5 способов создания культуры, дружественной к разработчикам-джуниорам

0
891
views

Перевод статьи «5 ways to create a junior developer-friendly culture».

Дружественная к разработчикам-джуниорам культура

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

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

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

1. Эмпатия и уважение

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

Эмпатию и уважение можно проявлять по-разному, например:

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

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

Тот факт, что каждый когда-то был джуниором, очень легко забывается.

2. Используйте местоимение «мы», а не «ты»

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

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

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

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

Необвиняющая атмосфера

3. Парное программирование и отладка

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

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

4. Найдите вашу stretch-зону

Тара Охо произнесла прекрасную речь на тему работы в stretch-зоне. Она объяснила, что каждый разработчик может находиться в одной из трех зон:

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

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

Стретч-зона

5. Говорите «я не знаю»

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

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

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

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here