Dev-непрофессионализм — главный тренд в отрасли

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

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

Я приведу свою точку зрения: «Позера от Профессионала отличает воинствующее сопротивление всему конструктивному, звездная болезнь, патологическая невозможность сказать себе „Достаточно“, а также периодические игры с переусложнением существующих решений ради удовлетворения собственного эго и завязывания проекта „на себя“ ».

Проще всего пояснить что-либо на примерах, с этого я и начну:

Причина: Dev-получают премии/бонусы за оперативное запиливание фич/исправление дефектов
Реализация: Особо ушлые товарищи поняли фишку и, не укладываясь в запланированное время, «запиливают» фичу/ «исправляют» дефект ржавыми велосипедами, заботливо собранными со всех помоек интернетов. Их не особо беспокоит, что получившийся ублюдок не взлетит, а лишь покашляв, выбросит очередной NPE. Главное «закрыть» задание, а исправление дефектов/новый этап исправлений идет отдельным процессом со своим, новым ожиданием исполнения, а там и замотанным синей изолентой костылям найдется применение.

Причина: Dev поднимают панику на пустом месте, делая бурю в стакане воды, чтобы оправдать собственное безделье.
Реализация: Некоторые Dev могут неделю играться в пинг-понг в начале спринта, а в пятницу после обеда развить ИБД, засыпая в широковещательной рассылке всех, включая вице-президента, уточнениями и вопросами по фиче.
На вопрос, чем же они занимались до этого, всегда наготове ответ, мол, локально поднимали-неведомо-по-какой-причине-упавший-томкат, и т.п. отмазки различной степени бредовости (навык оттачивается фантастически к рангу «синьора», при должной ежеспринтной практике).

Причина: Большинство dev «over-engineer» -ят при малейшей возможности; изучая что-то новое не осознают, когда это новое применимо к месту.
Реализация: При отсутствии гонки на время в виде точно выделенного времени на выполнение задания, некоторые разработчики умело дестабилизируют проект, доводя его до маразма.
К примеру, внедрением свежеизученного шаблона он переусложняет технически простое решение («смотрите, как я умею ^_^»), и, по мере роста фичи, уже не в состоянии ни расширять функционал ни отрефакторить за разумное время, Внезапно выяснив, что применение шаблона неразрывно связано с рядом «но».
Грохот падающего приложения на данном участке, как и шум падающих кирпичей из нежного нутра нашего с вами разработчика, насыщен и тонально полон.
QA инженеру на данном этапе, после указания на очевидный провал $programming_language$-guru путем фиксации дефекта в баг-трекере, рекомендуется укрыться в panic-room, т.к. жаркие лучи ненависти не лучшим образом влияют на потенцию.

Причина: Мой код идеален, просто спецификация немного по-деПильному написана.
Реализация: Проект собирается за 4 минуты без интеграционных тестов. Большая часть перекрестных юнит-тестов не проходит, QA smoke suite build conf на CI запускать бессмысленно.
Виноват, разумеется, составитель FRD/user story, сервер, администратор или провайдер, но только не разработчик. Не закрытые потоки, чтение файлов по 1 байту, феерические абстрактные фабрики для дохлой парочки типов, копипаста чуть более, чем везде, приводящая к сваливанию кода. Все это реалии разработки. Когда отмазки заканчиваются, применяется коронный аргумент: «архитектура изначально г*вно, а мы в белом». Не всегда, правда, выходят сухими из воды, и бизнес-гель находит себе применение.

Причина: «Звонок — для учителя»
Реализация: Разгар подготовки релизной версии, QA и dev-ops в мыле, team-lead уже 6-й час на совещаниях и ему там не сладко. Dev при этом в течение дня несколько раз играл в икс-бокс, покурил и обсудил последние политические новости. Видимо, для dev существуют особые правила, а командный дух это не для них. Два дефекта за день закрыл (исправление z-index: 3 часа, обработка 2 пропущенных исключений: 5 часов) — можно и расслабиться.

Причина: Двойные стандарты — второе имя DEV.
Реализация: DEV очень любят писать краткие комменты на техническом языке в JIRA, игнорируя факт, что помимо них трекер читают и junior QA, и люди, зачастую далекие от технической части (BA, PM), обижаясь при этом на справедливые замечания. Имеют свойство давать советы по тестированию, но при этом исподлобья смотрят, когда получают запросы на содействие тестированию (ввести недостающие хуки в api для облегчения тестирования, навести порядок в дурдоме верстки).

Причина: Ловля звезд.
Реализация: Термин варьируется, но в пределах 1,5-3 лет немалое количество разработчиков «ловит звездочку», после чего коэффициент тяжести проблем, указанных выше, можно смело умножать на 2.
В этом словивший звездочку разработчик схож с начинающим автолюбителем, по статистике наибольшее количество аварий происходит между 1 и 3 годами вождения (считает, что уже бог баранки).
В случае с разработчиком, оный начинает презрительно поглядывать на QA (неудавшиеся devs, позорище), PO (губошлепы), PM (переоцененный чувак с дорогим галстуком, не понимающий бизнеса), рекрутеров (прислуга). Дело усугубляется твердой уверенностью, что он глава мироздания в IT фирме, и он всех «кормит», а все остальные нахлебники.
Но есть и положительные стороны явления — словленная звезда способствует скорому переходу разработчика куда-то еще, ведь на нынешнем месте, ему, гиганту мысли, недоплачивают на грани беспредела (либо отправляется на поиски счастья в порядке добровольно-принудительном).
Стоит ли говорить, что качество кода у раненого кардинально не улучшилось с момента «осознания своей Настоящей цены» (+500/прыжок), как и качество английского?

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