Ранее мы уже переводили материал о негативном воздействии атмосферы крупной компании на работу программиста. Алан Картер, автор статьи, публикуемой сегодня, пытается рассмотреть эту проблему с физиологической точки зрения.
Интересные замечания автора о целостности мышления при решении задач и психологической стороне работы программиста — ниже
Мне очень нравится смотреть по телевизору гонки «Тур де Франс». Захватывающее зрелище, когда множество велосипедистов выкладывается на все сто, сбившись в плотную группу, чуть ли не сцепляясь педалями. В голове пелетона идут лидеры — элитная группа атлетов, между которыми этап за этапом передается знаменитая желтая майка лидера. Их окружают операторские автомобили и возбужденные люди на мотоциклах… И как раз это меня удивляет больше всего. В этой группе собираются одни из наиболее умелых и подготовленных ныне живущих спортсменов, они работают на пределе возможностей, а из-за этих зевак им приходится дышать выхлопными газами!
Мне кажется, что программист, работающий в напряжении, подобен гонщику в желтой майке, задыхающемуся от дыма моторов. Стрессовые условия принципиально несовместимы с максимальной производительностью труда. Что касается инженера, он в условиях стресса вообще может оказаться неспособен сделать что-то путное (ниже я расскажу о том странном меньшинстве, представители которого способны трудиться под давлением).
Стресс негативно влияет не только на работу инженеров. В отчете корпорации RAND «Стресс и производительность: обзор литературы и ее применимость в военной сфере» описано, как нейрофизиология влияет на познавательную деятельность и принятие решений в военных условиях. На первый взгляд может показаться, что стресс, испытываемый под вражеским огнем, несравним с тяготами офисной жизни, но дело в самом стрессе, а не в его степени. В ходе эволюции мы выработали универсальный физиологический отклик, который срабатывает и при виде саблезубого тигра, и при артобстреле, и при офисном давлении. Такая аналогия вполне уместна. Кроме того, пусть процесс анализа военных опасностей и не менее насыщен и сложен, чем разработка софтверного проекта, результат такого анализа всегда предельно конкретен. А вот программистам всегда приходится иметь дело с абстракциями. Поэтому при сравнимом уровне стресса в боевой обстановке и при программировании воздействие этого стресса на когнитивную деятельность во втором случае будет более выраженным. В вышеупомянутом отчете обобщены эффекты, оказываемые стрессом на следующие человеческие качества:
• абстрагирование от периферических раздражителей;
• способность принимать эвристические решения;
• снижение производительности в результате негибкости труда или узости мышления;
• потеря способности к анализу сложных ситуаций, ухудшение способности оперирования информацией.
В мире инженера любое непредусмотренное последствие или возможность найти ошибку в проектном предложении начинается с «периферического раздражения». С чего-то, о чем ты до сих пор не задумывался. А ведь как часто приходится слышать от людей «Меня не волнует, что что-то явно не работает — главное, придерживаться утвержденного плана!» Следует ли говорить, что программист, «потерявший способность анализировать сложные ситуации и оперировать информацией», должен отправиться в отпуск до тех пор, пока вновь не обретет эти умения?
Давайте рассмотрим эти проблемы в контексте повседневной реальности программиста. Преподаватель информатики Марк Газдайл (Mark Guzdial) сформулировал в заглавии своей статьи важнейший вопрос: «Почему программирование — такое сложное занятие?». Вот один из возможных ответов, который он предлагает:
…по природе своей программирование — это решение задач на смекалку. Все мы сталкивались с загадками вроде «есть 9 точек — зачеркните их четырьмя линиями» или «вот карта дорожек с односторонним движением. Пройдите из точки А в точку B, если можно лишь два раза свернуть налево и три раза — направо».Все мы умеем проводить линии или поворачивать. Сложность задачи заключается в том, чтобы объединить имеющиеся фрагменты информации именно таким способом, который позволяет решить поставленную задачу».
Это напоминает рассуждения о такой когнитивной гибкости, которая помогает находить компромиссы между разновидностями алгоритмов и арсеналом, доступным в конкретном языке. Как реализовать алгоритм А на языке L? Если изменить алгоритм, может ли реализация получиться яснее, проще, надежнее? Если мы можем выбирать как язык, так и детали реализации, то перед нами встает еще более разносторонняя проблема (расширяется поле поиска). А решать такую проблему зачастую приходится «на одном озарении».
В одном из своих традиционно проницательных сочинений, «Как удержать программу в голове», Пол Грэм отмечает:
Хороший программист, интенсивно работающий с собственным кодом, может держать его в голове, подобно математику, который всегда помнит о проблеме, решением которой он сейчас занят. Математик не отвечает на вопросы, излагая соображения на бумаге — так только в школе учат делать. Большая часть работы протекает у него в голове: исследователь пытается понять пространство задачи настолько полно, чтобы его можно было «обойти по памяти». Именно так можно вообразить себе прогулку по дому, в котором вы выросли. В идеале программирование должно быть таким же. Вы держите в голове всю вашу программу и можете мысленно манипулировать ею, как хотите».
Да, для этого требуется отличная оперативная память. Если же оперативная память ухудшается (сегодня известно, что и у человека, и у обезьян именно это происходит в результате стресса), то человек не сможет вот так работать над проблемой. У специалиста не остается иного выхода, кроме как решать проблему максимально сосредоточенно, работать процедурно, всегда иметь возможность обосновать каждый шаг, прежде чем сделать его. Но общее представление о проблеме в таком случае теряется. Вновь послушаем Грэма:
Среднестатистические программисты, работающие в типичных офисных условиях, никогда не мыслят в таких масштабах. Хуже того, такие программисты из обычного офиса никогда по-настоящему не понимают проблем, которые им приходится решать. Противоречие кроется в самом словосочетании «софтверная компания». Хороший программист, оказавшись в крупной организации, рано или поздно начнет с ней конфликтовать, так как такие организации заточены на подавление естественных стремлений программиста».
Полагаю, что Грэм правильно описывает такой конфликт, но ошибочно понимает его причину. Проблема не в возможности заменить любого сотрудника, а в том, что корпоративная мотивация, структура и политика в значительной мере основываются на стрессе, давлении и дискомфорте. Здесь можно вспомнить знаменитые «Хэллоуинские документы». Это попавшие в свободный доступ внутренние материалы Microsoft, в которых обсуждается Linux. Так вот, там есть следующая неоднократно высмеянная фраза:
В более дальновидных организациях нужная структура обеспечивается сильным, стратегически мыслящим руководящим составом».
Неужели автор действительно испытывает раболепие перед своим Лучезарным Лидером, так что без лишних напоминаний опускается до такого подхалимства? Это искреннее признание, либо каждый сотрудник в ужасе ожидает, что Господин Гейтс вышвырнет его на улицу, если он не будет кланяться и расшаркиваться? Да и мог ли самый успешный бизнесмен в мире быть настолько узколобым, чтобы просто увольнять недостаточно покорных сотрудников? Конечно же нет! Но в корпоративной среде считается нормой, что люди должны вести себя так, как будто над ними висит постоянная угроза увольнения. А реальность такова, что достаточно принять такие правила игры — и игра превращается в реальность. Страх становится обычным делом, к нему даже привыкаешь. Именно в этом, как мне кажется, заключается истинный конфликт между программированием и корпоративизмом. Именно привычный всепроникающий стресс делает инженера невротиком, не способным делать свою работу.
В статье Грэма также читаем:
Опасность стресса кроется не в том, насколько он длителен, а в том, насколько он проникает вам в мозг. Программист вполне может выйти из офиса, пойти купить себе бутерброд, не переставая при этом думать о коде. Но если вас некстати оторвут от работы, вы можете забыть обо всем полезном за тридцать секунд».
Это очень важное замечание. Большинству программистов когда-либо доводилось испытывать то ужасное исчезновение всех мыслей, которое бывает при несвоевременном вмешательстве в работу. Часто инженера прерывает какой-нибудь мелкий менеджер, желающий завести кафкианский спор о каком-нибудь «коде для тайм-букинга». Программист отвечает: «Я занят», но клерка это не волнует.
Давление, позволяющее заставить целую организацию работать в стрессовом состоянии, — тема для отдельного разговора, но большинство из нас неоднократно с этим сталкивалось. Независимо от деталей вас загоняют в угол. Вы не сможете работать спокойно. Этот менеджер будет висеть над вами и зудеть: «Но… только… но… только…», пока вы твердо не скажете ему «Нет!». Но бывает, что вы решаетесь на это слишком поздно. Вы проиграли. Потеряны часы, потраченные на погружение в проблему, на весь оставшийся день программист выведен из строя.
Все эти проблемы отлично описываются с неврологической точки зрения. Этот клерк, подвергающий программиста бюрократическому стрессу, стремится таким образом заострить внимание инженера на какой-то узкой проблеме. А та программа, которая варилась в голове у инженера, оттуда моментально вылетает. В некоторых организациях с программистами это происходит постоянно, день за днем, так что, бывает, проходит целая неделя — а никакого прогресса достичь не удалось. В итоге программист переживает «терапию отвращения» и начинает отлынивать от проработки всей задачи по второму кругу.
Разумеется, менеджер не ведает, что творит. По многим причинам менеджеру вообще редко приходится заниматься чем-либо, кроме сосредоточения на узкой проблеме.
Если попытаться обобщить одним словом все умения и навыки, которые безнадежно подавляются в атмосфере стресса, то я бы выбрал термин «соприкосновение» (в оригинале — juxtaposition — прим. пер.). Это способность держать в голове несколько сущностей, сравнивать и соотносить их структуры. Признав это, мы видим, что задача программиста — не просто ковыряться в коде, над которым работаешь в данный момент. Без нужного «соприкосновения» становится очень сложно анализировать полезность/риски. И действительно — мы видим людей, тратящих целые недели на всевозможные «оптимизации». Излишне напоминать, что на внедрение таких оптимизаций может уходить в разы больше средств, чем они позволяют сэкономить.
Аналогично усложняется и анализ рисков. Например, если вы не представляете всех нюансов документации API, проблем портируемости и совместимости с компиляторами, не можете учесть административных задержек, связанных с лицензированием и т. д., эксплуатационные издержки приближаются к фактической цене продукта. Проекты гибнут в борьбе с непредвиденными проблемами (которые, однако, можно было предвидеть), вызванными «инструментами» и сторонними компонентами.
В своей статье «Опасности обучения на Java» Джоэл Спольски упоминает «программистов без той части мозга, которая отвечает за указатели или рекурсии». В этом саркастическом замечании Спольски проявляет удивительную интуицию. Несомненно, он очень внимательно наблюдал за своими командами. Я не согласен с Джоэлом лишь в том, что, по моему опыту, у всех есть эта важнейшая часть мозга. Дело лишь в том, что для понимания работы с указателями и рекурсией необходим определенный уровень соприкосновения знаний, а большинство людей им не обладают.
Кроме того, теоретически все должны уметь замечать вещи, происходящие вокруг, даже без специального напоминания об этом. В своей книге «Гедель, Эшер, Бах» Дуглас Хофштадтер рассказывает об игре MIU, в которой требуется преобразовывать последовательности символов в соответствии с правилами. Хофштадтер отмечает, что включающие правила легче применять, чем исключающие, и что для понимания свойств системы необходимо рассмотреть ее со стороны. Это требуется, чтобы рефлексировать о наблюдаемом и спонтанно замечать происходящие вещи. Человек, сосредоточенный на решении узкой задачи, не сможет судить о системе таким образом, не увидит, как ее можно упростить, упустит другие интересные идеи. Вот мы и начинаем понимать феномен «раздутых программ» (bloatware) — причем, такое «разбухание» наблюдается не только при написании софта, но и при усложнении бюрократических структур. Все работают в напряжении, не обойтись без синоптика, знающего, откуда ветер дует.
В своей книге «Мифический человеко-месяц» Фред Брукс заглядывает еще глубже и говорит, что сущность хорошего дизайна — это концептуальная целостность. Может ли человек оценить степень такой целостности, если не в силах сопоставить все детали системы?
В качестве последнего примера приведу цитату из монографии Дейкстры «EWD936», где он отмечает:
Анализируя структуру традиционных математических доказательств, замечаешь, что равенство — наименее активно используемая логическая связь. А ведь считается, что оно применяется повсюду. Недостаточно активное применение равенства, то есть неспособность опираться на присущие системе симметрии, зачастую удлиняет доказательство вдвое, вчетверо и даже больше».
Логично предположить, что Дейкстра имеет в виду именно работу в узком контексте. Чтобы использовать и понимать равенство, необходимо уметь сопоставлять фрагменты системы. Правда, в этом фрагменте Дейкстра говорит о важном и редко замечаемом аспекте, который заслуживает отдельного обсуждения.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.