Blogerator.org

× Версия для печати

Я уже ранее касался этой острой проблемы на своём блоге в злободневном посте «35 лет: есть ли жизнь в программировании после?» На самом деле, эта проблема ОЧЕНЬ острая, поэтому я хочу возвратиться и посмотреть на неё чуть с другой стороны. Для этого предлагаю перевод статьи известного разработчика Алана Скоркина, который, кстати, ведет собственный популярный блог, полностью посвященный психологии программирования, а также секретам и парадоксам успеха в этой профессии.

Итак, под катом перевод его очень любопытной статьи «Did Your Boss Thank You For Coding Yourself to Death?», которую я рекомендую обязательно прочитать и задуматься, каждому профессиональному (и особенно любому амбициозному) программисту.

Постановка задачи

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

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

Алан Скоркин,
профессиональный программист и популярный блогер

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

А вот ещё одно наблюдение: как часто вам на самом деле удаётся повозиться с интересными задачами и классной техникой — и как часто вы вместо этого строчите код, отчаянно пытаясь успеть сделать что-то вовремя, вписаться в какой-то срок, установленный вам по чьей-то прихоти?

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

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

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

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

Меня очень впечатлила эта история, и первый мой вопрос был: «Ну и где же этот парень сейчас?». На что мой друг ответил: «Он умер. Слишком напряжённую жизнь вёл». Слишком напряжённо кодировал, так было бы точнее.

Ну и впечатление от этой истории про супер-кодера сразу как-то смазывается — ведь Джону тогда было едва за тридцать.

Что делает плохую ситуацию еще хуже

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

Люди словно собаки: мы удивительно восприимчивы к положительным и отрицательным стимулам. И многие годы «боевых крещений» выработали у всей индустрии условный рефлекс — вплоть до того, что авральное мучение над косячным проектом вознаграждается чаще, чем нормально работающий проект. Каждый раз, когда мы соглашаемся на дополнительные часы работы, мы подкрепляем эту тенденцию.

Плохо ещё, что мы животные стадные: достаточно убедить одного, и все остальные захотят последовать его примеру. Вина участвует в уравнении: «мы не можем бросить наших товарищей пахать одних, мы им поможем».

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

Интересно, что иногда за этими «гаргантюанскими усилиями» даже толком не ведётся учёт, поскольку это может навредить репутации. Поэтому они «химичат» с бухгалтерией, так чтобы клиент был уверен, что все работают по 40 часов в неделю (то есть им платят как за 40 часов), и работа шла по графику — неважно, что вся команда напрягается ещё лишних 40 часов.

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

Поддержка устойчивых темпов

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

Когда я обо всём этом думаю, я всегда вспоминаю об адвокатах. Адвокат-новичок прикладывает огромные усилия и тратит массу времени — таков общепринятый способ «пробиться» в этой области.

Ни один программист не хотел бы, чтобы его сравнивали с адвокатом, но часто ситуация схожа. Вот только разработчик никуда не «пробивается» при помощи этих сверхурочных (конечно, если вы не работаете на одну из консалтинговых корпораций «большой четвёрки» — но в этом случае вы с тем же успехом могли стать адвокатом).

Итак, адвокат против программиста: кто из них тупее?

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

Не говоря уже о проблемах со здоровьем, которые могут возникнуть, если долго заниматься одной и той же деятельностью (даже в Советском Союзе были ограничения, касающиеся долгого сидения за работой, хотя эти ребята больше всех любили выжимать пот «на благо всего народа»). И как насчёт диеты? На одной кока-коле далеко не уедешь — бедный Джон не дотянул и до 40.

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

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

В дополнение к теме: Овертаймим? А как насчет результатов?