Techlead Skyeng Кирилл Роговой (flashhhh) выступает на конференциях с докладом, в котором рассказывает о навыках, развивать которые стоит каждому хорошему разработчику, чтобы стать лучшим. Я попросил его поделиться этой историей с читателями Хабры, передаю Кириллу слово.
Миф про хорошего разработчика гласит, что он:
- Пишет чистый код
- Знает много технологий
- Быстрее кодит задачи
- Знает кучу алгоритмов и шаблонов проектирования
- Умеет отрефакторить любой код по Clean Code
- Не тратит время на непрограммистские задачи
- 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% времени мы пользуемся не то чтобы базовыми, но точно не самыми изощренными скилами, и этого достаточно даже в кодинге, даже в крутых компаниях.
Ну и, наконец, обучение – это инвестиция, а в инвестициях важна диверсификация.
Что учить
Так что же учить и как? Типичный разработчик в сильной компании регулярно использует:
- общение
- самоорганизацию
- планирование
- дизайн (как правило, кода)
- и иногда менеджмент, лидерство, анализ данных, писательство, найм, менторство и многие другие навыки
И практически ни один из этих скилов никак не пересекается с самим кодом. Их надо учить и прокачивать отдельно, и если этого не делать, они останутся на очень низком уровне, не позволяющим их эффективно использовать.
В каких областях стоит развиваться?
Софт-скилы – это все, что не касается нажиманий на кнопки в редакторе. Это как мы пишем сообщения, как ведем себя на встречах, как общаемся с коллегами. Вроде все очевидные вещи, но очень часто их недооценивают.
Система самоорганизации. Лично для меня за последний год это стало супер-важной темой. Среди всех известных мне крутых работников сферы IT это один из самых развитых скилов: они супер-организованы, они всегда делают то, что говорят, они точно знают, чем будут заниматься завтра, через неделю, через месяц. Необходимо строить вокруг себя систему, в которой записаны все дела и все вопросы, это существенно облегчает и саму работу, и сильно помогает взаимодействовать с другими людьми. По моим ощущениям, за последний год развитие в этом направлении прокачало меня намного сильнее, чем прокачка технических навыков, я стал выполнять значительно больше работы за единицу времени.
Проактивность, непредубежденность и планирование. Темы сильно общие и жизненные, не уникальные для IT, и развивать их стоит всем. Проактивность – значит не ждать сигнала, чтобы начать действовать. Ты сам источник событий, а не реакций на них. Непредубежденность – умение объективно относиться к любой новой информации, оценивать ситуацию в отрыве от собственного мировоззрения и старых привычек. Планирование – ясное видение того, как сегодняшняя задача решает задачу на неделю, месяц, год. Если видеть перспективу дальше конкретной таски, намного проще заниматься тем, что нужно, и не бояться по прошествии времени осознать, что оно было потрачено впустую. Этот навык особенно важен для карьеры: можно годами успешно достигать результатов, но не там, где надо, и в итоге потерять весь накопленный багаж, когда станет ясно, что двигался не туда.
Все смежные сферы до базового уровня. Конкретные сферы у каждого свои, но важно понимать, что, потратив 10-20 часов времени на прокачку какого-то «инородного» скила, можно открыть для себя много новых возможностей и точек соприкосновения в повседневной работе, и этих часов, возможно, хватит до конца карьеры.
Что почитать
Книг про самоорганизацию великое множество, это целая индустрия, где какие-то непонятные ребята пишут сборники советов и собирают тренинги. При этом неясно, чего они сами в жизни добились. Поэтому важно ставить фильтры на авторов, смотреть, кто они такие, и что у них за плечами. На мое развитие и кругозор больше всего повлияли четыре книги, все они так или иначе связаны с прокачкой описанных выше навыков.
1. Дейл Карнеги «Как завоевывать друзей и оказывать влияние на людей». Культовая книга про софт-скилы, если непонятно, с чего начать, выбрать ее – беспроигрышный вариант. Построена на примерах, легко читается, не требует больших усилий для осмысления прочитанного, и полученные навыки можно сразу же применять. В целом, книга раскрывает тему общения с людьми.
2. Стивен Р. Кови «7 навыков высокоэффективных людей». Микс разных навыков, от проактивности до софт-скилов, с акцентом на достижение синергии, когда надо небольшую команду превратить в огромную силу. Читается также легко.
3. Рэй Далио «Принципы». Раскрывает темы непредубежденности и проактивности, основана на истории построенной автором компании, которой он управлял 40 лет. Множество жизненных выстраданных примеров, здорово показывает, насколько предубежденным и зависящим может быть человек, как от этого избавиться.
4. Дэвид Аллен «Как привести дела в порядок». Обязательно чтение для обучения самоорганизации. Читать ее не так просто, но она дает исчерпывающий набор инструментов для организации жизни и дел, детально рассматривает все аспекты, помогает решить, что нужно именно тебе. Я с ее помощью выстроил свою систему, позволяющую всегда заниматься самым важным, не забывая об остальном.
Надо понимать, что только читать – мало. Можно проглатывать хоть по книге в неделю, но эффект будет сохраняться несколько дней, а потом все вернется на место. Книги надо использовать как источник советов, которые сразу же проверяются на практике. Если этого не делать, то все, что они дадут – это некоторое расширение кругозора.
Комментарии (68)
iit
07.06.2019 13:35+1Такие требования вполне применимы к Senior/TeamLead/TeachLead и да естественно они хорошие разработчики.
Maksclub
08.06.2019 16:39Для джуниора тоже хороши, тк могут дать разработчику дополнительную ценность, дополнительное value в работе и в глазах коллег/бизнеса. Всегда стараюсь прощупать — какую ценность представляю и что могу сделать. На позапрошлой работе благодаря этому выторговал 3 раза повышение зп (хотя смотрю назад — все копейки), на прошлой тоже получилось нащупать, но спустя месяца 4 только… Я далеко не сеньор и не тимлид, да и мидл начинающий
alsii
08.06.2019 20:45+3мне вот тоже подумалось. если некто не будет кодить вообще, но будет заниматься всем, что в статье написано, он в принципе уже будет неплохой… менеджер ;-)
defaultvoice
07.06.2019 13:51+4Короче, отличный разработчик умеет всё и вообще непонятно, зачем ему куда-то на работу устраиваться
codecity
07.06.2019 14:52+5Вот это ключевой вопрос. Если он обладает навыками управления, навыками (само)организации, способен вникать в проблему — нафига ему работать на чужой кошелек? Понятно что максимум подкопит деньжат и свалит делать свой проект.
flashhhh
07.06.2019 16:24+2Так ведь это и прекрасно. :)
Мы же не хотим сказать, что хороший разработчик лишен желания перерасти свою компанию или создать свою? Это абсолютно нормально, что лучшие сотрудники со временем уходят достигать высот, которых не смогли достичь в текущей компании.
Наивно утверждать «почему, мол, если такой крутой, то саму компанию не вытащит на новый уровень?», когда помимо него еще 100 человек принимают тысячи решений в день.
Более того, я считаю, что это прекрасно для всей индустрии. Ведь когда компания понимает, что альтернатива для их ценнейших кадров — идти строить свои продукты, условия для них растут соответственно (до тех пор, пока сотрудник окупается, конечно).
snp
07.06.2019 17:07+2А кто будет продавать проект? Деньги-то из ниоткуда не приходят, а кушать хочется. Даже если проект будет супер крутой и инновационный, то нужно рассказать об этом людям, найти и убедить инвесторов, сделать сайт и обновлять там новости, ходить на конференции, прилично одеваться. Чтобы это всё сделать, придётся отложить разработку.
Да, можно делегировать, но чтобы найти людей, которым можно это делегировать, то опять надо отложить разработку.
Даже если люди найдены, то нужно наладить и поддерживать процессы в новой компании, транслировать идеи и смыслы сотрудникам и опять для этого надо отложить разработку.
А если он и так хорошо получает, занимается интересным делом и получает удовольствие от работы (которую он и работой не называет даже), то зачем ему ввязываться в это всё и ради чего?
ukt
07.06.2019 18:12Где то выше в тексте было ключевое «подкопить».
Инвестиции требуются в масштабные и глобальные проекты, где нужна дикая инфраструктура. Для того, что бы пилить проект из инвестиций нужен комп и инет, крыша над головой, разумеется.
Не постоянно же делегировать, есть моменты про реперные точки, но они и так есть, только свои, теперь это точки делегируемого.
Если процессы нужно постоянно поддерживать, это не процессы.
Вы не поверите, но на наёмной работе ты не сможешь пилить свой проект, времени свободного не хватит, а хочется, и не просто пилить, а допустим, решить какую то глобальную/важную для себя проблему. Пиление фичей, это всё таки про пиление фичей — 100500 мини проектов. Это важный момент, но есть ещё один — компания может требовать каких то условий, вроде «работая на нас все патенты/идеи/ваша кошка/и ваша шкура — наши», что уже серьёзно подрывает перспективы проекта.
Fedorkov
08.06.2019 14:04+1Устроиться в интересный проект гораздо проще, чем самостоятельно отхватить кусок рынка, тем более — интересного.
Ontaelio Автор
07.06.2019 23:57+5Терпел весь день, теперь отвечу. Я дважды «сваливал делать свой проект». Я, конечно, не разработчик, но опыт управления коллективом у меня был, даже коллектив был, и «деньжат подкопил», казалось, вперед и с песней.
Проблема в том, что пока ты работаешь на дядю, даже если следуешь рекомендациям Кирилла, твой скилл «менеджмента» на уровне, ну, допустим, 50%. А основа — твоя профессия (в моем случае — журналистика и редактура). Внутри своей сферы ты умеешь управлять и выдавать качественный продукт. Но даже если в дополнение ты умеешь общаться с партнерами, они даже готовы дать тебе денег и яростно тебя поддерживают, то, оказавшись в открытом море, ты обнаруживаешь там акул, о существовании которых не подозревал. Они скрывались в оставшихся 50% скила менеджера. Банки, налоговая, бухгалтерия, документооборот, юристы, [то, о чем писать нельзя], дивный новый мир.
И ты прекращаешь заниматься тем, что тебе нравится, и начинаешь заниматься откровенной хренью, потому что больше некому. Когда в результате это дает тебе чистый доход на 20% больше твоей старой з/п, то ну к лешему, я лучше буду получать удовольствие от работы. А по опыту это и прибавки никакой не дает, только головную боль.
Идея Кирилла не только в том, чтобы помочь «дяде» (бизнесу). Помогая дяде, ты помогаешь себе, это вин-вин. И да, если тебя пропрет, возможно, ты созреешь для своего дела. Вон у нас есть один управляющий партнер, пришел из Яндекса, «накопил деньжат», сохранил прекрасные отношения с ним.jacob1237
08.06.2019 15:46Может для профессионала в сфере журналистики упомянутые "акулы" в виде "Банки, налоговая, бухгалтерия, документооборот, юристы" и представляют проблему, но для "лучшего разработчика", который обладает всеми перечисленными в статье качествами, это не является чем-то сверхсложным.
Разработчики постоянно работают с новыми знаниями, потому что программирование — это прикладная дисциплина, в которой надо еще и предметной областью владеть. Нередки случаи, когда один программист на предприятии может делать работу сразу нескольких специалистов разных департаментов.
Так что в этом контексте вопрос "зачем такому разработчику вообще работать на кого-то" актуальности, отнюдь, не теряет.
P.S. Если Ваша предпринимательская деятельность дает Вам всего-лишь на 20% больше чем зарплата, скорее всего Вы что-то делаете не так
NeverIn
08.06.2019 20:03+1Помогая дяде, ты помогаешь себе
Это спорный вопрос. В краткосроке дядя возможно кинет какой кусок для мотивации, но в долгосроке дядя остается с продуктом, а ты с голым задом.
agent10
07.06.2019 13:58+1В современной экосистеме IT лучше иметь как можно больше навыков и не быть ни в одном из них экспертом
Какая чушь.rzerda
07.06.2019 14:48+7Я сначала внутренне согласился, а потом подумал. Современное IT (из того, что на виду) в большинстве своём про «сделаем как Uber, только Tinder», т.е. ничем сильно важным не занимается, и делать там хорошо не имеет смысла. Пусть как-то работает, а потомки разберутся, если доживёт.
EvgeniiR
08.06.2019 13:16Современное IT (из того, что на виду) в большинстве своём про «сделаем как Uber, только Tinder», т.е. ничем сильно важным не занимается, и делать там хорошо не имеет смысла. Пусть как-то работает, а потомки разберутся, если доживёт.
А теперь осталось посмотреть статистику, сколько проектов из "Современного IT" до следующего нового года не доживает, не говоря уж о поколениях.
Ну и да, по моему опыту, пол годика работы пары фрилансеров джунов(причем имеющих лет по 5 опыта) хватит чтобы проект превратился в плохо расширяемое легаси(это все относительно конечно, но эффект будет значительный и долгий)
epishman
07.06.2019 14:13+1> Отлично менеджит других, даже если не менеджер
Из личных наблюдений — такой человек никогда не пойдет в программисты, уже со школы-института он будет волонтером/журналистом/продавцом/аудитором/комбатом, кем угодно, но не технарем. Глубокими технарями становятся именно те, кто не имеет возможности построить широкие социальные связи, особенно у нас, где монетизация связей на порядки превышает монетизацию любых технических компетенций.flashhhh
07.06.2019 16:27+1Не могу говорить за всех, но примеры вокруг меня (и мой в том числе) такие: начал карьеру разработчиком по канону — пишешь код, закрываешь таски, repeat; а через пару-тройку лет начало доходить, что приносит пользу, что — нет и как расти быстрей.
snp
07.06.2019 17:20+1Глубокими технарями становятся именно те, кто не имеет возможности построить широкие социальные связи
Это почему же? Вы хотите сказать, что технари это ущербные люди и если бы не их недостатки, то они бы занимались чем-то более приличным? :)
К тому же навык менеджмента можно прокачать, для него не надо строить социальные связи не надо. Можно даже через чатик и таски менеджерить.
epishman
07.06.2019 17:37+6Никто не ущербен, просто менеджмент — это другая планета навыков, через чатик и джиру менеджировать, плюс стэндапы вести — это не менеджмент вообще, а секретарская работа. Менеджмент — это «to make other people to work», и даже если у Вас полно денег чтобы платить — не факт что люди будут работать на Вас, и хорошо. Очень трудно быть боксером и гитаристом одновременно, хотя отдельным людям это доступно.
snp
07.06.2019 23:21+3Либо качок, либо умный?
Менеджмент — это «to make other people to work»
Cambridge dictionary даёт простое определение: «the control and organization of something». Откуда ваша фраза — я не знаю.
Если почитать исходную статью, то:
«Хороший разработчик знает, кто в чем заинтересован, может собрать с этими людьми встречу, записать договоренности, скинуть в слак, напомнить в нужный день, убедиться, что все готово, даже если он лично не несет непосредственной ответственности за эту задачу, но его результат зависит от ее выполнения.»
Так вот, за долгие годы работы я видел таких людей (ну и сам бывал в такой роли). Таких — мало.
Большинство это реактивные (в плохом смысле) разрабы. Чуть иссяк поток тикетов, так сразу лапки свесили. Которым по барабану, что они делают и зачем. Которые каждый день приходят «работать на дядю» и пользуются любым моментом чтобы увильнуть от работы. Если бы в IT индустрии существовали профсоюзы, то такие в первых рядах ломанулись бы в них вступать.
Так вот, вопрос — что мешает «глубокому технарю» попинать в чатике или лично всех ответственных и блокирующих? Только ли «социальные связи» или просто mindset?
epishman
07.06.2019 23:46+1Ежедневно пинать разрабов в чатике — это дно менеджмента. Построить систему, где люди сами пинают друг-друга, пока я два месяца лежу на пляже — это мидл-уровень. Построить систему, в которой люди сами строят систему, внутри которой могут пинать друг-друга вечно — это высокий уровень. Сделать так, чтобы люди при этом были счастливы — вершина.
PS
Ваши технари лапки свесили именно потому, что система, построенная менеджерами — плохая, слабая. Технократия в управлении (джира, тикеты и стендапы) — это и есть главное зло, когда люди привыкли что их ежедневно воскрешают к жизни электрошоком, вместо того, чтобы просто оставить в покое хотя-бы на неделю.alsii
08.06.2019 20:56Построить систему, в которой люди сами строят систему, внутри которой могут пинать друг-друга вечно — это высокий уровень.
Это уже не менеджмент. Это консалтинг в области менеджмента.
Сделать так, чтобы люди при этом были счастливы — вершина.
А вот это даже господу богу пока не удается :)
epishman
08.06.2019 21:06+1А вот это даже господу богу пока не удается :)
Что наводит на мысль «а был ли мальчик».
QtRoS
08.06.2019 14:52Ну нет, это очень сдвинутая оценка. Как минимум есть исключения, могу рассказать на своем примере — я ярко выраженный экстраверт, предпочитаю решать вопросы дипломатией, часто просто личным разговором, а не какой-нибудь заявкой, легко строю связи со смежными подразделениями, но программировать, решать технические задачи и делать что-то своими руками я люблю больше. Как-то я в программистах оказался, никто за ручку не привел :)
jevius
07.06.2019 14:18+1Одно лишь чтение подобных статей — вот что точно не сделает тебя топовым разработчиком
Grigorenkovic
07.06.2019 14:37«Хороший разработчик, столкнувшись с такой ситуацией, сам найдет контакты, спишется-созвонится, обсудит проблему, а если ничего не получится, соберет нужных людей, все объяснит и предложит альтернативы»,… «всех пушите» — это уровень совладельца компании, или хотя-бы крупного акционера. Прямо не человек, а золото. Хороших похвалит, плохих исправит, больных вылечит, голодных накормит.
GarfieldX
10.06.2019 09:50Утрировать не стоит. В чем такая сложность? Если в прилетевшей заявке были контакты заявителя и была такая необходимость, то связывался напрямую. Зачем в испорченный телефон "играть"? Смысл пинать заявку туда-сюда, если все равно ко мне вернётся? И, да, если возникали сложности, то сначала логично обсудить с начальством, а потом уже действовать.
agent10
07.06.2019 14:45+11Ощущение, что началась эра создания «эффективных разработчиков».
«Эффективные менеджеры по продажам» в skyeng уже созданы, мне звонили два разных в течение одной минуты. Лучше с ними разберитесь и оставьте разрабов в покое уже.epishman
07.06.2019 17:50+1Пожелание работодателей совершенно понятно, но у разработчиков могут быть иные мнения. Я вот например когда вижу в описании вакансии «в нашей команде идеальный тайм-менеджмент, скрам, джира и канбан» — остерегаюсь, ибо свое время я хочу менеджировать сам :)
APXEOLOG
07.06.2019 15:00Потратив 10-20 часов, вы заметно прокачаетесь в смежных областях, получите массу понимания происходящих в них процессов и станете намного автономнее.
Если это единовременно, то сомневаюсь
Ontaelio Автор
08.06.2019 00:38Речь о том, чтобы изучить основы, понять боли смежных областей и постараться им их не создавать. Ну вот, например, если дизайнер, выпускник Суриковского института, т.е. строго художник, потратит 10-20 часов на освоение Hello World, он, возможно, будет в состоянии понять устройство файла SVG. И тогда он сможет подсказать программистам фронт-энда, как оптимизировать меняющие цвет под контекст иконки. То же самое сделает программист, потративший 10-20 часов на изучение азов дизайна.
И признаюсь: это не условный пример, это реальный кейс.
A114n
07.06.2019 15:01+9Поэтому важно ставить фильтры на авторов
Полностью согласен.
Вот я если вижу статью, в которой советуют почитать Карнеги или Кови — сразу понимаю, что от других советов этого автора мне лучше держаться подальше.reki
07.06.2019 15:22Вот я если вижу статью, в которой советуют почитать Карнеги или Кови — сразу понимаю, что от других советов этого автора мне лучше держаться подальше
Лучше держаться подальше потому, что автор советует жуткие банальности (т.е. предлагать почитать Карнеги или Кови это всё равно что предлагать букварь) или потому, что он советует плохие, переоцененные вещи, на которые вообще не стоит тратить время?cross_join
07.06.2019 15:26+5Карнеги советует приемы, которые многие люди не используют не потому, что не знают, а потому, что в их культуре они считаются неприличными. Т.е. смысл книги в том, чтобы освободиться от груза этики.
epishman
07.06.2019 17:54+1Золотые слова. Я могу дополнить, хотя такое мнение нелюбимо на хабре — использование ИИ в отдельных направлениях (экзамены, найм персонала, маркетинг, реклама и PR) — оно тоже неэтично, и, в идеале, должно быть ограничено конвенциями, как химическое оружие или эксперименты с эмбрионами.
reki
08.06.2019 11:02Этика — это система устоявшихся правил общественной жизни, формирующая предсказуемые и «приемлемые» паттерны поведения для членов этого общества в определенной окружающей среде. И когда окружающая среда будет включать в себя ИИ в качестве неотъемлемой части, то и этические нормы адаптируются под такие изменения.
epishman
08.06.2019 12:39Это понятно, но в итоге это убъет данные дисциплины, как уже происходит с журналистикой и блоггингом. Одно дело, когда с экрана вам вещает конкретный человек, и вы знаете кто это, и можете проследить его поступки в прошлом, а другое дело когда все новости вам будет зачитывать персонаж ИИ, каждый раз с разным лицом, доверие к таким сми будет примерно ноль, дальше возникнет фронда, альтернативные медиа, альтернативный рекрутинг, и т.д. Все эти технологии возможно будут работать лишь на самом дне общества и среди детей, примерно как сейчас работает умирающее телевидение среди стариков.
reki
08.06.2019 18:09Все те вещи, о которых Вы упоминали (экзамены, найм персонала, маркетинг, реклама и PR) сформировались в привычном нам виде в том аналоговом мире без мгновенного произвольного доступа практически к любой информации, когда ценились в первую очередь доступ к информации и возможность ее сбора и накопления. А сейчас ценностью становятся способность отфильтровывать информационный шум и выделять полезный сигнал. Так что альтернативные формы неизбежны, на мой взгляд.
ibetsm
09.06.2019 13:33Воспринимать серьезно в XXI веке книги Карнеги вы серьезно? Социальные связи между людьми слишком сложны и многогранны, не существует каких либо паттернов. Уровень критического мышления на хабре падает. Вот недавний пост «Ответ психиатра на статью «Болен-здоров»». Человек на серьезных щах втирает про НЛП. Может быть я тупой и объективно не понимаю окружающую реальность?
cross_join
07.06.2019 15:02+6Ищут пожарные,
Ищет милиция,
Ищут фотографы
В нашей столице,
Ищут давно,
Но не могут найти
Парня какого-то
Лет двадцати.
Среднего роста,
Плечистый и крепкий,
Ходит он в белой
Футболке и кепке.
Знак «ГТО»
На груди у него.
Больше не знают
О нем ничего.
JustDont
07.06.2019 15:50Хороший разработчик умеет создавать классную архитектуру, писать классный код, не делать слишком много багов; в общем, у него все получается лучше среднего, но он не входит в топ-1% специалистов.
Топ-1% чего? Среднее что? Каким именно критерием вы тут ранжировать разработчиков пытаетесь?
dss_kalika
07.06.2019 15:50+2Хорошие советы.
Но большая часть сводится к «ищите баланс между плохими паттернами или стремлением к идеалу», а остальная — свойство самого человека (те, кто им обладают — им обладают, а кто нет — не смогут в себе воспитать, скорее всего).
9. Расширяйте свои границы. Технологий, компетенций, опыта, знакомств. Любой выход за границы уже изученного и освоенного полезен.
zim32
08.06.2019 10:21Нормальная статья. Начинающим разрабам как посыл как им вырасти по карьерной лестнице а продукт компании. Часто многие упираются и не могут понять чего от них хотят. Тут вроде все по полочкам. Ну если конечно есть цель рубить больше бабла, а не просто заниматься интересным делом.
EvgeniiR
08.06.2019 12:58+2Автор смотрит на ситуацию исключительно со стороны менеджера, а о задачах, целях, ответственности разработчика даже не задумывается, потому вся задача разработки для него -"кнопочки жать за компом".
Можно много критики написать, но любому разработчику это будет очевидно. В целом — то что задача бизнеса решена и фича работает без багов вовсе не означает что задача сделана хорошо, качественно, и эту фичу можно будет развивать и поддерживать. А развиваться и делать лучше можно сколь угодно, и это будет окупаться с развитием проекта.
Как реакция на таких вот менеджеров была мною написана вторая статья на этом ресурсе, и компромиссы, о которых ни слова в этой статье (потому мне кажется что автор в принципе далёк от разработки более менее серьёзных проектов), я там упоминал.
Fedorkov
08.06.2019 14:27+1Как завещал Юдковский, человек берёт ответственность за всё, что происходит вокруг него, а уже из этих приоритетов у гика рождаются софт-скиллы, самоорганизация и прочая магия.
На редкость толковая статья. Только полезность упомянутых книжек, имхо, сомнительна.
eshirshov
09.06.2019 12:46+1До светла все у него пляшет,
Лошадь запряжет, полосу вспашет,
Печь затопит, все заготовит, закупит,
Яичко испечет да сам и облупит.
Scf
09.06.2019 13:04+1Это всё хорошо и правильно, но отнимает много времени, которое можно было бы потратить на любимое дело — на программирование.
Программист с развитыми навыками менеджера — золотое дно для компании и первый кандидат на повышение в должности и зарплате. Но придется отказаться от программирования.
shipovfoto
09.06.2019 13:33Спасибо за статью, в некоторых пунктах узнаю себя, а в некоторых вижу реальные зоны роста. Пару книг из Вашего списка давно хотел прочитать, да руки не доходили.
Можно добавить,
9. Постоянно учится.
10. Следит за новыми технологиями.
RVstudent
09.06.2019 13:34лично меня в кодеры из манагеров надуло, насчёт карнеги камчу кину по лбу(кочевники так открывают спор). напрягает мнение, что смысл моего сушествования в создании всяческих удобств для вышестоящих органов, комформизм в кубе. я бы пошёл от познания себя любимого, начиная с популярного, типа «анна каренина сука» никонова. Куча скилов не спасёт от внутреннего перегорания, не стоит на задачу и баста
pyrk2142
Я бы добавил ещё один пункт:
9. Получает зарплату заметно больше среднего.
Иначе зачем работать больше, выполнять все, что написано выше, когда за похожую зарплату в этой компании можно прийти на работу, поболтать, попить кофе, посидеть немного, чуть-чуть покодить, сходить покурить, ещё покодить, а вот и обед настал, потом ещё немного работы, полдник, прощание со всем и дорога домой.
Не удивлюсь, если в куче компаний есть много неэффективных разработчиков, которые легко могли бы стать хорошими, если бы получали за это что-то.
ralder
высокая зарплата это следствие этих действий, а не наоборот :)
vowantuz
Полагаю, что в определённый момент разработчику будет всёравно и он просто станет тянуть лямку за те деньги что получает, а не пытаться работать больше и лучше, что-бы может быть получить зарплату по больше. А потом может и уйдёт вовсе.
NeverIn
Нет, это часть внешней мотивации.
Знаете как в поговорке «лучше всех в колхозе работала лошадь но председателем так и не стала».
Так вот ровно это же и по деньгам.
Fedorkov
Это всё из-за слабых софт-скиллов лошади.
NeverIn
Ну да, лошади с ослом нужно было нежнее общаться )
AstarothAst
Опять лошадь виновата.
MaxVetrov
Это зависть.
MaxVetrov
Председателем и гусь не станет, потому, что он думает только о себе))
Sergey_Kovalenko
А причина упомянутых действий — возможность получать большее вознаграждение.
dss_kalika
обычно после этих манипуляций уже не обед, а конец рабочего дня ))