А вы не программируете себе burnout?

Подвержены программисты эмоциональному выгоранию больше чем представители других профессий? Если да — какие факторы риска сушествуют и как с ними бороться?

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

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

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

Откуда берётся стресс у программистов?

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

Как программисты спят?

Наша жизнь делится на сон и бодрствование. Начнем со сна.
Есть много профессий, где люди работают посменно в разное время суток, со сменами разной продолжительности или спят в режиме постоянной готовности (английский термин on-call и немецкий – Bereitschaft). К числу таких профессий принадлежит и близкая нам профессия системных администраторов. Программисты новой разновидности (т.н. DevOps) затронуты больше, чем «классические» программисты. А последние также могут переживать кратковременные периоды сна в режиме on-call при запусках новой версии системы.

Но в целом профессия программиста не несет в себе риска неупорядоченного или неполноценного сна. Итак, дело не во сне.

Необщительные программисты

Время нашего бодрствования делится на рабочее и нерабочее. Разберемся сначала с нерабочим временем – вечерами после работы и выходными днями.

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

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

Итак, в поисках факторов риска мы отбрасываем свободное время тоже. Разберемся теперь с работой.

Как у всех

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

Проблема не в коллективе

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

Проблема в материале

Итак, остается «материал». Под этим подразумевается то, с чем имеет дело в своей работе тот или иной профессионал. У хирурга это человеческое тело, у учителя – ученики, у слесаря – металл, у программистов – программный код.

По отношению к материалу я хотел бы выделить следующие аспекты:

• Необратимость ошибки
• Неотвратимость проявления ошибки
• Невозможность «сачковой» работы.
• Скорость наступления «расплаты».

Итак, рассмотрим эти аспекты по порядку.

Необратимость ошибки

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

Неотвратимость проявления ошибки

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

В программировании такого не бывает практически никогда. Исключение составляют случаи, когда коллега заметит ошибку и между делом её исправит, либо внешние условия изменятся так, что ошибка и не проявится.

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

Итак, мы нашли первый фактор риска, который специфичен для профессии программиста и редко встречается в других профессиях.

Невозможность «сачковать»

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

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

С краткосрочной перспективой ещё хуже. Любой программист знает, что необходимые решения приходят в состоянии высокой концентрации и креативного тонуса. Если они пришли, путь понятен и далее остается их реализовать и написать тесты (а лучше сначала написать тесты, а потом реализовать). А вот если творческого состояния нет, можно целый день мучать себя, но результат достигнут не будет. Мне попадалась статистика, что коды, написанные и помещенные в систему версионирования сразу после праздников, бывают позже переписаны с существенно большей вероятностью, чем остальные. Вы уже догадались, почему?

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

Скорость наступления «расплаты»

По этому показателю профессия программиста достаточно уникальна и сопоставима с профессиональным спортом. Если футболист неверно ударит по мячу, то он (а также зрители, товарищи по команде и соперники) узнают об этом через секунду. Современные методы и инструменты программирования таковы, что на синтаксические ошибки IDE указывает мгновенно. А если вы работаете правильно, покрываете свой код тестами, то тесты укажут вам на алгоритмическую ошибку уже через пару минут, при следующем тестовом запуске. В отличие от футболиста, за свой «промах» программист не будет освистан зрителями. Но не надо забывать, что футболист выступает перед трибунами полтора часа в неделю и бьёт по мячу не так уж много раз за игру. У программиста же это продолжается полную рабочую неделю.

Историческое отступление: Правдивая история из 70-х годов

В этой связи мне вспомнилась одна история. Когда я только начинал свою профессиональную деятельность на Вычислительном Центре Сибирского Отделения Академии Наук в Академгородке, вычислительные ресурсы делились там между отделами «в режиме разделения времени». Выглядело это так. Каждому отделу выделялось какое-то время (например – полчаса) на одном из компьютеров. (Тогда они назывались ЭВМ). Свои задачи мы подготавливали в виде колод перфокарт. Когда подходило наше временное окно, лаборантка брала первую колоду из нашей стопки и вкладывала её в считыватель перфокарт. Компьютер её обрабатывал и подавал сигнал лампочкой. Принтер печатал на бумажную ленту результат. Лаборантка брала следующую колоду … и так повторялось, пока временное окно не закончится.

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

Тонкость заключалась в том, что если у предыдущего отдела колод было мало или они были обработаны быстро, колоды нашего отдела могли пойти в обработку раньше. Такое случалось крайне редко, но однажды мы заметили, что нам систематически «везёт».

Оказалось, что отделу, который был по плану поставлен в очередь перед нами, было запланировано много машинного времени на отладку некоего интерпретатора с языка, по сложности напоминающего подмножество Фортрана. (Сейчас это назвали бы DSL – Domain Specific Language). Интерпретатор программировал один талантливый разработчик, который поспорил с коллегами, что напишет программу так, что она заработает с первого раза. Начальство, планировавшее ресурсы об этом споре не знало, и отвело ему окна на несколько месяцев вперёд. Чем мы невольно пользовались.

Этот талантливый человек написал, набил на перфокарты, проверил (мы все тогда умели читать и понимать «дырочный» язык перфокарт не хуже русского) много тысяч строк кода без единого запуска. Но… спор он проиграл. Несколько ошибок при первом запуске нашлось. И только второй запуск, после устранения ошибок, принес желаемый результат.

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

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

Подведем итоги

Итак сформулируем основные специфические факторы стресса у программистов:

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

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

Ну и что? А как избежать стресса? (Или как начать новую жизнь в новом году)

Как я уже отмечал, я далек от психологии. Отнимать хлеб у своего приятеля, его коллег, авторов многочисленных книг и фильмов на эту тему я тоже не пытаюсь. И все-же, рискну дать несколько простых советов. Возможно ву как и я даёте себе на Новый Год зарок начать жить правильнее. Тогда вам мои советы могут пригодится.

1. Больные герои никому не нужны. Помните, что для достижения результата необходимо хорошее физическое самочувствие и творческий подьем. Если их нет, нет и результата. Вам весь день нездоровилось и код написан плохо. Не мучайтесь вечером по этому поводу. Не пытайтесь дома доделать не сделанное днем с градусником подмышкой. Лучше попейте чая с медом и пораньше ложитесь спать.
2. Правильная смесь. Программирование можно сравнить с прыжками в длину. Только прыгун вначале разбегается все быстрее и потом прыгает, а у программиста возникает озарение-решение (прыжок) а потом он доделывает необходимые рутинные операции. Невозможно прыгать восемь часов к ряду. Перемешивайте творческий полёт и рутину.
3. Умейте релаксироваться в течении рабочего дня. Руководители проектов, особенно больших, склонны перебарщивать с малополезными для программистов заседаниями. Если уж нельзя их избежать, не злитесь на потерянное время и на болтливых участников совещания. Подумайте о чем-нибудь своем, пустив болтовню по вторичному тракту сознания. Научитесь принимать при этом вдумчивое и заинтересованное выражение лица.
4. Планируйте каждодневный успех. Разбивайте задачи на части, про которые можно ожидать, что вам удастся запрограммировать их за час или два. В крайнем случае, упорядочите ваши планы на день так, чтобы оставалась надежда что-то «закруглить» до окончания рабочего дня.
5. Заканчивайте рабочий день победой. Если вы успешно решили задачу за полчаса или час до окончания рабочего дня, не начинайте новую. Скорее всего, «аккумуляторы» у вас в голове уже «подсели». Может у вас накопилась парочка организационных заданий типа отчета о командировке? А если через 5 минут вам надо выходить, чтобы успеть на электричку, выключайте компьютер и не пытайтесь написать ещё строчку. Написанная строчка скорее всего ничего не даст, а вот из-за пропуска электрички вы на себя разозлитесь. И самое главное – если вы останетесь на работе ещё на два или больше часов, решение скорее всего не придёт. А вот по дороге домой оно очень даже может прийти. Я проверил это на себе много раз.

Повторюсь ещё раз. Данный текст не претендует на научную глубину и тщательность в подборе материалов и аргументов.

Ваше мнение мне было бы очень интересно узнать. Поэтому я очень прошу вас ответитиь на вопросы внизу.

А если вам мои аргументы не понравились, то отразите пожалуйста ваши возражения в комментариях, а не в минусовании статьи. Как-никак Новый Год на носу.

Иллюстрация автора «Ночной кошмар JavaScript-программиста»