Советы разработчика с 8-летним опытом работы

Сменить команду

В каких случаях есть смысл попробовать перейти в другую команду:

• Вам слишком комфортно на нынешней должности, и вы хотели бы выйти из зоны комфорта.

• Вам не очень нравятся проекты/задачи команды, и вы хотели бы работать над проектами, которые вам больше по душе.

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

Если вы оказались в одной из этих ситуаций, то я советую вам подумать о новой команде, а не сразу увольняться и искать новую компанию.

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

Я считаю, что смена команды — это может быть здорово по следующим причинам:

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

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

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

• Вы можете изучать новые инструменты, языки, библиотеки, архитектуры, способы решения проблем. Другими словами, стать лучшим разработчиком.

• Возможно, у вас появится возможность работать в лучших условиях, если ваш переход вызван причинами 2 или 3, упомянутыми ранее.

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

Когда я присоединился к новой команде, я почувствовал, что мое звание Senior программиста больше не является легитимным. Мне пришлось изучать новые кодовые базы, инструменты и практики. Конечно, я сохранил свои мягкие навыки и знания о бизнесе/продуктах, но мои технические навыки пострадали. Изучать что-то новое, конечно, здорово, но я больше не был техническим лидером в команде. Хотя, когда новой команде приходилось участвовать в проектах моей предыдущей команды, я мог помочь им более эффективно. Со временем чувство самозванца прошло, и я вырос, поскольку приобрел больше навыков.

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

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

Писать посты в блог

Этот пункт должен быть просто «Писать», но он показался мне слишком коротким. Умение писать — один из самых важных навыков, которыми должен обладать разработчик. Большая часть нашей повседневной работы связана с написанием текстов: кода, сообщений, писем, документации, RFC, заметок о встречах, разборов инцидентов и т. д.

Письменная речь — один из лучших асинхронных способов общения с людьми. Сообщения можно читать в любое удобное время, не прерываясь в середине задачи. Конечно, в некоторых ситуациях синхронное общение является лучшим способом коммуникации: видеозвонок, личные встречи, чтобы решить какую-то срочную проблему или устранить двусмысленность и неправильное толкование. Но, по моему опыту, разработчики ежедневно больше пишут, нежели говорят.

Писать статьи полезно по следующим причинам:

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

• Цель написать статью заставит вас разбираться в выбранной теме. Это отличный способ узнать что-то новое, закрепить знания или разобраться в чем-то на более высоком уровне. 

• Это развивает ваш личный бренд. Чем больше людей интересуются вашими статьями, тем больше подписчиков вы получаете и тем более заметным становитесь.

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

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

Я начал этот путь с публикации в инженерном блоге своей первой компании: The most accurate way to schedule a function in a web browser. Она даже получила упоминание в рассылке JavaScript Weekly, что было очень приятно.

Затем, в марте 2021 года, я начал писать статьи в блог на Dev.to и продолжаю это делать время от времени. Я также опубликовал статью на HackerNoon, но мне не понравилось, как они отредактировали заголовок, и я решил, что моим основным местом для ведения блога будет Dev.to, по крайней мере пока.

Что я хотел бы сделать по-другому, вернись я в прошлое

Быть более осторожным, производя глобальные изменения

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

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

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

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

В какой-то момент после этих презентаций мы увидели возможность:

• Это было в начале лета, поэтому активность бизнеса в течение нескольких месяцев будет ниже обычного.

• В первой половине года мы столкнулись с несколькими ошибками и были вынуждены использовать костыли в одной из наших старых систем.

• Мы могли бы радикально улучшить тестируемость и удобство для разработчиков этой системы, используя функциональные концепции и типы TypeScript (он же TS). Эта старая система была изначально разработана на ранней версии TS, которая не предоставляла широких возможностей для работы с типами.

Другими словами, это было идеальное время для рефакторинга! Я показал команде подтверждение концепции, использующей функциональное программирование и программирование на типах с помощью TS, чтобы значительно улучшить эту систему. Мы все убедились в ее преимуществах и решили пойти дальше, создав готовый к продакшену вариант. Я отвечал за создание задач, планирование того, что можно делать параллельно, и т.д. Я регулярно публиковал обновления в канале Slack, где заинтересованные стороны могли следить за ходом работы.

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

Меня сильно вдохновила библиотека fp-ts, способ кодирования которой, можно сказать, отличается от «обычного JavaScript». Мы не могли просто импортировать библиотеку в нашу кодовую базу из-за ограничений, о которых я не буду здесь упоминать, поэтому мне пришлось заново внедрить некоторые из ее функций и типов данных самостоятельно, с небольшими адаптациями. Я провел несколько презентаций об этих изменениях и получил положительный фидбек.

Отсутствие возражений замотивировало меня продолжить углубляться в эту тему.

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

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

Когда работа была закончена, я взял 2 недели отпуска (они уже давно были запланированы). Пока меня не было, команда, к сожалению, столкнулась с довольно важным инцидентом. Они изо всех сил пытались определить первопричину и найти способ ее устранения. Проблема находилась где-то внутри новой системы, которая совсем не походила на остальную часть кодовой базы. Команда не была знакома с ней, поскольку я разрабатывал ее практически в одиночку.

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

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

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

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

На самом деле мне с самого начала не следовало лезть в эту кроличью нору. Это не было прагматичным решением. Улучшение типов было хорошей идеей, но вся новая функциональная система была ошибкой.

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

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

Независимо от того, являетесь ли вы индивидуальным разработчиком (он же IC, individual contributor) или менеджером, если старший член команды вносит важные изменения, подобные этим, я настоятельно советую вам оспорить его предложение. Я уверен, что в моем случае можно было бы найти лучшее решение.

Если вы находитесь в таком же положении, как и я, я призываю вас дважды подумать, прежде чем принимать решение. Действительно ли это прагматичное решение? Уверены ли вы, что определена область применения и выявлены риски? Вы делаете это для блага команды или потому, что вам это нравится? Будет ли команде ок с этим решением, когда вас не будет рядом, чтобы помочь?

Не позволять эмоциям брать верх перед командой

Бывали моменты, когда я был категорически не согласен с тем, что руководитель или коллега рассказывал команде во время митинга. Я давал всем присутствующим понять, что меня это беспокоит, и таким образом публично начинал «конфликт».

Я хотел показать коллегам, что не соглашаться с чьим-то решением — это нормально. Однако такое поведение не является здоровым:

• Люди могут чувствовать себя неловко, когда конфликт становится видимым/очевидным, как в этих ситуациях. Несправедливо ставить их в такие ситуации.

• Это может привести к расколу в команде, когда одни соглашаются с человеком А, а другие — с человеком Б. Команда должна оставаться единой, чтобы быть эффективной.

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

Я не говорю, что сдерживать свои эмоции легко. В конце концов, мы люди, а не машины. Но также важно проявлять уважение к коллегам и не нарушать ход встречи.

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

• Поговорить с этим человеком на встрече 1-1.

• Или поговорить о ситуации с руководителем и найти способ ее исправить.

Важно провести эту встречу 1-1 сразу после ситуации, которая вызвала у вас прилив эмоций. Чем больше времени проходит, тем хуже становится ситуация.

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

Время от времени мониторить рынок труда

Когда я пришел в первую компанию в качестве стажера, у меня было 30-минутное собеседование с моим будущим руководителем. И все. Я прошел быстрое собеседование на «соответствие культуре», и меня приняли.

После этого я семь с половиной лет не выходил на рынок труда. Когда я наконец решил сменить место работы, мой единственный и короткий опыт трудоустройства явно не соответствовал тому, с чем мне предстояло столкнуться. Процесс трудоустройства, когда вы претендуете на должность Senior с опытом около 8 лет, определенно не состоит из одного лишь «30-минутного поведенческого интервью».

После прочтения книги The Most Heated Tech Job Market in History я почувствовал, что готов попробовать. Я обновил информацию в профиле на LinkedIn и указал статус «в поиске».

Я чувствовал подавленность. Разбираться со всеми предложениями, которые сыпались на меня ежедневно, было утомительно. С сентября 2021 года по конец октября 2021 года я получал, наверное, от 5 до 10 предложений в рабочий день. Мне приходилось брать отгулы, чтобы справиться с ситуацией, и я тратил на это значительную часть своих выходных.

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

• Я должен был работать весь день, так как в то время я еще работал в своей нынешней компании.

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

• Мне постоянно поступали новые предложения о работе.

Становилось все труднее отвечать на сообщения от рекрутеров.

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

Хочу сказать всем рекрутерам, которые связывались со мной в то время и которым я так и не ответил: Мне очень жаль. Я был просто ошеломлен ситуацией.

Но ответы на сообщения на LinkedIn были не самой сложной частью. Самыми утомительными были собеседования. У меня никогда не было возможности пройти обучение DSA (Data Structures and Algorithms), поскольку я не чувствовал необходимости менять компанию.

Я тренировался в основном на leetcode, а также купил несколько книг, которые мне помогли:

• Cracking the Coding Interview, Gayle Laakmann McDowell.

• System Design Interview Volume 1, by Alex Xu.

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

Когда я наконец принял оффер, я написал заявление об увольнении. Если я правильно помню, я получил тогда повышение зарплаты на 25%, а также дополнительную компенсацию и в целом более выгодные условия для сотрудников в моей ситуации (удаленная работа).

Причина, по которой я рекомендую вам время от времени проходить собеседования, заключается в следующем:

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

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

В моей первой компании я получал хорошие прибавки к зарплате (от 7 до 10 % в год), за исключением последнего года. Несмотря на то, что я не был доволен той зарплатой, которую получал в последний год, я считал, что в следующем году я все равно получу еще более высокую прибавку.

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

Не поймите меня неправильно: получить прибавку в 10% — это хорошо. Но если ваша зарплата на 15-20% ниже того, что рынок говорит вам о вашей ценности, то в конечном итоге и 10% прибавки будет недостаточно. А как узнать, есть ли у вас та компенсация, которую вы заслуживаете? Испытав этот рынок на себе. А также поддерживая связь с бывшими коллегами, которые сами испытали этот рынок.

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

Заключение

Прежде всего, спасибо, что дочитали до этого момента! Надеюсь, эта статья была для вас хоть в чем-то полезной. 

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

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