Write helpful error messages — the user's first debugging tool

Vague error messages like 'Something went wrong' or 'Invalid input' force users to guess what happened. Developers waste time debugging errors that should be self-explanatory.

Every error message should answer three questions: (1) What happened? (2) Why did it happen? (3) How to fix it. Format: 'Failed to [action] because [reason]. [Fix suggestion].' Example: 'Failed to connect to database at localhost:5432 because connection was refused. Check that PostgreSQL is running: sudo systemctl start postgresql'. Include relevant values (the URL, the input, the expected format) but never include secrets.

Error messages are the most-read documentation. A good error message eliminates a support ticket or debugging session. A bad one creates one.