Решать задачи бизнеса и не забывать расти самому. Заметки для разработчика

Есть шутка: «Хочешь быстро стать лидом — останься последним в комнате из тех, кто знает бизнес‑процессы и код». В компаниях с текучкой она вполне может оказаться карьерным планом.

Но если коллеги пока не собираются увольняться, придется придумать что‑то еще. Ниже мысли о том, что можно делать для своего развития прямо на работе. В первую очередь для джунов и мидлов, хотя некоторые вещи приходится напоминать себе и позже.

Задач больше, а ты растешь?

Допустим, раньше ты делал задачу за три дня, теперь за один. Хорошо. Тебе начинают давать больше задач, ты их закрываешь, все довольны. Через полгода обнаруживаешь, что делаешь примерно то же самое, только быстрее и больше.

В этом тоже есть польза: набиваешь руку, меньше ошибаешься. Но если хочется дальше, стоит иногда смотреть на свои задачи и спрашивать себя, чему ты на них учишься. Если ответ каждый раз звучит как «быстрее делать такие же», возможно, пора поговорить о других задачах.

Можно сравнить себя с собой несколько месяцев назад. Что тогда без коллеги вообще не мог сделать, а теперь можешь? В каком куске проекта разобрался? Можешь объяснить, почему сделали именно так и что сломается, если это поменять? Здесь хотя бы понятно, что сравнивать.

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

Кстати, я знаю людей, которые могут заниматься только рутиной на протяжении многих лет, и их это устраивает. Лично для меня это сверхнавык, и иногда я им даже завидую. Так что, если вы из таких людей, то, может, ничего делать и не требуется.

Чужой код все равно придется читать

Писать свое обычно интереснее. Там хотя бы понятно, кого ругать. Но на работе придется разбираться и с тем, что написали до тебя: кодом, конфигами, запросами в базу и переписками, в которых полгода назад что‑то решили.

Начать можно со своей задачи: куда приходит запрос, через какие сервисы проходит, где лежат данные, кто потом использует результат. Не обязательно сразу изучать все репозитории компании. Пройти один рабочий сценарий от начала до конца уже полезно.

Если есть возможность посмотреть соседний проект, пользуйся. Особенно когда он делает что‑то похожее. Можно спросить, почему там другой подход, с какими проблемами столкнулись и что сейчас сделали бы иначе. Только не надо после первого просмотра бежать переписывать свой проект, потому что там красивее.

Сюда же относится умение разбираться с проблемами. Например, запрос тормозит. По коду можно долго гадать, что не так. А можно посмотреть время выполнения, пройти по трейсу, если он есть, найти медленный вызов и уже разбираться с ним. Может, там запрос в базу, может, ожидание другого сервиса, а может, несколько повторных попыток, о которых ты не знал.

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

Иногда, даже посмотрев, как пишут и разбирают логи другие команды, можно много чему научиться.

Спрашивай, пока не закопался

Если задача непонятна, лучше потратить время на вопросы в начале: что должно получиться, кто этим будет пользоваться, какие случаи нужно учесть. Особенно если в описании три строчки и одна из них содержит только «сделать по аналогии».

Когда застрял в коде, расскажи коллеге, что пытаешься сделать, что уже посмотрел и где именно перестал понимать. Так ему не придется вытягивать из тебя историю по одному сообщению. Но и сидеть два дня ради того, чтобы прийти с достаточно умным вопросом, тоже не нужно.

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

Иногда на ревью сталкиваются два вполне рабочих подхода. Тут интересно разобраться, что именно не устраивает: есть риск ошибки, проблема с поддержкой или в команде просто так принято. Это разные причины, и обсуждать их тоже стоит по‑разному. Привыкай слышать фразу «Так исторически сложилось», но сам пытайся такого не допускать.

Если есть более опытный человек, который готов помогать, не обязательно сразу объявлять его своим ментором. Можно начать с конкретного вопроса или попросить вместе разобрать решение. А потом попробовать применить то, что обсудили. Иначе можно очень приятно общаться о развитии, но ничего особо не менять.

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

ИИ: задачу закрыл, а что понял?

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

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

Умение ставить ей задачу стоит развивать. Если просишь «сделай нормально», не удивляйся, что ее «нормально» сильно отличается от твоего. Дай контекст: что должно получиться, как сейчас работает проект, какие есть ограничения, что менять нельзя и как будешь проверять результат. Не обязательно писать огромный промпт. Иногда достаточно показать похожий модуль и объяснить, чем новая задача отличается.

Если инструмент умеет работать с репозиторием, можно попросить сначала изучить нужный участок и описать план изменений. Тут уже видно, туда ли он вообще пошел. Если предлагает переписать половину проекта ради небольшого исправления, лучше заметить это до того, как он все переписал.

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

Просить задавать уточняющие вопросы полезно. Но фраза «не выдумывай» не гарантирует, что модель перестанет выдумывать. И ее ответ «уверен на 95%» тоже ничего сам по себе не доказывает. Проверять все равно придется: открыть документацию, прочитать изменения, запустить подходящие проверки, посмотреть граничные случаи.

Не нужно и специально делать все руками из принципа. Если уже понимаешь задачу и можешь проверить результат, почему бы не сэкономить время. Главное, иногда замечать, какие вещи ты теперь умеешь сам, а какие только научился отправлять в чат.

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

Стартап или корпорация

Если выбора пока нет, идешь туда, куда берут, и смотришь, чему там можно научиться. Но если выбираешь между предложениями, размер компании сам по себе мало что объясняет.

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

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

Поэтому я бы смотрел на конкретную команду. Кто будет делать ревью? Какие задачи получишь в начале и позже? Можно ли брать что‑то за пределами своего участка? Есть ли у коллег время объяснять? Что происходило с людьми, которые пришли сюда на похожую позицию?

И в стартапе можно найти сильного наставника, и в корпорации остаться один на один с непонятным проектом. Лучше выяснить это до выхода на работу.

А что нужно для повышения?

Можно долго стараться угадать. Брать больше задач, помогать всем вокруг, задерживаться и ждать, что в какой‑то момент это автоматически превратится в новую должность. Иногда так и происходит. Но лучше хотя бы поговорить с руководителем.

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

Дальше уже можно договориться о конкретной работе и о том, когда вернетесь к обсуждению. Так будет что показать и что разобрать, даже если не все получилось с первого раза.

При этом ты можешь стать сильнее, а повышения не получить. Нет позиции или бюджета, либо руководитель вообще не собирался никого повышать. Это неприятно, но полезно выяснить. Еще десять задач сверху не обязательно что‑то изменят.

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

По личному опыту скажу, что здорово, если ты заведешь себе хобби: будешь нет‑нет да и решать какие‑либо задачи с литкода (это не реклама, но если кто оттуда читает, то я не против буду, если продлите годовую подписку). Даже изи‑уровень даст свои плоды. К примеру, когда тебе потребуется строить большие отчеты из разных источников, умение работать с разными типами данных очень поможет. И да, смотреть готовое решение задачи до того, как решишь её сам, не является слабостью, если ты вообще до этого никогда этим не занимался.

С чего начать

Не нужно в понедельник одновременно искать ментора, учить мониторинг, писать скилы и просить новый грейд. Выбери что‑то одно, что сейчас мешает в работе.

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

Или ты нормально пишешь код, но задача постоянно возвращается, потому что что‑то не учел. Тогда полезнее разобраться, как уточнять требования и проверять результат, чем срочно изучать еще один фреймворк.

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

Сроки тут у каждого свои. Важно, чтобы через какое‑то время ты мог назвать конкретную вещь, которой научился. А то список закрытых задач будет большой, а на вопрос «Что нового?» опять ответишь: «Да всё то же самое».