7 типов разработчиков, которые тянут команду на дно

Для выполнения задач команда проекта должна работать как единый организм, но это не всегда возможно, особенно, если в коллективе присутствуют проблемные личности. За годы работы разработчик с сайта CodingToFreedom научился определять людей, которые способны изменить настрой коллектива и навредить общим усилиям, и условно разделил на типы. Как правило, они есть практически в каждой команде. 

«Новатор» 

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

Достаточно одного или нескольких программистов, которые ведут себя так, будто все вокруг приехали из села, и ценности команды будут подорваны. В моей команде однажды был разработчик, который как минимум раз в день говорил, что мы «кодим, как дикие животные». С каждым разом эта фраза все меньше звучала как шутка. А потом он уволился, и вся команда вздохнула с облегчением.

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

Это неправильный способ введения инноваций. 

Занятой лентяй 

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

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

Лид, который ничего не знает 

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

Я работал под началом таких людей, поэтому знаю, что они существуют. С ними команда может стать максимально продуктивной. 

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

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

Сдавшийся циник

Человек-пустота, торнадо ненависти, отвращения и разочарования. Такие люди продолжают работать на одном месте только потому, что знают, что в другом все будет так же паршиво. Они смотрят на хорошее и видят только плохое.

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

Попасть в этот омут рискуют все, как только перестают приходить на работу с «горящими глазами». 

Непрагматичный перфекционист 

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

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

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

Позже я внедрил это изменение, и оно безупречно работало. Но у меня так и не получилось объяснить свою идею, потому что «мои псевдоскобки были псевдолишними и их можно было упростить до inline-ifs с использованием нотации двоеточия и вопросительного знака». 

Элитарист 

Такие люди не следят за своим кодом, но лезут в чужой. Это голословные поклонники Mac или Windows, те, кто настаивает на превосходстве одного текстового редактора и отказывается помочь коллеге, пока он не установит его на свою машину, и те, кто приходит в проект и переписывает половину рабочего кода, потому что считают, что их ORM подходит лучше. 

Эти люди бесят каждый раз, когда видишь их самодовольное лицо и гордость за тот незначительный выбор, который они сделали и пытаются навязать другим. Опуститесь на их уровень. Спросите, «что Mac/Windows делает такого, чего не может моя ОС?». В ответ вы получите что-то вроде «чувак, я понятия не имею, как ты вообще можешь с этим работать», — без фактического объяснения, но с необоснованной верой, которую может опровергнуть любой, кто действительно использует любую из технологий в соответствии с ее возможностями. 

Скрытный 

Зададите вопрос, но ответа не услышите. Попросите помощи — и вам скажут: «Поищи документацию, но только сам, не могу же я все делать за тебя».

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

В какой-то момент я просто стал скачивать и изучать репозиторий системы, потому что было гораздо быстрее понять и узнать все, что нужно, оттуда, чем спросить у того, кто его написал. Код не врет, и он говорит со всеми, кто готов слушать. 

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

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

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

Автор материала