image Недавно я задумывался об идее сервиса для категоризации разработчиков при найме или уже работающих в существующих командах. Такие системы существуют и гордо именуются директора эйчары. Кого нанимать зависит от типа компании: стартап или корпорация. В первом случае будут эффективны одни наборы программистов, во-втором могут быть совершенно иные, и этот пост про классификации программистов на уровне моих субъективных ощущений, это не упорядочивание уровня джуниор/мидл/сеньор или бекенд/фронтенд/мобайл, — скорее обобщенные образы из комбинации компетенций, вовлеченности, миссии и тд.

Эта статья носит немного шутливый характер, поэтому сначала я разделил всех на 2 стороны. Светлая и темная, и назвал их конструкторы и деструкторы. Это понятие характеризует их влияние на команду и разрабатываемый продукт, и не коррелирует с техническими компетенциями.

Типы программеров

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

Рокстар

Одно его появление в составе команды увеличивает шанс стартапа на N%

Я работал с несколькими разработчиками, которых можно было записать в категорию “Рокстар” и их объединяет одно удивительное качество — они умеют заряжать. Это образ полубогов, для которых нет невыполнимых задач, архитектурные, кодовые и любые технические таски они разделывают подобно Нео, раскидывающего вирус Смита по окрестностям квартала. Делают они это легко, с беззаботной улыбкой и некоторой долей лени, что отвлекают его от просмотра роликов на ютубе или обсуждения пончиков на кухне. Они не хвастаются своими достижениями, все уже доказано, а авторитет давно завоеван. Они могут не управлять командами, и не быть тимлидами, осуществляя евангелистическую функцию — помогать любым разработчикам правильно и грамотно решать задачи и писать код, а также создавать самые сложные компоненты в системе, писать ядра и основы продукта в компании.

Часто предоставлены сами себе и пишут то, что считают нужным, так как находятся на уровне высокой компетенции. У них большой энтузиазм, разносторонне развитое мышление и эрудиция, как в языках программирования так и общая, высочайший уровень компетенций в теоретическом computer science и в количестве, выполненных проектов. Пишут код быстро и качественно, на ходу решая стоит ли писать тесты или делаем код ревью по-быстрому. Хорошо относятся к ревьювингу своего кода и критике, активно спрашивают у команды вещи, в которых не разбираются. Обычно, это еще и очень талантливые люди. Как правило неплохо разбираются и в смежных областях от Ux до математики и могут работать над созданием новых фич, идей и продуктов.

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

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

Сторона силы — NaN(конструктор или деструктор). 10/10

Джедай-перфекционист

Лучше писать отличный код в хреновом проекте, чем хреновый код в крутом

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

Лучший кандидат на написание внутренних библиотек или фреймворков, общих компонентов или мидлвэйр. Скорее всего он идеально подойдет на роль мейнтейнера ваших пакетов на github. Он будет скрупулезно комментировать сложные моменты и грамотно оформлять документацию, тесты, README.md и тд.

Хорошо подходят в любую команду, особенно, где наблюдаются проблемы с кодовой базой и общими низкими компетенциями команды. В описанном виде врядли впишется в стартапы на ранних стадиях жизни. Работают в основном над техническими проблемами, очерчивая свою зону отвественности и компетенций.

Сторона силы — конструктор 8/10

Вечный подмастерье

Полтора джуниора или программер-ефрейтор

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

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

По стороне силы его сложно отнести к деструкторам, потому что он рад взаимодействовать с командой и хорошо выполняют поручения и требования к коду, но и затраты на контроль и возню с ним большой, так как нельзя надеятся, что без ошейника они сделают все что требуется на 100%. От него трудно добиться своего видения, а если оно и будет, то с оглядкой на чужие мнения. Каждый шаг проектирования он будет сверять с тимлидом. От него вы не добьетесь собственных идей по продукту или вовлеченности.

Разработчики этого класса привыкли, что за них принимают решения, каждую строку ревьювят и подтверждают, что все правильно или нет. В целом они пишут достаточно неплохой код под контролем старшего разработчика и менеджера. Лучший вариант для развития — апнуться в один из других “конструктивных” типов путем наращивания отвественности за проектные детали.

Для стартапов однозначно нет, но в корпорации такие люди могут вырасти из новичков-джунов.

Сторона силы — undefined(конструктор и деструктор одновременно) 4/10

Дефолтный или средний

Офисный клерк из мира программирования

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

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

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

Сторона силы — констурктор 6/10

Старовер

Во времена, когда мамонты ходили по земле мы были рок звездами

Один из сложнейших типов. У него есть дуальность стороны силы, и однозначно сказать конструктор он или деструктор невозможно. Разница в способности обучаться и принимать в свой рабочий процесс новые библиотеки, технологии, языки программирования. Староверы используют десятилетиями одни и те же подходы и инструментарий, навыки владения которыми довели до совершенства. Как правило они не заставляют других работать по своим методологиям, но ревностно относятся и защищают свой выбор, сделанный много лет назад. У них всегда есть аргументы, почему старые и надежные технологии стоит использовать и лучший их аргумент — время на изучение новому. Примечательно, что сами перемены не даются им тяжело, в основе их аргументов лежит зрелое зерно — зачем тратить время на окружение и новые подходы, когда мы не использовали весь потенциал старых и не дошли до точки их неработоспособности и заниматься улучшением продуктов.

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

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

Сторона силы — NaN(или конструктор или деструктор)7/10

Темный эльф

Каста высших, непризнанных гениев

В качестве темной стороны джедая-перфекциониста я выделил классического непризнанного гения. Энакин Скайвокер в мире разработки.

Эго, эго, эго. Является деструктором эни вэй. Хард скиллы этого персонажа как правило прокачаны на максимум, но не хватает навыков работы в команде, восприятия критики, других софт скилз.

Они используют темную сторону разработки — любят играть с технологиями ради себя, внедрять библиотеку, чтобы развивать свои навыки, наплевав на требования бизнеса, удобства и инфраструктуры. Любители строить гениальную логику, трепетно защищая принципы Барбары Лисков. Топ 1 участники споров по архитектуре и метдологиям. Преследуют только свои цели в компании, а следовательно с ними трудно договариваться. Будучи хорошими специалистами, используют поступающие к ним проекты для раскачки своих навыков и в качестве полигона для экспериментов по улучшению собственных скиллов и раздувания эго.

Они всегда “правы” и как правило могут это доказать, даже если их аргументы прекрывают темную бездну собственных амбиций. Если их проект ломается от внесенных изменений, то это значит изменения не предусмотрены архитектурой и надо её переписывать. Если в проекте ошибки, то виноваты всегда кто-то, кто делает что-то не идеально из-за чего его код работает как-то не так. Вечный хейтер на чужой код и подходы. С такими разработчиками сложно договариваться, потому что их цели редко коррелируют с целями других разработчиков.

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

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

Сторона силы — деструктор 8/10

Смузи-кодер

“Ну мы хотим сделать progressive web app на react redux с instance на amazon , бекенды на elixir, с микросервисами на go и graphQL вместо rest, ну это только прототип, конечно mongodb”. Любители модные технологий, адепты фреймоворков, у которых воротит нос от легаси, для них легаси — это код, написанный пол года назад. Обычно это люди, которым искренне нравится щупать все модные фишки языков и технологий, они неплохо ориентируются в экосистемах, но не глубоко. Редко можно встретить смузи кодера пишущего 5 лет на C, 3 года golang и пару лет на ECMAScript2017. Обычно они неплохо ориентируются в одном выскоуровневом языке с динамической типизацией типа JavaScript и читают Getting started по модным технологиям, но являются неплохой движущей силой для разработчиков из разных команд, так как начинают говорить о новых вещах, заставляя кого-то с большим практическим опытом разобраться в новых подходах, переписать ядро чего-нибудь на новый язык и стать еще профессиональнее.

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

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

Стороны силы — конструктор 6/10

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