Комментарии 20
1) Продавец дыма
Как правило исчезает сразу после начала разработки задачи и появляется вконце, когда уже дело почти сделано, демонстрируя от своего имени вашу работу начальству и клиентам.
3) Специалист с сертификатами
Абсолютно бесполезный чел в реальной разработке. Сертификаты — это исключительно коммерческое изобретение дабы поднять цену "продукта". Любая сертификация — это зазубривание вопросов и искусственных кейсов, которые мало что имеют с реальными ситуациями. Будучи специалистом очень узкого плана, любую задачу пытается решить заученными шаблонными методами, мотивируя это best practice и ссылаясь на авторитет сертифицирующей огранизации, чем сильно мешает разработке.
5) Разработчик-теоретик
Не знаю этот ли тип разработчика, который на этапе планирования из газовой плиты пытается сделать ядерную станцию, наваливая всевозможные модные и фриковые технологические решения. Разобьем все на микросервисы, запакуем все в докеры, инсталлим через терраформ, деплоим через кубер, для логов подтащим эластик, сделаем репозиторий бинарников, поднимем дженкинса, испльзуем монгу для документов, мускул для данных, эластик для индекса, еще кассандру для трейсинга и полирнем все сверху кафкой. Как правило любит много рисовать, называя все это "архитектурой решения". Кодить не любит, еще меньше любит возиться со всем этим придуманным зоопарком. В проекте с самого начала создает проблемы на ровном месте.
9) Нарцисс
Как правило имеет хреновые либо сильно ограниченные навыки. Ибо нарциссизм сильно мешает прогрессировать.
5 это тогда "паттерналист-GOFнокодер". После такого товарища годами приходится все фабрики абстрактных декораторов вычищать..
Любая сертификация — это зазубривание вопросов и искусственных кейсов, которые мало что имеют с реальными ситуациями.
Если честно — я не уверен даже какая из точек зрения хуже — что “сертификаты — это достаточный/единственный способ проверки” или критика сертификации на уровне не совсем верного представления о том, как и зачем это делается.
Во-первых говорить про зазубривание вопросов можно только в двух случаях:
— Если человек никогда не сдавал ни одной сертификации и имеет о них слабое представление
— Если человек пользуется так называемыми dump — практика нечистоплотная и, если на этом поймают — приводящая к лишению сертификата.
На самом деле сертификация это проверка знаний в голове у человека (а не то которые он может моментально нагуглить), в ситуации легкого стресса, созданного присутствием наблюдателя и ограничением по времени, на основе стандартизованных задач. Да, не идеально, но намного дешевле для работодателя, чем рисковать живым проектом или устраивать многомесячные “испытательные сроки”.
И если читать сертификацию как она есть — то есть не “ой, пришел великий специалист с бумажкой”, а как положено — “человек понимает и уважает риски компании и не побоялся испытать себя и показать что он обладает минимальным набором собственных знаний и минимальной устойчивостью к стрессу” — то картинка меняется.
А обычный плач по сертификации можно сравнить с экзаменом ВУЗ после прослушивания курса. Одинаково глупо считать что сдача экзамена — это 100% доказательства, равно как и хватать студента после прослушивания курса и сразу кидаться тестировать его на реальном производстве.
Давайте не будем демагогизировать. Все прекрасно понимают для чего используется большинство сертификатов: для работника — поднять свою цену или конкурентноспособность на рынке труда, для компании-провайдера — поднять коммерческую стоимость своих услуг или получить доступ к более выгодным предложениям на рынке, для компании-клиента — отсеять большинство мелких сошек из крупного тендера, а также налепить различных "certiried" плашек на финальный продукт, для сертифицирующей огранизации — тупо собрать со всех бабла за бумажку. Реально же ни одна сертификация никогда не гарантирует качество сертифицируемого материала, и лишь призвана создавать такое впечатление.
Да, не идеально, но намного дешевле для работодателя, чем рисковать живым проектом или устраивать многомесячные “испытательные сроки”.
Дешевле всего — посмотреть портфолио кандидата и увидеть то, что он уже делал в реальных условиях. Это скажет гораздо больше, о нем как о специалисте, нежели любые сертификаты. Кроме того "сертификационный бизнес" устроен так, что никогда не даст вам универсального сертификата "широкого плана" — только узконаправленный такого-то уровня по такому-то компоненту такого-то продукта такой-то технологии и такой-то версии. Поэтому чтобы подтвердить требуемые в типовом проекте скилы, вам придется иметь целый паровоз сертификатов, причем достаточно свежих, ибо они протухают со временем. И обойдетесь вы один мне такой сертифицированный как целая команда классных разработчиков.
И если читать сертификацию как она есть — то есть не “ой, пришел великий специалист с бумажкой”, а как положено
Читать следует так: на рынке существует такой же специалист, но без бумажки, который обойдется вам дешевле.
и не побоялся испытать себя и показать что он обладает минимальным набором собственных знаний и минимальной устойчивостью к стрессу
В первую очередь у него образовалось где-то куча свободного времени для своей сертификации, что уже настораживает. И не надо мешать сертификацию с обучением, ибо последняя идет всегда отдельно от первого и за дополнительную плату, которую кандидат надеется с лихвой отбить.
Одинаково глупо считать что сдача экзамена — это 100% доказательства, равно как и хватать студента после прослушивания курса и сразу кидаться тестировать его на реальном производстве.
Именно. Поэтому то, что вам кто-то выдал водительские права, абсолютно не значит, что вы реально умеете водить.
Что сертификационный экзамен — это не зазубривание, мы как-то тактично проехали. Дальше — не лучше. Вам стоит внимательно посмотреть темы покрытые сертификационными экзаменами чтобы понять что утверждение про «один компонент одной версии продукта» точно так же не имеет никакого отношения к реальности, как и тема про зубрежку. Каждый экзамен имеет четко обозначнный круг проверяемых тем, вот можете начать изучать вопрос с «детского» по уровню 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 проекты чтобы было что показать как портфолио?
Или портфолио это вообще не об исходниках, а о красивом рассказе самого разработчика как классно он где-то чего-то делал? И это вызывает большее доверие чем независимая сертификация?
Ну а в остальном вы говорите о реалиях которые мне, работающему с сертификациями достаточно плотно просто неизвестны.
Как именно можно налепить плашек на продукт через сертификации разработчиков? Какие именно сертификации разработчиков дают возможность вешать какие именно плашки? Мне кажется вы путаете три совершенно разных вещи — сертификацию специалистов, сертификацию процессов и сертификацию продуктов.
Потом можете взять экзамены AWS, Oracle, Cisco и убедиться в том же самом.
В чем убедиться? Вот текущие сертификации от 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.
Теперь ваш вариант «кучи», пожалуйста.
Да пожалуйста. Вот стек всего лишь одного продукта:
- Linux
- Firewall/Iptables & basic network security
- Nginx
- Docker
- Java
- Spring Boot
- Html/Css/Javascript
- React.JS
- Oracle DB
- ElasticSearch
Плюсом скилы agile, git, ci/cd, devops, english и естественно в самой предметной области.
И это примерный профайл разработчика, который сейчас требуется практически повсеместно. Сделайте одолжение, посчитайте самотстоятельно количество сертификатов. Нанимать отдельно сертифицированного спеца на каждую технологию ни у кого не хватит никакого бюджета, даже тупо потому, что вы никогда не займете его работой на 100%.
Исключение — если вы работаете с продуктом, у которого штат превышает несколько десятков разработчиков, где вся работа строго распределена по ролям. Тогда вас сертифицированного посадят на конвеер например клепать бесконечные формочки.
Смотреть портфолио? Прям исходняки? Очень интересная идея, минимум по двум причинам:
Да оспади, даже резюме сразу может о многом сказать, особенно деятельность в предудыщих проектах, несколько наводящих вопросов на собеседовании, плюс твиттер, гитхаб и общее представление о кандидате уже готово. Другое дело, что далеко не все HR-ы в состоянии адекватно оценить скилы и экспириенс кандидата, поэтому для них проще работать с сертифицированным товаром.
Мне кажется вы путаете три совершенно разных вещи — сертификацию специалистов, сертификацию процессов и сертификацию продуктов.
Я намеренно объединяю их в одно, ибо общие цели и методы у всех сертификаций практически одинаковые.
И… я думаю, что я понимаю о чем вы.
Скажем существует целый рынок «дикого» аутсорса, в первую очередь отличающийся тем, что конракт, который заключен с командой, не стоит бумаги на которой он написан, просто потому что его нельзя реально enforce. Это нормально, пока есть клиенты которые готовы рисковать получая за это низкую цену, на таком рынке будет предложение, и работа на нем имеет свои преимущества. Все о чем вы говорит совершенно справедливо для этого рынка, и сиди я на нем — я бы не вложил ни копейки в сертификацию, она совершенно не релевантна была бы.
Существуют и другие рынки/ситуации когда сертификация является не обязательной. Скажем внутренняя разработка когда разработчик работает сидя рядом и ежедневно глядя в глазки пользователем мотивирует к собственному развитию не хуже сертификации и на самом деле являет собой самый что ни на есть Agile.
Но все-таки преобразование утверждения «я нахожусь на рынке на котором ценность сертификации сомнительна» в «все ваши сертификации — сплошное обманулово и бессмыслица» — таки остается более чем спорным.
Теперь конкретно по вашему ответу:
В чем убедиться? Вот текущие сертификации от Oracle
Посмотрел.
По 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). Обнаружить сходство методов при такой разнице реализации — как я уже писал — слишком смелое обобщение.
Однобоко надерганы примеры из жизни. Такого рода типизации это просто наглая ложь и навешивание ярлыков. Под ней нет никакой теории, которую можно проверить.
Ну почему же сразу ложь? Нам попадаются люди разных типов и субъективно мы можем классифицировать по-разному. Но и это разное может где-то пересекаться.
Теоретик detected :)
Просто на фоне хотя бы такой классификации это все выглядит слишком субъективно и от того слабовато.
https://habr.com/ru/post/336248/
Хорошая статья, спасибо. К сожалению, я не смог найти ни её ни чего-то похожего перед тем как брался за перевод. Только перед публикацией пока искал правильные хабы нашёл вот эту https://habr.com/ru/post/431534/, но на мой взгляд типажи всё же разные и скорее они дополняют друг друга.
Там по ссылке воды много, а типов мало. Например вот как назвать человека, который готов делать всё и с фанатизмом, и зарплата для него не самое главное? А таких хватает.
Как стоит назвать статью это к автору оригинала :)
А как просто читатель я с вами не соглашусь. Здесь есть и те с кем нравится и те с кем не нравится работать вместе. Если бы были только обиды и обвинения, автор не рассказывал бы о тех типах разработчиков, с которыми ему нравится работать. У каждого из нас, наверное, есть люди с кем нам нравится работать и с кем больше не очень бы хотелось. И эта классификация хотя и довольно субъективна, она имеет право на жизнь. И наверняка найдутся те, кто скажет: "О, действительно, вот с таким типом и я работал."
а) принадлежащих Императору,
б) набальзамированных,
в) прирученных,
г) сосунков,
д) сирен,
е) сказочных,
ж) отдельных собак,
з) включенных в эту классификацию,
и) бегающих как сумасшедшие,
к) бесчисленных,
л) нарисованных тончайшей кистью из верблюжьей шерсти,
м) прочих,
н) разбивших цветочную вазу,
о) похожих издали на мух.»
Хорхе Луис Борхес, «Аналитический язык Джона Уилкинса»
Почти все типажи отрицательные. Похоже, автор статьи занимается банальным самоутверждением, расходимся :)
13 типов разработчиков, с кем я работал