Перевод статьи «Career Advice for Junior Developers».
Разработчики, только начинающие свою карьеру, часто спрашивают меня, как им побыстрее повысить свой профессиональный уровень.
По сути они хотят знать, как им побыстрее стать эффективными членами команды, познакомиться с огромной кодовой базой и вообще узнать все, что нужно для работы.
Переход на новое место может быть стрессом даже для разработчика-сеньора. Но если речь идет о вашей первой работе, это особенно тяжело. Давайте рассмотрим четыре стратегии повышения профессионализма разработчика-джуниора, позволяющие быстро освоиться на рабочем месте.
1. Задавайте много вопросов
Во-первых, задавайте вопросы, да побольше. И что еще более важно, не бойтесь это делать. Набраться смелости, чтобы что-то спросить, может быть непросто. Это как бы признание того, что вы не все знаете. Но стоит ли переживать об этом? Сфера разработки настолько обширна, что в ней никто не может знать всё.
Задавая вопросы, особенно на открытом форуме (например, в Slack-канале вашей компании), вы попадаете в уязвимое положение.
Вы можете задаваться вопросами: «Будут ли коллеги смотреть на меня свысока из-за того, что я этого не знаю? Не перестанут ли они доверять мне как программисту?» В такие моменты важно напоминать себе о нескольких вещах.
Во-первых, все с чего-то начинают. Даже программисты с 30-летним стажем когда-то были на вашем месте и старались сориентироваться в обширной сфере разработки программ.
Во-вторых, если у вас возник вопрос, весьма вероятно, что эта тема интересна нескольким другим людям. Если вы наберетесь смелости и спросите открыто, это поможет и вам, и вашим коллегам.
В-третьих, синдрому самозванца подвержены все. Буквально каждый разработчик в какой-то момент чувствует, что недостаточно хорош, что не заслуживает того, чтобы занимать свое место, что если его коллеги поймут, насколько мало он знает, его разоблачат как мошенника. Не слушайте голос, который вселяет в вас эти сомнения.
В-четвертых, когда вы задаете свой вопрос на публичном форуме, он становится документацией, к которой вы сможете вернуться позже.
Я всегда рекомендую разработчикам, отправляющим мне личные сообщения, вместо этого размещать свои вопросы в общедоступных каналах Slack. В таком случае ответить на вопрос сможет любой член команды (или даже несколько человек), а ответы пригодятся не только тому, кто спросил, но и тем, кто постеснялся спросить. Кроме того, обсуждение станет доступным для поиска, а это поможет тем, у кого такой же вопрос возникнет в будущем.
А теперь хочу обратиться к опытным разработчикам, к которым адресуются вопросы от начинающих. Уязвимость, возникающая, когда кто-то задает вопрос на публичном форуме, это проявление доверия к вам. Культура вашей компании зависит от вас. Будет ли эта компания и команда психологически безопасным местом, где люди могут задавать вопросы, не подвергаясь критике? Решать вам. Реагируя на вопросы, проявляйте мудрость, иначе создадите среду, в которой ваши коллеги будут боятся высказаться.
Когда Google проводил исследование, чтобы определить факторы, способствующие высокой производительности в команде, на первом месте оказалась психологическая безопасность. Члены команды должны чувствовать себя в безопасности и знать, что в обществе друг друга можно проявлять уязвимость.
Но вернемся к джуниорам. Какие вопросы вы могли бы задать, чтобы стать более эффективным членом команды? Вот несколько примеров:
- Не могли бы вы показать мне структуру директорий нашей рассказать мне об архитектуре нашего приложения? Какие фреймворки и библиотеки мы используем?
- Не могли бы показать мне структуру директорий нашей кодовой базы? Где какой код находится? Как он организован?
- Как выглядит процесс разработки? Какой тип рабочего процесса Git мы используем?
- Как происходит релиз? Как новый код попадает в продакшен? Насколько часто выпускается новый код?
- Почему фича X была реализован именно так?
- Почему мы используем библиотеку A, а не библиотеку B?
Все это прекрасные вопросы, которые стоит задавать не только разработчикам-джуниорам, но и всем, кто начинает работать на новом месте.
2. Просите о помощи, когда она вам нужна
Точно так же важно обращаться за помощью, когда она вам нужна.
Схватка с трудной задачей — неотъемлемая часть обучения тому, как справляться с проблемами и устранять неполадки. Если вас постоянно будут водить за руку, не давая работать самостоятельно, ваш прогресс замедлится. Но бывают моменты, когда разумнее признать, что вам нужна помощь.
Есть отличное правило: если вы застряли, работая над какой-то задачей, отведите себе еще 15 минут на попытки справиться самостоятельно. Затем, если все же не получилось, попросите о помощи.
Эта 15-минутная задержка перед обращением за помощью устанавливает временные рамки для решения задачи, чтобы вы все-таки не провели над ней целую вечность. Кроме того, это вынуждает вас попробовать еще раз решить все самостоятельно (ведь сразу сдаться нельзя). А поскольку вы можете не хотеть обращаться за помощью, ограничение по времени может дополнительно мотивировать вас напрячь мозг!
Если срок в 15 минут истек, а вы все еще не выбрались из тупика, пора обратиться за помощью.
Вы можете подумать, что лучше продолжать копаться самостоятельно, но вспомните, что вам платят за выполнение работы. С финансовой точки зрения тратить на что-то целые часы без всякого прогресса — неэффективно. Особенно, если коллега может быстро подсказать вам что-то и разблокировать вашу работу. Не забывайте, что команда и нужна для того, чтобы помогать друг другу.
Опытные учителя и наставники, помогая джуниорам, часто используют теорию Выготского о зоне ближайшего развития и скаффолдинг (даже если ничего о них не знают).
Зона ближайшего развития (ЗБР) — это «расстояние между тем, что учащийся может делать без посторонней помощи, и тем, что он может делать при поддержке человека, обладающего большими знаниями или опытом». Скаффолдинг (англ. «строительные леса») — это метод предоставления студентам рекомендаций, помогающих им работать в рамках ЗБР.
То есть, опытный наставник дает начинающему разработчику ровно столько рекомендаций, сколько нужно, чтобы тот смог самостоятельно выполнить свою задачу. Как вариант — дает достаточно информации, чтобы разблокировать новичка на любой стадии разработки.
3. Учитесь непрерывно
Сфера разработки программного обеспечения все время меняется. Создаются новые языки, некогда популярные библиотеки и фреймворки вытесняются новыми, постоянно возникают и исчезают новые тренды в дизайне.
Чтобы не отставать в этом быстро меняющемся мире, вы должны постоянно приобретать новые знания и навыки. Разработчики не могут просто отучиться в университете или на курсах, найти работу и никогда больше не возвращаться к учебе. Мы учимся каждый день.
В книге «Гении и аутсайдеры» (2008) Малкольма Гладуэлла было сформулировано «правило 10000 часов», ставшее затем очень популярным. Оно гласит, что чтобы стать в чем-то экспертом, требуется примерно 10000 часов работы в этой сфере.
Естественно, что чем больше вы что-то практикуете, тем лучше у вас получается. Тем не менее, правило 10000 часов было опровергнуто несколько раз с момента публикации книги.
Оказывается, на самом деле важно не только то, сколько вы тренируетесь, но и то, как вы это делаете. «Практика» и «осознанная практика» — разные вещи.
Когда вы учитесь играть на музыкальном инструменте, вам нужно осознанно подходить к тому, как и что вы практикуете. Если вы разучиваете какую-то конкретную песню, вы не будете просто повторять ее снова и снова. Просто проигрывать каждый раз от начала до конца — неэффективно. Скорее всего, какие-то части в песне будут сложнее других. Занимаясь осознанной практикой, вы проигрываете четыре сложных такта снова и снова, пока не добьетесь хорошего результата. А после этого переходите к следующей части.
Та же концепция применима к разработке. Не нужно беспорядочно хвататься за разные темы. Осознанно выбирайте то, что хотите изучить.
Если вы чувствуете, что испытываете трудности с написанием юнит-тестов, посмотрите двухчасовой курс Pluralsight по модульному тестированию с помощью Jest. (Или любой другой курс по любому другому тестовому фреймворку, подходящему для вашего языка).
Если пытаетесь изучить React, прочтите документацию: у React она чертовски хороша!
Постарайтесь разобраться в основах технологий, которые использует ваша компания. Познакомьтесь с AWS, Heroku или любыми провайдерами IaaS / PaaS, которые вы используете. Если вы фронтенд-разработчик, изучите фреймворк или UI-библиотеку, которую использует ваша компания, например Angular, React или Vue. Если вы часто работаете с базами данных, узнайте о различиях между SQL и NoSQL, а также об их сильных и слабых сторонах.
Другими словами, найдите время, чтобы «заточить пилу». Стивен Р. Кови в своей книге «7 навыков высокоэффективных людей» ставит «затачивание пилы» последним, седьмым навыком. Он приводит притчу о дровосеке, который с огромным трудом пилит лес тупой пилой, но отказывается ее точить, потому что у него нет на это времени: пилить надо.
Занимаясь в рабочее время исключительно рабочими задачами, легко попасть в ловушку. Ваше рабочее время отслеживается, а работодатель его оплачивает. Логично, что это время вы должны тратить на работу, верно? Однако такое мышление недальновидно. Это все равно, что часами пилить большое дерево, не тратя времени на заточку пилы. Да, в то время, когда вы затачиваете пилу, вы не пилите. Но чем острее пила, тем более эффективной будет ваша дальнейшая работа. В итоге вы сможете спилить дерево за меньшее время, чем если бы вы не остановились, чтобы заточить пилу.
Хорошие работодатели признают эту истину и активно поощряют сотрудников тратить несколько часов в неделю на целенаправленную учебу.
Не стесняйтесь тратить время на чтение статьи или просмотр видеоуроков в рабочее время. Если вы делаете это в рамках осознанного оттачивания навыков, вы станете куда более эффективным разработчиком, чем если бы тратили все рабочее время исключительно на решение производственных задач.
4. Участвуйте в код-ревью
Наконец, принимайте участие в проверках кода. Все уважаемые компании, занимающиеся разработкой программного обеспечения, внедрили процедуры ревью, чтобы поддерживать высокое качество своей кодовой базы.
Код-ревью обычно рассматриваются как практика контроля. Они позволяют убедиться, что в коде используются хорошие паттерны проектирования, что код чист, что он должным образом протестирован и что возможные неприятности предотвращены.
Но не менее важно то, что ревью кода также способствуют обмену знаниями. Когда вы создаете новый мерж-реквест (= пул-реквест) и просите коллег просмотреть ваш код, вы приглашаете их высказать свое мнение.
Таким образом вы можете узнать о самых разных вещах. Например, о способах рефакторинга кода, о структуре данных или паттерне проектирования, более подходящих для вашего случая, о нарушении вами best practices, которым вы еще не научились.
Ревью кода — одна из лучших возможностей для учебы, и она встроена прямо в процесс разработки!
Код-ревью может быть сложным эмоционально. Люди будут критиковать ваше творение, а это задевает эго творца. Старайтесь не забывать, что даже если часть вашего кода плохая, это не делает вас плохим разработчиком. Заглушите голос своего эго и помните о конечной цели — создании высококачественного кода и обмене знаниями.
При подготовке мерж-реквеста всегда с уважением относитесь к ревьюерам. Они тратят время на то, чтобы помочь вам, поэтому следите за тем, чтобы у вас были хорошие сообщения коммитов и полезные описания мерж-реквестов. И, конечно, первоначально сами проверяйте свой код.
Ничто так не раздражает ревьюера, как проверка кода без понимания контекста и обилие закомментированного и плохо отформатированного кода.
С другой стороны, не бойтесь также проверять код других разработчиков, даже сеньоров. Никто не идеален, и разработчики-сеньоры тоже допускают ошибки.
Изучая код более опытных программистов, вы сможете увидеть, как они его пишут и структурируют, как называют переменные и решают сложные проблемы. Подражая стилю программирования старших коллег, вы сможете быстро повысить качество своего собственного кода.
У Google есть отличные рекомендации для ревьюеров, а также для авторов кода. Я очень рекомендую прочитать оба раздела.
(Примечание редакции Techrocks. А мы рекомендуем статьи для ревьюеров и авторов кода, опубликованные на нашем сайте).
Заключение
Если вам суждено запомнить только одну вещь из этой статьи, пускай это будет тема целенаправленной учебы. Определите, что вам нужно изучить, и сфокусируйтесь на этих вещах. Занимайтесь осознанной практикой. Проявляйте любопытство и старайтесь удовлетворять свою жажду знаний. Все это будет способствовать вашей долгой и успешной карьере. Удачи!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]