Полезные привычки для разработчика-джуниора

Перевод первой части статьи «9 Habits I Wish I Had as a Junior Developer».

Photo by Luca Bravo on Unsplash

Вам когда-нибудь случалось сесть и «проинвентаризировать» свои привычки? Ведь именно они делают нас теми, кто мы есть!

Хорошие привычки помогают вам стать тем, кем вы хотите быть. А плохие медленно, но верно превращают вас в того, кем вы быть не хотите.

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

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

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

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

Добровольно беритесь за вещи, в которых не разбираетесь

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

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

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

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

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

Если нужно исправить что-то в сборке, а вы никогда не работали со сборкой системы, — беритесь! Вы приобретете новые навыки.

Если есть какой-то баг во фронтенде, написанном на JavaScript, а вы до сих пор работали только с бэкендом (причем на Java), попробуйте взяться за его исправление! Вы изучите новые идиомы JavaScript.

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

Photo by Marc Mintel on Unsplash

Проситесь поработать в паре с кем-нибудь

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

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

Знакомьтесь с контекстом. С какой кодовой базой вам нужно работать? Каковы явные и неявные соглашения по написанию кода в этой базе?

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

Таким образом вы научитесь у коллеги, как следует подходить к обдумыванию и решению задач. Вообще, новичку парное программирование принесет сплошную пользу. Одни только новые сочетания клавиш в IDE чего стоят!

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

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

Рассказывайте о том, что делаете (и чего Не делаете)

Я даже не припомню, сколько раз случалось, что я резво хватался за задачу, думая, что справлюсь за день, но не заканчивал и за неделю.

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

  • давление руководства, которое требует закончить новую фичу побыстрей, ведь дедлайн близок,
  • покрасоваться перед коллегами,
  • расчет на то, что все будет работать без сучка, без задоринки (вот на этом я постоянно спотыкаюсь, даже несмотря на весь мой опыт; дело в том, что многие вещи просто не работают так, как ожидалось),
  • и многое, многое другое…

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

Вы можете управлять ожиданиями уже в процессе работы

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

Итак, если ваш менеджер (команда, менеджер проекта или продукта, стейкхолдер) ожидает от вас результатов, ежедневно давайте ему быстрый апдейт: «Я работаю над тем-то и тем-то. Столкнулся с такой-то проблемой. Вот варианты ее решения».

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

Благодаря такому подходу вопросы типа «Почему так долго?» останутся в прошлом. Дополнительный плюс: такие апдейты способны породить дискуссии, которые могут помочь в решении проблем.

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

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

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

Ведите блог

Вероятно, я далеко не первый, от кого вы получите этот совет, но я все равно скажу: ведите блог!

Он даже не обязательно должен быть доступен другим людям. Это могут быть пара страниц на wiki компании или подборка GitHub-репозиториев с примерами кода и несколькими строчками поясняющего текста.

Зачем?

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

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

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

А три года назад я начал вести мой теперешний блог. Я писал, не имея никакой аудитории, в течение полугода. А потом я заметил, что мой файл robots.txt не разрешал поисковикам индексировать мой блог!

В общем, я изменил настройки в robots.txt, и люди начали читать мои статьи. Читателей было не много, но все равно их наличие стимулировало меня не останавливаться. Постепенно я отточил свои навыки письма, и теперь мой блог набирает 200 тысяч просмотров в месяц.

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

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

Конец первой части. Часть 2.

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх