Хабрахабр

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

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

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

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

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

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

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

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

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% в каждой. Это утрирование, но оно иллюстрирует идею.

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

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

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

Что учить

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

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

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

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

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

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

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

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

Что почитать

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

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

Кнопка «Наверх»
Закрыть