2013-12-10
Релиз должен был быть вчера. Пользователи ноют. Начальник начальника грозит топором. Ничего не работает, всё пропало.
Все хотят, чтобы код лился на головы освежающим лёгким потоком, но никто не думает, что для этого нужно сделать. Руководитель, который хочет, чтобы работа была сделана вчера, и пальцем не пошевелит для того, чтобы нанять ещё людей в штат, например.
Соберём жалобы программистов в одном месте. Что мешает нам работать продуктивно?
Собрания
Самая популярная жалоба. Если верить тому, что говорят программисты, их запирают в переговорных на неделю и заставляют выслушивать повестку дня. Всегда виноваты либо менеджеры, которые собирают эти идиотские совещания, либо другие программисты, которые в подробностях расписывают каждый баг или фичу.
Что так раздражает в совещаниях? После каждого собрания крайне сложно обратно войти в колею абстрактного мышления. Переключение мозга в нужный для манипуляции абстрактными алгоритмами режим может занять час и даже больше.
Ответы на корпоративные рассылки
Следом за собраниями в рейтинге убийц продуктивности идут бесконечные письма из корпоративной рассылки. Эти письма адресованы либо всей компании, либо всему отделу, и на них хочется ответить только «многобукв, не осилил». Некоторые просто ставят рассылки на фильтр, отправляя их прямиком в корзину. Вот и получается парадокс: то, что призвано налаживать внутреннюю коммуникацию, вызывает лишь раздражение и желание избавиться от человечества.
Попытки контролировать уровень эффективности
Когда-то менеджерам попалась на глаза гениальная фраза: «Нельзя руководить тем, что не можешь измерить». Вот они и начинают измерять, замерять, считать количество коммитов, строк кода и баг-фиксов. Они думают, что это и есть единица измерения, а ведь измерения — это хорошо.
Однако, это приводит лишь к народной забаве под названием «симуляция активной деятельности». Вместо фактической работы над кодом начинаешь увеличивать количество строк, или нервно выискивать баги. В итоге вместо отлично сконструированного лаконичного кода мы получаем максимально длинные манускрипты.
Да, нам нужен баг-трэкинг. Нам нужна организация рабочего процесса и координация процесса создания программного обеспечения. Но у качественной работы нет единицы измерения.
Старшие разработчики
В каждой команде есть коллега хуже начальника. Как правило, это именно тот разработчик, который создал последнюю итерацию, но больше не работает над этим проектом. Примерно так каждый сантехник, приходящий в дом, обязательно нелестно выскажется об умственных способностях предыдущего мастера.
На самом деле всё не так плохо, как нам кажется, когда мы смотрим на прежний код. Стили программирования меняются со временем. У предыдущего поколения не было в распоряжении тех библиотек, которые есть сейчас.
Такое отношение к старшим разработчикам и проделанной ими работе зачастую замедляет проект. В нас включается тщеславие, которое заставляет нас переписывать и без того неплохой код, лишь бы это было сделано «правильно».
Технический долг
У нас никогда не хватает времени. Мы вставляем костыли, наскоро залепляем скотчем, и запиливаем в продакшн со словами «Потом доделаем». Это и называется техническим долгом.
Он есть в каждом проекте. Иногда он настолько глубок, что следующая команда разработчиков начинает свой путь с нуля. Этот долг растёт почти так же стремительно, как дыра в федеральном бюджете.
Менеджеры нетехнического склада ума
Это такие весёлые ребята-выпускники %любого_нетехнического_факультета%, которые, как правило, замечательно умеют лайкать и репостить.
Некоторые программисты искренне любят таких менеджеров, потому что им можно сказать любую наукообразную чепуху, и они ей поверят. А для большинства эти менеджеры — это те, кто собирают совещания и путаются под ногами.
Менеджеры технического склада ума
Да, они нам тоже не нравятся. И даже больше, чем весёлые ребята с юрфака.
Менеджер, который когда-то был программистом, может внезапно заняться копанием в проекте и требовать заменить почти всё, потому что у него случилось прозрение. Или вдруг он начнёт вспоминать старые добрые ассемблеровские времена. В любом случае, именно они начинают погружаться в технические детали, хотя их задача — следить за общей картиной проекта.
Брограммисты
Программисты и сами себе обычно не очень нравятся.
Очень часто у типичного программиста возникают проблемы в коммуникации, обусловленные отсутствием желания размышлять об эмоциональной стороне вопроса. Он с хваткой питбуля вгрызается в технические споры. Неважно, что клиенту нужно что-то конкретное, он обязательно начнёт говорить о преимуществах динамических языков. Это он устраивает разборки об алгоритмах и принципах наследования.
Те, кто в белом пальто
Нашли у него в коде нулевой указатель? Сами и исправляйте. И недопустимые операции тоже сами поищете.
Он всё делает суперкруто и супербыстро, потому что тестированием и верификацией замнимается кто-то другой. Правда, кто этот другой — неизвестно. И то, что верификацией не занимался чуть менее, чем никто, обнаруживается уже при бета-релизе.
Плохая документация
На подготовку документации уходит очень много времени. А платят нам за написание кода. Да ещё и строчки считают. Вы хотите результатов. Мы делаем то, что вы от нас требуете. Нет-нет, не переживайте, мы всё помним и обязательно запишем всё. Как-нибудь потом.
Очень часто существующая документация актуальна для кода, написанного месяцы и годы назад. И такой и останется. Вечно.
Обильная документация
Проект без документации — это плохо. Проект с идеальной документацией, но с почти не написанным кодом — тоже не радует. Порой создаётся ощущение, что в том, кто составлял документацию, погиб сценарист «Доктора Кто». Тот самый случай, когда код не кратко комментируется, а переводится с языка программирования на английский.
Смешались вместе люди, кони
Болтовня, громкая музыка, рингтоны и даже звуки любимого многими пинг-понга однозначно отвлекают от решения аналитических задач. Нам тоже нужно общаться, но не в том же помещении, где мы сосредоченно решаем проблемы вселенского уклада. Тишина должна быть в библиотеке!
А стол для пинг-понга пусть стоит в специально отведённой для этого зоне, а не посреди опен-спейса.
Соответствие корпоративной культуре
Можно много рассуждать об идеальном рабочем пространстве, но лучше предоставить команде решать это. Иногда удобно, когда все твои коллеги на расстоянии вытянутой руки от тебя. Иногда групповой скайп-колл может быть очень эффективен.
Но возводить в культ ценности, придуманные чужими дядями и тётями, и слепо им следовать, всё же не стоит. Корпоративный дух не погибнет, если пару дней несколько сотрудников поработают из дома.
Олдфаги
На Dice.com из 700 000 предложений по запросу Cobol выдаётся около 680 вакансий. Около 1%. Конечно, фанаты Cobol скажут тысячу слов в защиту этой технологии. Но при этом они часто забывают о том, как затратно поддерживать в рабочем состоянии устаревший код, который был написан ещё до появления ASCII.
Ньюфаги
Ну, вы поняли. Это те, кто утверждает, что на Java писала ещё его бабушка, а Node.js — это тренд далёкого 2012 г.
При этом забывается, что новые инструменты ещё не прошли проверку боем, и не всегда стоит тратить своё время на игры с новым фреймворком только потому, что он только что вышел.
Перевод: Люся Ширшова. Подготовлено по материалам ITworld.com.
