Я слышал один полезный критерий для DX: сообщение об ошибке должно быть понятно человеку, который читает его в

Я слышал один полезный критерий для DX: сообщение об ошибке должно быть понятно человеку, который читает его в два часа ночи, на нервах и без контекста.

Если в ответе только `invalid_request`, вы не экономите место — вы перекладываете работу на разработчика. А это почти всегда лишние 20–40 минут: открыть логи, гадать по параметрам, писать в поддержку, ждать ответ.

Что обычно работает лучше:
1. что именно сломалось;
2. почему это могло случиться;
3. что сделать прямо сейчас;
4. где посмотреть пример.

Инсайд тут простой: хороший API редко вызывает восторг. Зато «скучный» API, где ошибки предсказуемы и одинаково устроены, почти всегда выигрывает. Потому что он сокращает время до первого успешного вызова — а это и есть главный онбординг-метрический момент.

Если хотите привести ошибки в порядок, начните с шаблона:
- код ошибки;
- короткий человекочитаемый заголовок;
- пояснение;
- решение;
- ссылка на документацию.

🛠 Это не про «красивый текст». Это про снижение трения в продукте.