Без иллюзий
Ты хочешь стать разработчиком? Тогда давай сразу без иллюзий. Разработка — это не «писать код». Разработка это в основном работать с тем, что уже написано. Если разложить честно, ~30% это новые фичи, ~70% рутина. И именно на этих 70% люди ломаются.
Как выглядит работа на практике
Когда только заходишь в профессию, кажется, что всё будет выглядеть так: ты сидишь, пишешь код, делаешь фичи, создаёшь что-то новое. На практике читаешь чужой код, разбираешься в логике, которую писал не ты, фиксишь баги, переписываешь старое, покрываешь тестами, пишешь документацию. И только иногда — делаешь «что-то новое».

Тесты
Когда я впервые столкнулся с тестами, я вообще не понимал, зачем это нужно. Казалось, лишнее время, усложнение, «и так работает». Потом я попал на конференцию, где рассказывали про TDD. И в какой-то момент до меня дошло: тесты — это не про «правильно». Это про контроль системы. Сейчас я практически не пишу код без тестов. Потому что они ловят ошибки до продакшена, они дают уверенность при изменениях и ускоряют развитие системы на дистанции. Да, ты тратишь больше времени сейчас, но экономишь кратно больше потом. Если тебе скучно писать тесты, ты не готов к профессии.
Чтение чужого кода
Это одна из самых недооценённых вещей. Когда ты приходишь в новую компанию, тебе дают доступ, что-то объясняют на словах и говорят: «разбирайся». И ты сидишь и читаешь. Много. Долго. Без полного понимания. На старте это выматывает, потому что: нет контекста, нет полной картины, код может быть разного качества. Но это обязательный этап, и здесь есть переломный момент. Сначала ты просто читаешь, потом начинаешь видеть, где плохо, где можно улучшить, где архитектурные проблемы, и это уже рост.
Баги и фиксы
Очень часто это выглядит так: у тебя есть задача, ты в неё погружён, и тут прилетает баг из продакшена. Ты переключаешься. Теряешь контекст. Возвращаешься обратно — и снова входишь в задачу. Это нормально. В зрелых командах есть процессы дежурства (выделенные люди под баги). Но даже там это часть работы. И если ты думаешь, что будешь «только писать новые фичи» — нет. Ты будешь много чинить.
Рефакторинг и техдолг
Самая опасная фраза в разработке: «потом перепишем». Почти никогда «потом» не наступает вовремя. Я видел, как код разрастается до состояния, когда менять что-то страшно, всё связано со всем и производительность падает. И в какой-то момент приходится делать большой разворот. У меня был кейс, когда система уже не справлялась, поиск и фильтры работали плохо, нагрузка убивала базу. И вместо «латания» пришлось менять структуру API, менять хранилище (MySQL → Elasticsearch), пересобирать часть системы. Это не быстрый процесс. Но это цена за то, что техдолг копился.

Кто такой разработчик на самом деле
Теперь главное. Почему всё это важно. Потому что разработчик — это не человек, который пишет код. Разработчик — это человек, который поддерживает систему, развивает систему, держит её в рабочем состоянии, а это почти всегда рутина.
Простой тест готовности
Есть простой тест. Если тебе скучно писать тесты, раздражает чтение чужого кода, не хочется разбираться в баге - ты не готов к этой профессии. И это нормально. Лучше понять это раньше, чем через год. И наоборот, если ты принимаешь, что придётся читать больше, чем писать, исправлять чужие ошибки, думать о будущем кода, у тебя есть шанс вырасти.
Дисциплина и рост
Хорошая новость в том, что со временем это перестаёт быть «рутиной». Ты начинаешь быстрее понимать код, видеть проблемы заранее и использовать инструменты, которые упрощают работу. И это становится нормальной частью процесса. Разработка это не только про вдохновение. Это про дисциплину. И если ты готов к этому, всё остальное придёт.