Как понять, что вы растёте как разработчик: вопросы важнее объёма кода

Есть привычка, которая маскируется под продуктивность: мерить собственный рост объёмом выученного. Не идёт проект — значит, надо взять ещё одну библиотеку. Не чувствуешь прогресса — записаться на курс по новому фреймворку. Счётчик растёт, а ощущение застоя никуда не девается.

Второй популярный счётчик — сколько кода вы написали за день — врёт примерно так же. Особенно заметно это становится на деплое, когда приложение, идеально работавшее на localhost, отказывается запускаться на чужой машине.

Почему «работает» — плохая финишная лента

Когда вы собираете фичу, критерий «API вернул ожидаемый ответ, кнопка нажимается, данные появились на экране, в консоли чисто» выглядит разумным. Он и есть разумный. Собрать работающее — обязательный навык, без него дальше некуда.

Загвоздка в том, что этот критерий ничего не говорит о том, понимаете ли вы, что собрали. Он отвечает на один вопрос — работает ли — и молчит про остальные: почему работает, где перестанет работать, что случится, если изменится окружение.

Второй вопрос неприятнее. Зато он и учит.

Деплой — самый честный тест

Локально всё держится на невидимках. Порт, который вы поменяли полгода назад и забыли. Переменные окружения. Внешний сервис, поднятый у вас на машине. Конфиг, существующий только в вашей папке. Поведение сборки, о котором вы никогда не задумывались, потому что оно и так работало.

Переезд наружу вытаскивает каждую невидимку на свет. Сначала это выглядит как список поломок: поправить порт, поправить конфиг, задеплоить заново. Но после пятого круга меняется сама реакция. Когда что-то снова запускается локально, вместо «готово» в голове всплывает другое: что именно заставило это работать?

• есть ли настройка, без которой проект не стартует, и только у меня она уже выставлена;
• не крутится ли рядом сервис, о котором я забыл и который молча всё вытягивает;
• сможет ли другой человек поднять проект по инструкции, если я ему её дам;
• что сломается, если окружение изменится — версия, порт, права доступа, переменная;
• какую часть этого кода я не могу объяснить своими словами.

Пять вопросов, которые раньше просто не приходили в голову. Отвечать на них дольше, чем нажать «Deploy» ещё раз.

Ошибку можно закрыть, а можно прочитать

Инстинкт у всех одинаковый: увидел красный текст, скопировал в поиск, нашёл похожую тему, применил совет, сообщение исчезло, идём дальше. Так делает большинство. Так будете делать и вы — и это нормально.

Сдвиг начинается в другом месте. Ошибка — это сообщение системы о вашей модели мира. Закроете её, не прочитав, — она вернётся. Обычно в слегка другой форме и в самый неподходящий момент, когда вы уже переключились на следующую задачу. Пара лишних минут на разбор сообщения экономит потом часы.

README как рентген собственного проекта

Документацию удобно считать тем, что пишут после настоящей работы. Но попробуйте написать README, по которому проект запустит посторонний. Придётся объяснить, как приложение стартует, какие настройки ему нужны, от каких сервисов оно зависит и что должно стоять в системе до первого запуска.

Пока вы это формулируете, вылезают допущения. Вещи, очевидные только вам, потому что вы же всё это и собирали. Неприятно. Полезно. README перестаёт быть описанием кода и становится проверкой того, понимаете ли вы среду вокруг него.

Когда копать не надо

Всё это легко довести до абсурда. У прототипа, который живёт один вечер, нет причин иметь выверенный README и продуманную конфигурацию. У скрипта-однодневки — тоже. Сначала добиться, чтобы оно работало, — нормальный порядок вещей, а не компромисс.

Разница в том, оставляете ли вы вещь жить. Прототип, который через месяц запускают у себя трое коллег, — уже другая история. Ошибка, всплывшая во второй раз, — тоже сигнал, что пора разобраться, а не залепить.

Две привычки, которые мешают

Искать свою ошибку по чужой. Копирование решения с форума даёт быстрый результат и почти нулевое понимание. Иногда этого достаточно, но если тот же класс ошибок возвращается — значит, вы лечите симптом, а причина осталась. Разница в подходе простая: сначала выписать своими словами, что вообще должно было произойти, и только потом идти искать.

Писать документацию для галочки. Одна строка в списке, потому что тут объяснять особо нечего.

Замечать, что день ушёл на логи, чтение документации и разбор конфигов вместо печати кода, поначалу неприятно: кажется, что ты не работаешь. Но мерить разработку объёмом набранных символов — то же самое, что мерить работу врача количеством выписанных рецептов. Иногда меньше кода и больше вопросов — это и есть движение вперёд. Хотя бы потому, что часть будущих проблем вы ловите до того, как они станут чужой головной болью.

Понять, стал ли ты лучше, изнутри собственной головы почти невозможно. Ступоры, поиск того, что вроде бы должен знать, сломанные сборки — всё это никуда не девается. Единственное, что реально поддаётся наблюдению, — формулировки. Если вместо «как заставить это работать» вы всё чаще спрашиваете «почему это работает» и «что я тут предполагаю», счётчик действительно сдвинулся.