Почему только прокачка кодинга не сделает из тебя лучшего разработчика

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

Миф про хорошего разработчика гласит, что он:

1. Пишет чистый код
2. Знает много технологий
3. Быстрее кодит задачи
4. Знает кучу алгоритмов и шаблонов проектирования
5. Умеет отрефакторить любой код по Clean Code
6. Не тратит время на непрограммистские задачи
7. 100% мастер своей любимой технологии

Так видят идеальных кандидатов HRы, и вакансии, соответственно, выглядят тоже так.

Но мой опыт говорит, что это не сильно соответствует действительности.

Сперва два важных дисклеймера:
1) мой опыт – продуктовые команды, т.е. компании со своим продуктом, а не аутсорсом; в аутсорсе все может сильно отличаться;
2) если вы джуниор, то не все советы будут применимы, и я бы на вашем месте пока сконцентрировался на программировании.

Хороший разработчик: реальность

1: Кодит лучше среднего

Хороший разработчик умеет создавать классную архитектуру, писать классный код, не делать слишком много багов; в общем, у него все получается лучше среднего, но он не входит в топ-1% специалистов. Большинство самых классных разработчиков, что я знаю, не такие уж и прекрасные кодеры: они отлично разбираются в своей области, но ничего супер-сверх не умеют.

2: Решает проблемы, а не создает их

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

Хороший разработчик, столкнувшись с такой ситуацией, сам найдет контакты, спишется-созвонится, обсудит проблему, а если ничего не получится, соберет нужных людей, все объяснит и предложит альтернативы (скорее всего, есть другой внешний сервис с лучшей поддержкой). Такой разработчик видит проблему бизнеса и решает ее. Его задача закрыта тогда, когда он решил проблему бизнеса, а не когда во что-то уперся.

3: Пытается потратить минимальные усилия, получив максимальный результат, даже если придется писать костыли

Разработка софта в продуктовых компаниях – почти всегда самая большая статья расходов: разработчики стоят дорого. И хороший разработчик понимает, что бизнес хочет получить максимальное количество денег, потратив минимальное. Чтобы ему помочь, хороший разработчик хочет потратить минимальное количество своего дорогого времени для получения максимального профита работодателя.

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

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

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

Работа по принципам Getting Things Done – когда вы записываете все дела в какую-то текстовую систему, не забываете никаких договоренностей, всех пушите, везде вовремя появляетесь, знаете, что важно, что не важно в текущий момент, у вас никогда не теряются задачи. Общая характеристика таких людей – когда с ними о чем-то договариваешься, никогда не волнуешься, что они забудут; а также знаешь, что они все записывают и не будут потом задавать тысячу вопросов, ответы на которые уже обсуждались.

5. Ставит под сомнение и уточняет любые условия и вводные

Здесь тоже бывают две крайности. С одной стороны, можно скептически относиться вообще ко всем вводным. Люди до тебя придумали какие-то решения, а ты считаешь, что можно сделать лучше и начинаешь переобсуждать все вообще, что было до тебя: дизайн, бизнес-решения, архитектуру и т.д. Это тратит кучу времени как разработчика, так и окружающих, и негативно сказывается на доверии внутри компании: другие люди не хотят принимать решения, потому что знают, что вон тот чувак опять придет и все поломает. Другая крайность – когда разработчик воспринимает любые вводные, ТЗ и хотелки бизнеса как что-то высеченное в камне, и только упершись в нерешимую проблему начинает думать, тем ли он вообще занимается. Хороший разработчик тут тоже находит золотую середину: пытается понять решения, принятые до или без него, до того, как задача перейдет в разработку. Что хочет бизнес? Решаем ли мы его проблемы? Продакт-дизайнер придумал решение, но понимаю ли я, почему это решение будет работать? Почему тим-лид придумал именно такую архитектуру? Если что-то непонятно, значит, надо пойти спросить. В процессе этого выяснения хороший разработчик может увидеть альтернативное решение, которое до него просто никому не пришло в голову.

6. Улучшает процессы и людей вокруг себя

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

7. Отлично менеджит других, даже если не менеджер

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

8. Не воспринимает свои знания как догму, постоянно открыт к критике

Каждый может вспомнить коллегу с предыдущей работы, который неспособен идти на компромисс по отношению к своей технологии, кричит, что все сгорят в аду за какие-то не те мутации. Хороший разработчик, если он работает 5, 10, 20 лет в индустрии, понимает, что у него половина знаний протухла, а в оставшейся половине он не знает в десять раз больше, чем знает. И каждый раз, когда с ним кто-то не соглашается и предлагает альтернативу, это не атака на его эго, а возможность чему-то научиться. Это позволяет ему расти намного быстрее, чем окружающие.

Сравним мое представление об идеальном разработчике с общепринятым:

На этой картинке видно, сколько пунктов из описанных выше имеют отношение к коду, а сколько нет. Разработка в продуктовой компании – только на треть программирование, остальные 2/3 к коду имеют мало отношения. И хотя кода мы пишем реально много, наша эффективность сильно зависит от этих «не имеющих отношения» двух третей.

Специализация, генерализм и правило «80-20»

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

Правило «80-20» говорит нам, что 80% результата достигаются за счет 20% усилий. 80% выручки приносят 20% клиентов, 80% прибыли генерят 20% сотрудников и так далее. В обучении это значит, что 80% знаний мы получаем за первые 20% потраченного времени.

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

Итого: можно потратить 100% времени на изучение какого-то навыка до предела, а можно то же время потратить на пять областей, прокачавшись на 80% в каждой. Следуя этой наивной математике, мы можем за одно и то же время получить в четыре раза больше навыков. Это утрирование, но оно иллюстрирует идею.

Смежные скиллы можно тренировать не на 80%, а на 30-50%. Потратив 10-20 часов, вы заметно прокачаетесь в смежных областях, получите массу понимания происходящих в них процессов и станете намного автономнее.

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

Ну и, наконец, обучение – это инвестиция, а в инвестициях важна диверсификация.

Что учить

Так что же учить и как? Типичный разработчик в сильной компании регулярно использует:

• общение
• самоорганизацию
• планирование
• дизайн (как правило, кода)
• и иногда менеджмент, лидерство, анализ данных, писательство, найм, менторство и многие другие навыки

И практически ни один из этих скилов никак не пересекается с самим кодом. Их надо учить и прокачивать отдельно, и если этого не делать, они останутся на очень низком уровне, не позволяющим их эффективно использовать.

В каких областях стоит развиваться?

1. Софт-скилы – это все, что не касается нажиманий на кнопки в редакторе. Это как мы пишем сообщения, как ведем себя на встречах, как общаемся с коллегами. Вроде все очевидные вещи, но очень часто их недооценивают.

   
   

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

   
   

3. Проактивность, непредубежденность и планирование. Темы сильно общие и жизненные, не уникальные для IT, и развивать их стоит всем. Проактивность – значит не ждать сигнала, чтобы начать действовать. Ты сам источник событий, а не реакций на них. Непредубежденность – умение объективно относиться к любой новой информации, оценивать ситуацию в отрыве от собственного мировоззрения и старых привычек. Планирование – ясное видение того, как сегодняшняя задача решает задачу на неделю, месяц, год. Если видеть перспективу дальше конкретной таски, намного проще заниматься тем, что нужно, и не бояться по прошествии времени осознать, что оно было потрачено впустую. Этот навык особенно важен для карьеры: можно годами успешно достигать результатов, но не там, где надо, и в итоге потерять весь накопленный багаж, когда станет ясно, что двигался не туда.

   
   

4. Все смежные сферы до базового уровня. Конкретные сферы у каждого свои, но важно понимать, что, потратив 10-20 часов времени на прокачку какого-то «инородного» скила, можно открыть для себя много новых возможностей и точек соприкосновения в повседневной работе, и этих часов, возможно, хватит до конца карьеры.

   
   

Что почитать

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

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

2. Стивен Р. Кови «7 навыков высокоэффективных людей». Микс разных навыков, от проактивности до софт-скилов, с акцентом на достижение синергии, когда надо небольшую команду превратить в огромную силу. Читается также легко.

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

4. Дэвид Аллен «Как привести дела в порядок». Обязательно чтение для обучения самоорганизации. Читать ее не так просто, но она дает исчерпывающий набор инструментов для организации жизни и дел, детально рассматривает все аспекты, помогает решить, что нужно именно тебе. Я с ее помощью выстроил свою систему, позволяющую всегда заниматься самым важным, не забывая об остальном.

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

Let's block ads! (Why?)