Сколько времени уходит на код
Меньше, чем принято думать. У обычного разработчика написание нового кода занимает примерно четверть рабочего времени, иногда меньше.
Остальное — чтение чужого кода, разбирательство, почему что-то не работает, обсуждения, уточнение требований, проверка чужих изменений, встречи.
Это не значит, что работа скучная. Это значит, что представление «программист сидит и печатает» неверное, и тот, кто идёт в профессию с таким ожиданием, испытывает разочарование.
Обычный день
- Утренняя сверка. Пятнадцать минут: кто что делал, где застрял.
- Работа над задачей. Обычно это выглядит так: разобраться, где менять, прочитать окружающий код, понять, почему сделано именно так, и только потом писать.
- Разбор чужих изменений. Смотрите код коллег, оставляете замечания.
- Ответы на вопросы. Ваши и к вам.
- Разбирательство с поломкой. Регулярная часть работы: что-то не работает, надо понять почему.
Что оказывается неожиданным
Чтения больше, чем письма. Вы приходите в проект, где сто тысяч строк, написанных до вас. Умение быстро разбираться в чужом коде важнее, чем скорость набора.
Много общения. Уточнить требования, объяснить решение, договориться с соседней командой. Полностью молчаливая работа — редкость.
Требования меняются. То, что вчера было нужно, сегодня отменили. Это нормальный ход дела, а не чья-то ошибка.
Мало красивого кода. В реальных проектах всегда есть места, написанные наспех. Работа во многом состоит из аккуратного улучшения того, что есть.
Что действительно нужно уметь
- Разбираться в незнакомом. Главный навык. Знания устаревают, умение быстро вникнуть — нет.
- Задавать вопросы. Вовремя и по делу.
- Объяснять свои решения. Если не можете объяснить, почему сделали так, решение считается случайным.
- Доводить до конца. Умение закрывать задачи ценится выше умения красиво начинать.
Кому это подходит
Тем, кому нравится разбираться, как что-то устроено, и кого не бесит долгое ковыряние в непонятном. Кто способен спокойно провести три часа, выясняя, почему одна цифра не сходится.
Плохо подходит тем, кто ждёт быстрого результата и не выносит неопределённости: значительная часть работы — это состояние «пока непонятно».
Как проверить, ваше ли это
Единственный надёжный способ — сделать что-то самому от начала до конца. Не пройти курс, а именно сделать: с непонятными ошибками, тупиками и необходимостью самому решать, как правильно.
А чтобы понять, подходит ли вам ещё и командная сторона профессии, стоит поработать с людьми: разделить задачи, обсудить чужой код, договориться о сроках. Это ближе всего к настоящей работе — и выясняется быстрее, чем за год учёбы в одиночку.
Хватит читать — пора делать
На CohortX можно найти команду под пет-проект и получить тот самый опыт, о котором спрашивают на собеседовании.
Похожие статьи
- What a junior QA engineer should knowWhy this is the fastest entry into the field, what you need at the start, and how a tester builds a portfolio.
- Что должен уметь начинающий тестировщикПочему это самый быстрый вход в профессию, что нужно знать на старте и как собрать портфолио тестировщику.
- What a junior backend developer should knowThe minimum asked at entry, what gets learned on the job, and which gaps are visible immediately.