DX ломается не в API, а в первом неудачном запуске

DX ломается не в API, а в первом неудачном запуске

Плохой developer experience почти всегда начинается с одного и того же: человек открыл docs, скопировал пример, получил ошибку и не понял, где именно он споткнулся. Для tooling это критично: если до первого рабочего запроса слишком много шагов, дев уходит молча.

Что должно быть в онбординге:
— один короткий quickstart без лишней теории
— рабочий пример запроса сразу в curl, Python и JS
— понятные ошибки: не “invalid request”, а что сломалось и как исправить
— минимальные права для первого теста, без полного доступа ко всему

Отдельно проверьте путь от auth до первого response. Если токен, sandbox, переменные окружения и base URL лежат в разных местах, это уже не DX, а квест. Хороший знак — когда пример можно запустить, не открывая пять вкладок подряд.

Ещё одна типовая яма — docs пишут для команды продукта, а не для человека, который просто хочет встроить сервис в свой скрипт. Дев не читает длинные объяснения про архитектуру, он ищет готовый кусок кода и одну-две оговорки по краям.

Если первый запрос не проходит за 5 минут, проблема почти всегда в документации, а не в пользователе.