«Негибкие навыки»: Как представления об идеальном программисте могут навредить процессу разработки
В классической короткометражке про 7 красных перпендикулярных линий начальники и заказчики, обращаясь к исполнителю, все время подчеркивают: «Вы же эксперт? Вы же профессионал?»
И действительно, в корпоративной культуре культивируется образ программиста-героя, всегда готового к вызовам, обладающего полным знанием всех существующих технологий и способного творить чудеса одним нажатием клавиш.
Но погоня за этим идеалом, часто приводит к печальным результатам.
В этой статье мы разберем, как попытка соответствовать представлениям об идеальном программисте может навредить и самому программисту, и процессу разработки. Рассмотрим, чем чистый код, зона потока, незаменимость и безотказность могут помешать работе.
Тыжпрограммист не допускает ошибок
Никто не будет спорить, что хороший код — это важно. Но погоня за идеальным кодом может легко завести в тупик.
Исследователь Нил Грин выделяет тип разработчиков, которых он называет «Идеалистами». Эти программисты одержимы идеей совершенства, тратят невероятное количество времени на рефакторинг, оптимизацию и переписывание кода.
В чем проблема:
Забытые цели. Идеалисты, увлеченные поиском совершенного кода, часто забывают о конечной цели разработки — решении бизнес-проблем. Они могут потратить недели на переписывание функционала, который уже работает, лишь для того, чтобы сделать его «красивее».
Прокрастинация. Постоянная погоня за совершенством может стать источником хронической прокрастинации. Разработчик может бесконечно переписывать код, боясь, что его работа не будет идеальной.
Синдром «Not invented here». Такие разработчики могут страдать от неприязни к чужому коду. Даже если код работает отлично, они предпочитают переписывать его заново, чтобы он соответствовал их собственным представлениям о совершенстве.
Чтобы избежать ловушек идеализма, стоит помнить, что код — это инструмент для решения бизнес-задач. Пользоваться принципом программирования YAGNI. Это принцип («You aren’t gonna need it» — «Вам это не нужно») утверждает, что функционал, не указанный в требованиях к системе, не следует реализовывать.
Подход простой: заказчик не должен платить за ненужные функции, а разработчики не должны тратить свои ресурсы на создание того, что не нужно.
Стремление к качественному коду — это благородная цель. Однако важно помнить, что идеальное — это враг хорошего. В мире кода нужно находить баланс между совершенством и практичностью, чтобы создавать качественные продукты, которые решают реальные проблемы.
Тыжпрограммист творит только в зоне потока
Это миф о непрерывной продуктивности. Зона потока — сверхпроизводительное время, когда удается писать код с невероятной скоростью и легкостью.
Роберт Мартин, автор книги «Идеальный программист», называет это состояние опасным. По его мнению, в зоне потока программист считает себя суперменом, а свой код — хорошим. Проблема в том, что такой код часто оказывается написан наспех, без должной проверки, и, впоследствии, становится причиной ошибок.
Джоэл Спольски, напротив, считает, что зона потока — это уникальное состояние, в котором нужно творить. Программистов нельзя отвлекать, так как даже самый простой вопрос соседа «как сделать то или это» выбивает из зоны потока на 15 минут.
В чем проблема:
Подходит не всем. Зона потока — это индивидуально.
Представление о том, что программист должен постоянно находиться в состоянии «потока» и эффективно управлять своим временем, может вызвать стресс и выгорание.
Реальность такова, что работа в IT требует гибкости и способности адаптироваться к меняющимся условиям. Не всегда удается сохранять высокую продуктивность, и это нормально.
Тыжпрограммист — универсальный работник
Чед Фаулер в книге «Программист-фанатик» советует разработчикам не ограничивать себя одной технологией или ролью. Он пишет о том, что нужно стремиться стать универсальным специалистом. Ведь чем больше навыков и знаний освоит программист, тем выше его ценность для компании.
Об этом пишут и в описаниях к вакансиям. Работодатели ищут разработчика рок-звезду — героя, который в одиночку сможет вытащить проект.
Но также Фаулер напоминает о том, что любой работник — это камешек в ведре воды. Если маленький камешек вынуть из ведра — уровень воды практически не изменится. От работника могут избавиться в любой момент.
Разработчик рок-звезда — это не просто камешек, он глыба на которой, держится все. Кажется, что компания очень заинтересована, чтобы удержать такого ценного сотрудника. Но опыт показывает, что увольняют и универсальных профессионалов, которые делают всю работу и тянут команду.
Нил Грин относит разработчика рок-звезду к деструктивным типам разработчиков.
В чем проблема:
Незаменимость. «Rockstar» решают любые проблемы быстро, работают ночами, минимизируют ошибки и берут на себя сложные задачи. Они становятся незаменимыми. Когда такой разработчик в отпуске — вся работа стоит, вопросы копятся, задания не выполняются.
Чаще всего в проекте, которым занимается рок-звезда, нет документации. Ему некогда собирать и описывать информацию. Такой разработчик — единственный «носитель» знаний по проекту.
С вопросами обращаются только к нему, задания поручают ему, с ошибками разбирается он. Чем лучше работает человек, чем больше ему доверяют — тем больше работы на него взваливают. Такое «доверие» руководства приводит к переработкам.
Рок-звезда попадает в замкнутый круг, пока не совершит фатальную ошибку. И тогда окажется, что это не начальство свалило на него кучу работы, а он держит проект в заложниках и, вообще, во всем сам виноват. Прям как в старой нашумевшей статье «Мы уволили самого талантливого сотрудника. Это лучшее решение, которое мы когда-либо делали».
В итоге, рок-звезда уходит, забирая с собой ценные знания. В компании ничего не меняется, процессы остаются недокументированными, а через некоторое время там появляется новый «герой».
Феномен «рок-звезды» в разработке — это опасная иллюзия эффективности, скрывающая системные проблемы в организации.
Тыжпрограммист не использует слово «нет»
Современное общество, одержимое культом позитивного мышления, часто доводит все до крайности. Лозунги о достижении невозможного и непреклонной целеустремленности создают атмосферу, в которой сказать «нет» — признак слабости.
Нередко приходится сталкиваться с ситуацией, когда новые задачи наваливаются одна за другой, словно снежный ком. И часто вместо того чтобы реально оценить свои возможности и отказаться от задачи с нереальным сроком, работники выбирают путь наименьшего сопротивления отвечая: «Попытаюсь».
Если очевидно, что задание не под силу, вместо фразы «Попытаюсь» лучше сказать «Нет».
В чем проблема:
Выгорание. В таком случае программист переоценивает свои силы, берется за слишком много задач одновременно. Результат предсказуем: срывы дедлайнов, нарушение планов проекта, снижение качества кода.
Многозадачность, хотя, на первый взгляд, и кажется эффективной, может снижать концентрацию и приводить к нерациональному использованию времени и ресурсов.
Постоянное стремление угодить всем неизбежно приведет к выгоранию.
Важно понимать, что умение говорить «нет» — это не признак токсичности или нежелания работать в команде. Это, прежде всего, проявление ответственности за свою работу, свои ресурсы и, что немаловажно, свое здоровье.
Конечно, сказать «нет» может быть непросто. Это может вызывать дискомфорт и приводить к конфликтам.
Но в адекватной компании отказ с ясным объяснением причин и предложением альтернативных вариантов приведет к конструктивному диалогу.
Тыжпрограммист не конфликтует
Подчинение и сговорчивость иногда воспринимаются как ключевые факторы карьерного роста. Однако такой подход может оказаться губительным, поскольку он препятствует развитию новых идей.
Исследования показывают, что чрезмерная неконфликтность и угодничество часто производят негативное впечатление на окружающих.
Вместо этого гораздо разумнее проявлять твердость характера и не бояться конфронтации.
В чем проблема:
Избегать конфликта — значит тормозить прогресс. Когда разработчики боятся выразить свое мнение или задать критический вопрос, они лишают себя возможности увидеть проблему с разных сторон. В результате применяются стандартные решения, и команда теряет шанс на прорывные идеи.
Представление о том, что программист должен избегать конфликтов, может привести к подавлению мнений и идей в команде.
Конфликты — это естественная часть взаимодействия между людьми. Но они должны быть конструктивными. Открытое обсуждение разногласий способствует более глубокому пониманию проблемы и нахождению лучших решений.
Важно понимать, что «конфликт» не равно «агрессия». Существует несколько стилей коммуникации:
Пассивный: Участник конфликта избегает конфронтации, не выражает своего мнения. Поэтому он подавлен и неудовлетворен.
Агрессивный: Вступает в конфликт с целью доминировать, не учитывает мнение других. Это приводит к негативным эмоциям и разрушению отношений.
Пассивно-агрессивный: Скрывает несогласие и раздражение, проявляя его непрямыми способами. Это приводит к недопониманиям и отрицательно сказывается на работе команды.
Ассертивный: Участник конфликта открыто и уважительно выражает свое мнение, учитывая мнение других. Это способствует продуктивному диалогу и нахождению лучших решений.
Ассертивное поведение — это не просто уверенность, а способность открыто выражать свое мнение без агрессии и не бояться отстаивать свою точку зрения. Это навык, который можно и нужно развивать.
Заключение
Не бывает идеальных программистов. Каждый разработчик — это уникальная комбинация навыков, опыта, индивидуального подхода к решению проблем и личностных качеств.
Лучше сфокусироваться не на поиске фантастического «идеального» программиста, а на создании сплоченной и эффективной команды, где вклад каждого ценится по достоинству.
Habrahabr.ru прочитано 1567 раз
