Вы можете любить или ненавидеть их, но вы не можете игнорировать их.
В течение моей профессиональной карьеры я работал с множеством различных типов разработчиков. Мне нравилось работать с некоторыми из них, но в работе с другими я только надеялся закончить проект и больше никогда не работать вместе.
В этой статье я перечислю некоторые типы этих разработчиков.
1. Продавец дыма
Этот тип разработчика всегда что-то кому-то обещает — заказчикам, вашим начальникам или другим разработчикам. Но когда что-то действительно нужно сделать, то если он может, он сбегает в другой проект или пытается спихнуть всю работу другим разработчикам. Продавец дыма очень опасен, так как может привести вас к серьёзным проблемам. Он продаёт продукт, который он и не собирается делать, с технологиями, которые никогда не использовал.
Если вы не знаете продавцов дыма, вы подумаете, что они знают всё, о чём говорят и что могут помочь вам. Но скоро вы поймёте, что это ложь и вы не можете рассчитывать на них.
2. Мультизадачный разработчик
Неплохой разработчик. Обычно этот тип обладает классными техническими навыками, но так занят, что никогда не фокусируется на чём-то одном и вы никогда не можете рассчитывать на него в проекте среднего размера. Получить его внимание довольно тяжело и хотя он иногда имеет блестящие идеи, требуется много усилий, чтобы убедить его что-то закончить.
3. Специалист с сертификатами
У меня пока нет большого опыта работы с данным типом разработчика, который всё измеряет своими сертификатами. Я думаю, что необходимо иметь хорошую базу с глубокими знаниями в области вашей работы. Я не против сертификатов. Но в большинстве случаев иметь сертификат, если это не подтверждено реальным опытом, не стоит многого.
Несколько лет назад клиент, которому я разрабатывал программное обеспечение, нанял архитектора программного обеспечения. Роль этого архитектора была в организации и руководстве всеми внешними разработчиками, работающими с клиентом.
Сперва я чувствовал себя хорошо в работе с ним, но вскоре я понял, что всё, что он делает было услышано в решениях других людей и он притворялся, что это были его собственные решения.
В моём случае, я потерял много времени на митингах, в которых он пытался изменить наши методы работы, но это базировалось на идеях, о которых он только читал или слышал, но не использовал на практике.
Конечно, сертификаты или степень в образовании это прекрасно, но только если это подтверждено реальным опытом, иначе вы становитесь разработчиком-теоретиком.
4. Неряшливый разработчик
Их код беспорядочен и не следует каким-либо хорошим практикам, смешивая все дизайны в одну кучу(если они где-то и прослеживаются).
Я работал с людьми, подобными этому типу. В конце планёрок я обычно спрашивал их есть ли у них какие-либо сомнения насчёт того, о чём мы говорили, потому что я видел, что они делали беспорядочные заметки на кусочке бумаги. Они всегда отвечали мне, что сомнений нет. Через несколько дней они разрабатывали что-то тотально отличное от того, о чём мы договорились на планёрке.
У вас может быть много ключей, чтобы распознать нерях:
Упорядочены ли их заметки?
Записывают ли они, чтобы не забыть?
Приведён ли их рабочий стол в порядок?
5. Разработчик-теоретик
Много теории, мало практики. Они всегда говорят остальным разработчикам как делать, но в большинстве случаев сами никогда не используют то, о чём говорят. Когда босс рядом, разработчики-теоретики хвастаются всем, что "знают", но ищут способы уйти с дороги, когда дело доходит до работы.
На одной из моих работ, был такой человек. Он был повсюду, рассказывая как мы могли бы делать вещи, но я редко видел его разрабатывающим что-то. Когда я получил его в напарники, я практически вынужден был объяснять ему как делать что-то.
6. Рядовой разработчик
Наиболее распространённый тип разработчика. Они имеют тенденцию быть средними во всём, что делают и обычно хотят иметь предсказуемые и комфортные задачи в их бэклоге.
7. Боязливый разработчик
Боязливые разработчики никогда не берут инициативу в свои руки. Они всегда ждут пока вы скажете им как нужно делать и какие технологии использовать или напомните что было сказано на митинге о той части, которую они разрабатывают. И если что-то пойдёт не так, они обвинят вас.
Они тратят много энергии и времени, чтобы не быть обвинёнными, если что-то пойдёт не так, вместо того, чтобы думать как сделать свою работу лучше.
Они всегда выбирают наиболее комфортный для них путь сделать свою работу, даже если есть лучшие альтернативы в решениях.
8. Универсальный разработчик
Отличный тип разработчика для большинства проектов. Как правило не обладает супер навыками во всём что знает, но может сделать любой проект. От бэкенда до фронтенда.
9. Нарцисс
Обычно имеют огромное эго и плохие командные навыки.
Они хотят, чтобы их рассматривали как лучшего разработчика в команде. Имеют тенденцию переусложнять простые вещи и используют хитроумный код, который более сложен для понимания другими членами команды. Если они ревьювят ваш код, они всегда пытаются отрефакторить и прокомментировать даже там, где это не является необходимым.
В другое время они рассказывают вам что что-то идёт не так и они позаботятся об этом, применяя что-то супергениальное. Но в конечном счёте, они не сдержат своих обещаний и когда начальник спросит у вас почему ваша задача провалилась, они ответит что предупреждали вас, что что-то пошло не так.
Вкратце, нарцисс - это человек, имеющий высокие технические навыки, но склонный усложнять вещи, чтобы выделиться и быть выше других членов команды. С нарциссами тяжело работать.
10. Одержимый всем разработчик
Тип разработчика одержимого всеми стандартами и методологиями. Стандарты и методологии могут приносить пользу, но если это становится крайностью, то теряется гибкость и вся работа идёт очень медленно.
11. Единорог
В моей компании есть разработчик, которого я обозначаю как "единорог". У него есть всё: великолепные технические навыки, великолепные навыки коммуникации и он всегда готов помочь.
Если есть проблема, он всегда готов решить её. Вы всегда уверены, что если он сказал, то он сделает.
В целом, "единороги" хороши во всём, но, как правило, не задерживаются долго на одной работе, потому что они знают свои возможности, не являются нарциссами и всегда имеют хорошие предложения о работе.
12. Быстрый разработчик
Они склонны заканчивать всё быстро, но берут новую задачу без 100-процентного закрытия предыдущей.
Они стремятся закончить задачу быстро и сделать свою часть работающей, хотя во многих случаях без тестирования хотя бы чего-нибудь или без применения хороших практик. Они не документируют код либо не следуют документации.
Проблема в работе с ними - после них весь код нужно рефакторить полностью либо много исправлять, чтобы избежать ошибок.
13. Разработчик, который всегда хочет помочь
Один из моих любимых типов. Обычно они знают всё и знают как это сделать хорошо. Они всегда хотят помочь не будучи заносчивыми и высокомерными.
К сожалению, некоторые из них отвечают на ваши вопросы, как будто вы ребёнок и совершенно не терпят критики, если опровергаете что-то из сказанного ими.
Заключение
В конечном счёте, наиболее важная вещь - найти сбалансированную команду с людьми, с которыми легко работать, кто надёжен и хочет развиваться. Технические знания и опыт приходят со временем, а изменять себя в лучшую сторону намного сложнее.
И хотя в этой статье я поведал личный опыт работы с другими разработчиками, я уверен, что вы сталкивались с множеством других различных типов разработчиков. И я бы хотел, чтобы вы тоже поделились в комментариях своим опытом.
Throwable
Как правило исчезает сразу после начала разработки задачи и появляется вконце, когда уже дело почти сделано, демонстрируя от своего имени вашу работу начальству и клиентам.
Абсолютно бесполезный чел в реальной разработке. Сертификаты — это исключительно коммерческое изобретение дабы поднять цену "продукта". Любая сертификация — это зазубривание вопросов и искусственных кейсов, которые мало что имеют с реальными ситуациями. Будучи специалистом очень узкого плана, любую задачу пытается решить заученными шаблонными методами, мотивируя это best practice и ссылаясь на авторитет сертифицирующей огранизации, чем сильно мешает разработке.
Не знаю этот ли тип разработчика, который на этапе планирования из газовой плиты пытается сделать ядерную станцию, наваливая всевозможные модные и фриковые технологические решения. Разобьем все на микросервисы, запакуем все в докеры, инсталлим через терраформ, деплоим через кубер, для логов подтащим эластик, сделаем репозиторий бинарников, поднимем дженкинса, испльзуем монгу для документов, мускул для данных, эластик для индекса, еще кассандру для трейсинга и полирнем все сверху кафкой. Как правило любит много рисовать, называя все это "архитектурой решения". Кодить не любит, еще меньше любит возиться со всем этим придуманным зоопарком. В проекте с самого начала создает проблемы на ровном месте.
Как правило имеет хреновые либо сильно ограниченные навыки. Ибо нарциссизм сильно мешает прогрессировать.
Racheengel
5 это тогда "паттерналист-GOFнокодер". После такого товарища годами приходится все фабрики абстрактных декораторов вычищать..
ngekht
Если честно — я не уверен даже какая из точек зрения хуже — что “сертификаты — это достаточный/единственный способ проверки” или критика сертификации на уровне не совсем верного представления о том, как и зачем это делается.
Во-первых говорить про зазубривание вопросов можно только в двух случаях:
— Если человек никогда не сдавал ни одной сертификации и имеет о них слабое представление
— Если человек пользуется так называемыми dump — практика нечистоплотная и, если на этом поймают — приводящая к лишению сертификата.
На самом деле сертификация это проверка знаний в голове у человека (а не то которые он может моментально нагуглить), в ситуации легкого стресса, созданного присутствием наблюдателя и ограничением по времени, на основе стандартизованных задач. Да, не идеально, но намного дешевле для работодателя, чем рисковать живым проектом или устраивать многомесячные “испытательные сроки”.
И если читать сертификацию как она есть — то есть не “ой, пришел великий специалист с бумажкой”, а как положено — “человек понимает и уважает риски компании и не побоялся испытать себя и показать что он обладает минимальным набором собственных знаний и минимальной устойчивостью к стрессу” — то картинка меняется.
А обычный плач по сертификации можно сравнить с экзаменом ВУЗ после прослушивания курса. Одинаково глупо считать что сдача экзамена — это 100% доказательства, равно как и хватать студента после прослушивания курса и сразу кидаться тестировать его на реальном производстве.
Throwable
Давайте не будем демагогизировать. Все прекрасно понимают для чего используется большинство сертификатов: для работника — поднять свою цену или конкурентноспособность на рынке труда, для компании-провайдера — поднять коммерческую стоимость своих услуг или получить доступ к более выгодным предложениям на рынке, для компании-клиента — отсеять большинство мелких сошек из крупного тендера, а также налепить различных "certiried" плашек на финальный продукт, для сертифицирующей огранизации — тупо собрать со всех бабла за бумажку. Реально же ни одна сертификация никогда не гарантирует качество сертифицируемого материала, и лишь призвана создавать такое впечатление.
Дешевле всего — посмотреть портфолио кандидата и увидеть то, что он уже делал в реальных условиях. Это скажет гораздо больше, о нем как о специалисте, нежели любые сертификаты. Кроме того "сертификационный бизнес" устроен так, что никогда не даст вам универсального сертификата "широкого плана" — только узконаправленный такого-то уровня по такому-то компоненту такого-то продукта такой-то технологии и такой-то версии. Поэтому чтобы подтвердить требуемые в типовом проекте скилы, вам придется иметь целый паровоз сертификатов, причем достаточно свежих, ибо они протухают со временем. И обойдетесь вы один мне такой сертифицированный как целая команда классных разработчиков.
Читать следует так: на рынке существует такой же специалист, но без бумажки, который обойдется вам дешевле.
В первую очередь у него образовалось где-то куча свободного времени для своей сертификации, что уже настораживает. И не надо мешать сертификацию с обучением, ибо последняя идет всегда отдельно от первого и за дополнительную плату, которую кандидат надеется с лихвой отбить.
Именно. Поэтому то, что вам кто-то выдал водительские права, абсолютно не значит, что вы реально умеете водить.
ngekht
Я бы был благодарен если бы перестали выдавать ложные утверждения за аксиомы.
Что сертификационный экзамен — это не зазубривание, мы как-то тактично проехали. Дальше — не лучше. Вам стоит внимательно посмотреть темы покрытые сертификационными экзаменами чтобы понять что утверждение про «один компонент одной версии продукта» точно так же не имеет никакого отношения к реальности, как и тема про зубрежку. Каждый экзамен имеет четко обозначнный круг проверяемых тем, вот можете начать изучать вопрос с «детского» по уровню AZ-203: docs.microsoft.com/en-us/learn/certifications/exams/az-203. Там очень легко увидеть что ваше утверждение не соотвествует истине. Потом можете взять экзамены AWS, Oracle, Cisco и убедиться в том же самом.
Так что я возьму на себя смелость попросить пример кучи сертификатов. Лично я для проекта на netCore вполне себе ограничиваюсь ровно двумя: MCSA Azure Developer или MCSA C# WebApp Developer + ICP для юниора, или MCSE Azure DevOps/MCSD WebApp Developer + PSD 1 для лида. И это дает более чем полное покрытие базовых знаний и о стеке и о процессе. Теперь ваш вариант «кучи», пожалуйста.
Теперь насчет реалистичности ваших предложений.
Смотреть портфолио? Прям исходняки? Очень интересная идея, минимум по двум причинам:
— Исходняки с реальных проектов вообще-то попадают под соглашение о неразглашении и показывать их вообще-то преступление.
— Даже если их смотреть — а какова стоимость отсмотра одного портфолио? Я лично не возьмусь много сказать про человека не покурив его исходняки часа 3-4 минимум. А спец который может грамотно это сделать даже по РФ стоит сейчас $20+/час.
Или вы предлагаете бедному разработчику у которого нет времени и средств на сертификацию инвестироваться в open source или pet проекты чтобы было что показать как портфолио?
Или портфолио это вообще не об исходниках, а о красивом рассказе самого разработчика как классно он где-то чего-то делал? И это вызывает большее доверие чем независимая сертификация?
Ну а в остальном вы говорите о реалиях которые мне, работающему с сертификациями достаточно плотно просто неизвестны.
Как именно можно налепить плашек на продукт через сертификации разработчиков? Какие именно сертификации разработчиков дают возможность вешать какие именно плашки? Мне кажется вы путаете три совершенно разных вещи — сертификацию специалистов, сертификацию процессов и сертификацию продуктов.
Throwable
В чем убедиться? Вот текущие сертификации от Oracle:
https://education.oracle.com/es/oracle-certification-path/pPillar_2#path-p-prod-product_267
Только на Java есть 5 различных экзаменов на 3 уровня и 2 версии Java 8 и Java 11! Оставлю вам для самостоятельного ознакомления посчитать количество сертификатов, версий и уровней по Oracle DB.
Да пожалуйста. Вот стек всего лишь одного продукта:
Плюсом скилы agile, git, ci/cd, devops, english и естественно в самой предметной области.
И это примерный профайл разработчика, который сейчас требуется практически повсеместно. Сделайте одолжение, посчитайте самотстоятельно количество сертификатов. Нанимать отдельно сертифицированного спеца на каждую технологию ни у кого не хватит никакого бюджета, даже тупо потому, что вы никогда не займете его работой на 100%.
Исключение — если вы работаете с продуктом, у которого штат превышает несколько десятков разработчиков, где вся работа строго распределена по ролям. Тогда вас сертифицированного посадят на конвеер например клепать бесконечные формочки.
Да оспади, даже резюме сразу может о многом сказать, особенно деятельность в предудыщих проектах, несколько наводящих вопросов на собеседовании, плюс твиттер, гитхаб и общее представление о кандидате уже готово. Другое дело, что далеко не все HR-ы в состоянии адекватно оценить скилы и экспириенс кандидата, поэтому для них проще работать с сертифицированным товаром.
Я намеренно объединяю их в одно, ибо общие цели и методы у всех сертификаций практически одинаковые.
ngekht
Спасибо за переход к более конструктивному диалогу.
И… я думаю, что я понимаю о чем вы.
Скажем существует целый рынок «дикого» аутсорса, в первую очередь отличающийся тем, что конракт, который заключен с командой, не стоит бумаги на которой он написан, просто потому что его нельзя реально enforce. Это нормально, пока есть клиенты которые готовы рисковать получая за это низкую цену, на таком рынке будет предложение, и работа на нем имеет свои преимущества. Все о чем вы говорит совершенно справедливо для этого рынка, и сиди я на нем — я бы не вложил ни копейки в сертификацию, она совершенно не релевантна была бы.
Существуют и другие рынки/ситуации когда сертификация является не обязательной. Скажем внутренняя разработка когда разработчик работает сидя рядом и ежедневно глядя в глазки пользователем мотивирует к собственному развитию не хуже сертификации и на самом деле являет собой самый что ни на есть Agile.
Но все-таки преобразование утверждения «я нахожусь на рынке на котором ценность сертификации сомнительна» в «все ваши сертификации — сплошное обманулово и бессмыслица» — таки остается более чем спорным.
Теперь конкретно по вашему ответу:
Посмотрел.
По Oracle самом точно могу сказать две вещи:
1) Нет сертификатов по каждой версии. Есть последняя и 11. Работа с Oracle 11 и Oracle 19 действительно сильно отличается. Я бы не доверил ни один свой проект «специалисту» который не понимает почему эта разница есть. И причина не в моей принципиальности. Если человек не понимает изменений сделанных при переходе с версии 11 дальше — то он не может и использовать Oracle эффективно, эти знания напрямую связаны между собой. Как минимум это будет означать что вполне можно было обойтись чем попроще. Тем же Postgres. Вынуждать заказчика к применению дорого инструмента, там где можно обойтись более простым — не профессионализм. А без того, чтобы получать за это денежку от Oracle — еще и чисто экономическая глупость. ;-)
2) Сертификаты для разных ролей по тестируемым знаниям сильно перекрываются. Т.е. никто не сказал что их надо собирать все. Но варианты выбора позволяют взять то, что наиболее точно отразит сильные стороны человека. Не понимаю почему такой выбор вдруг стал недостатком. Он неоднозначный, но не более того.
По Java 8/11 не скажу. Не явист, и насколько был принципиален переход с восьмой явы и насколько до сих пор она используется — мне оценить сложно.
Стек посмотрел. Если бы это был стек azure/netcore все кроме elastic было бы покрыто MCSA in Development.
Но можно интереса ради скажем взять React или Git. Ни по одному отдельных сертификаций как бы нет, но есть достаточно курсов. Так вот возникает интересный вопрос: а насколько нужен нам человек, которые не овладел информацией в пределах курсов по этим инструментам и какова была бы ценность более глубокой чем просто «пара вопросов» оценки этих знаний?
И нужен ли сертификат по elastic — вопрос насколько глубоко он используется. Если схватили первое что попало чтобы наваять на коленке — то ненужен. Если действительно использовать elastic как он был предназначен и наиболее эффективно — то таки да, тем более что elastic это не экзамен, а обучение.
Плюс сертификат по Agile, уже говорили.
Плюс, если действительно надо выпускать участников команды напрямую на заказчика, то TOEFL какой, чтобы не выглядеть на уровне а-ля AliExpress «я есть русский программист Иван придти делать ваша проект». Я как бы много нанимаю в exUSSR, это типичный уровень английского, к сожалению. Что-то приличное начинается с тех, кто реально оторвал попу и сдал хотя бы на upper-intermediate.
Есть много причин по которой такой выбор персонала не совсем попадает под понятие «наилучший способ». Наиболее просто объяснить почему — это взять ситуацию в которой ваш контракт с заказчиком таки стоит хотя бы бумаги на котором он написан, по причине того что заключен в юрисдикции в которой его реально enforce. Скажем как любая команда в РФ/на Украине или в Беларуси работающая с заказчиком в США — не такая, контрактом с ними можно в лучшем случае подтереться. Но вот я бы лично не рисковал подходить так к набору кадров если есть реальная возможность действительно «отвечать за базар» с суде. Доказать что вы предприняли «все разумные усилия для найма адекватных специалистов» будет очень сложно если вы поверили просто резюме, посмотрели twitter, и задали пару наводящих вопросов.
Мне все-таки кажется стоит хотя бы посмотреть и сравнить методы получения сертификата специалиста, процесса (хотя бы тот же ISO 9000) и продукта (хотя бы тот же FCC). Обнаружить сходство методов при такой разнице реализации — как я уже писал — слишком смелое обобщение.