Подвержены программисты эмоциональному выгоранию больше чем представители других профессий? Если да — какие факторы риска сушествуют и как с ними бороться?
Данный текст не претендует на научную глубину и тщательность в подборе материалов и аргументов. Это просто рассуждения автора на интересную ему тему.
Данная статья является переводом поста в моём англоязычном блоге.
Недавно ко мне в гости заходил мой хороший знакомый. По профессии он психиатр. В разговоре он упомянул, что к нему в последнее время обращается все больше программистов с диагнозом 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%. Программисты вынуждены работать постоянно в выматывающем режиме высокой креативной отдачи и психологической концентрации.
Ну и что? А как избежать стресса? (Или как начать новую жизнь в новом году)
Как я уже отмечал, я далек от психологии. Отнимать хлеб у своего приятеля, его коллег, авторов многочисленных книг и фильмов на эту тему я тоже не пытаюсь. И все-же, рискну дать несколько простых советов. Возможно ву как и я даёте себе на Новый Год зарок начать жить правильнее. Тогда вам мои советы могут пригодится.
- Больные герои никому не нужны. Помните, что для достижения результата необходимо хорошее физическое самочувствие и творческий подьем. Если их нет, нет и результата. Вам весь день нездоровилось и код написан плохо. Не мучайтесь вечером по этому поводу. Не пытайтесь дома доделать не сделанное днем с градусником подмышкой. Лучше попейте чая с медом и пораньше ложитесь спать.
- Правильная смесь. Программирование можно сравнить с прыжками в длину. Только прыгун вначале разбегается все быстрее и потом прыгает, а у программиста возникает озарение-решение (прыжок) а потом он доделывает необходимые рутинные операции. Невозможно прыгать восемь часов к ряду. Перемешивайте творческий полёт и рутину.
- Умейте релаксироваться в течении рабочего дня. Руководители проектов, особенно больших, склонны перебарщивать с малополезными для программистов заседаниями. Если уж нельзя их избежать, не злитесь на потерянное время и на болтливых участников совещания. Подумайте о чем-нибудь своем, пустив болтовню по вторичному тракту сознания. Научитесь принимать при этом вдумчивое и заинтересованное выражение лица.
- Планируйте каждодневный успех. Разбивайте задачи на части, про которые можно ожидать, что вам удастся запрограммировать их за час или два. В крайнем случае, упорядочите ваши планы на день так, чтобы оставалась надежда что-то «закруглить» до окончания рабочего дня.
- Заканчивайте рабочий день победой. Если вы успешно решили задачу за полчаса или час до окончания рабочего дня, не начинайте новую. Скорее всего, «аккумуляторы» у вас в голове уже «подсели». Может у вас накопилась парочка организационных заданий типа отчета о командировке? А если через 5 минут вам надо выходить, чтобы успеть на электричку, выключайте компьютер и не пытайтесь написать ещё строчку. Написанная строчка скорее всего ничего не даст, а вот из-за пропуска электрички вы на себя разозлитесь. И самое главное – если вы останетесь на работе ещё на два или больше часов, решение скорее всего не придёт. А вот по дороге домой оно очень даже может прийти. Я проверил это на себе много раз.
Повторюсь ещё раз. Данный текст не претендует на научную глубину и тщательность в подборе материалов и аргументов.
Ваше мнение мне было бы очень интересно узнать. Поэтому я очень прошу вас ответитиь на вопросы внизу.
А если вам мои аргументы не понравились, то отразите пожалуйста ваши возражения в комментариях, а не в минусовании статьи. Как-никак Новый Год на носу.
Иллюстрация автора «Ночной кошмар JavaScript-программиста»
Комментарии (36)
bioroot
29.12.2017 23:48Мне кажется главной является часто отмечаемая проблема отсутствия физических результатов. Вы фигачите код целый день как проклятый, разворачиваете какие-то админки, делаете запросы к серверам статистики, настраиваете биллинг, а в результате ваших каждодневных усилий на каком-нибудь левом сайте просто рисуется баннер, который будет бесить пользователей. Трудно не выгореть от такого даже при хорошей зарплате и прочих плюшках.
snp
30.12.2017 01:13Почему отсутствие? А нафигаченный за целый день код для вас не результат разве? Или факт того, что заработало в итоге то, что вы делали?
Levitanus
30.12.2017 10:43+5часто делаешь фигню, котора никому не нужна. (может, только CEO считает, что она пригодится)
И вот эта бессмысленность и правда удручает.snp
30.12.2017 12:07А полученный опыт? Если работа потребовала целый день (а не 5 минут), то наверное она достаточно сложна, чтобы сама по себе вызывала удовольствие.
Есть ещё момент — когда работа делаешь одни и те же вещи несколько раз, но каждый раз лучше. Например, есть такой эффект, когда с нуля пишешь кусок кода (или опять разворачиваешь какую-то админку), желательно не сразу, а через неделю-месяц, то результат гораздо лучше выходит. И это очень радует.
Пользователи же обычно всегда недовольны и не могут оценить результат по достоинству.
visirok Автор
30.12.2017 13:46+1Согласен с Вами по второму пункту наполовину. К сожалению, мне очень редко предоставлялась возможность вернуться к своему коду и улучшить его на основании новых знаний или достигнутого пониманимания. Приходили новые проекты с новыми технологиями или задачами. Всегда приходится учиться на лету и что-то делать с ощущением, что можно сделать лучше. Потом понимаешь или узнаёшь, как сделать лучше, но времени на это уже нет. Но это мой личный опыт. На обощение не претендую.
avost
30.12.2017 17:50Если работа потребовала целый день (а не 5 минут), то наверное она достаточно сложна, чтобы сама по себе вызывала удовольствие
Здесь мерилом работы считают усталость? Нет. Возможно, кто-то способен удовлетвориться количеством закрытых в трекере тасков, лично мне это не кажется достойным результатом того, на что я трачу свою единственную и неповторимую жизнь…
Пользователи же обычно всегда недовольны и не могут оценить результат по достоинству
А вот когда получаешь гневные письма от разъярённых пользователей, чувствуешь, что хоть кому-то твоя работа действительно нужна :).
Levitanus
30.12.2017 18:23+1кстати, очень хороший пример.
Некоторые баги мы сами находим, спустя пару месяцев после релиза. Баги достаточно заметные, а комьюнити достаточно активное в обратной связи. А это наводит на мысль, что конкретная фича была разработана просто так)
А полученный опыт? Если работа потребовала целый день (а не 5 минут), то наверное она достаточно сложна, чтобы сама по себе вызывала удовольствие.
Сложная != объемна :)
Я раз в два месяца выхожу на сцену с новой сольной фортепианной программой: Это работа сложная. Или неделю назад сел писать autodoc для маленького, но храброго языка. Может не такая сложная, но со своими задачами, где есть над чем голову поломать.
А на работе работа объемная… тут либо выгорать, либо менять работу, я решил, что выгорать вредно)
jaiprakash
30.12.2017 11:24Выгорал и когда писал под железо (микроконтроллеры). Там был физический результат, т. к. железо тоже делал сам. Но и цена ошибки была большая.
AllexIn
30.12.2017 21:45А почему вы обобщили всех программистов?
Вы описали даже не большинство. Например, сайто писатели прекрасно видят результат своего труда.
И таких специализаций, где результат «налицо» — много.
brrr
30.12.2017 01:03+1Эмоциональное, как и профессиональное выгорание есть везде. Как мне кажется, в статье затронуты лишь внешние проявления и их неглубокий уровень осознания. Ведь программирование и ИТ — это гигантская сфера со всеми вытекающими из этого трудовыми, профессиональными, человеческими, экономическими отношениями. И набор условий может быть грандиозно уникален. А в корне всего — обычный конфикт личности. НО! Это уже вопросы психотерапии, которые должны разбирать наверное профессиональные "мозгоправы". В качестве отправной точки статья прекрасна.
Timur_n
30.12.2017 01:14+1Я скажу спасибо автору. такой взгляд на проблему мне показался близок и советы полезны, с наступающим всех) Да! И упоминание о «старой школе».
riky
30.12.2017 03:29Тоже задумывался над данной темой. Выгорание часто происходит у «творческих» программистов. Специфика професии такова, что среди программистов таких много. Эти люди создатели, любят творить и изобретать что-то новое, исследовать. Но с годами работа становится довольно рутинной. Ты понимаешь что можешь творить великие вещи, но на работе приходится делать никчемные небольшие улучшения.
Мало того что незначительные так они еще и зачастую не делают этот мир лучше. Профессия полицейского, хирурга, пожарника с этой точки зрения куда лучше, они хотя бы знают что цена их работы — спасенные жизни людей, которые будут им всю жизнь благодарны. В отличие от верстки баннеров, или вывода блока с похожими товарами чтобы люди покупали все что им надо и не надо, главное у компании было больше продаж.
Еще одна особенность — люди становятся довольно обеспеченными, и с другой стороны достаточно осмысленными, чтобы понимать что много вещей (и денег) им не так и надо. Деньги есть, очень не малые и они не делают их счастливыми.
я думаю, в большинстве случаев, причина в потере смысла жизни.snp
30.12.2017 12:02+1Профессия полицейского, хирурга, пожарника с этой точки зрения куда лучше, они хотя бы знают что цена их работы — спасенные жизни людей, которые будут им всю жизнь благодарны.
Это достаточно простой путь. Делаешь добро, тебя благодарят, тебе хорошо. Так кто угодно может.
Нам же нужно находить свои смыслы, не привязанные к чьей-то внешней оценке. Работа становится рутинной, если мы не развиваемся и не расширяем свои границы. И простора у IT'шников тут гораздо больше. Просто двигаться дальше, вперёд новым вызовам, изучать новые технологии. Если совсем скучно, а хочется, чтобы благодарили — ну так можно на конференциях рассказывать о своих достижениях.
Деньги есть, очень не малые и они не делают их счастливыми.
Деньги дают независимость. Например, если можешь просто бросить надоевшую работу и устроить себе на год отпуск. А излишки всегда можно на благотворительность пустить :)disakov
31.12.2017 00:41Это достаточно простой путь. Делаешь добро, тебя благодарят, тебе хорошо. Так кто угодно может.
Надеюсь имелся ввиду путь получения благодарности, а не работу, которую надо проделать для ее достижения.snp
01.01.2018 15:51«Простой для понимания» скорее. Потому что легко укладывается в много вековой опыт человечества с «вечными» историями про добро-зло, героев и т.п. Архетипы героев и т.п.
Программист, как персонаж истории, уже более неоднозначный и результат его работы тоже.
riky
01.01.2018 14:39Да, но и выгорают не все подряд. Многие ли устраивают себе отпуск на год? И большинство все таки работает рутинно, хотя в теории можно и по-другому. На тостере много вопросов задавали, как все надоело.
Прокрастинация и выгорание мне кажется одного поля ягодки. Просто разные степени.snp
01.01.2018 16:12Не всем отпуск на год нужен. Кто-то может и со скуки помереть. Это был просто пример.
Я скорее имел в виду, что если человек готов каждый день
умереть, как самурайуволиться с работы «в никуда», это уже что-то значит.
И большинство все таки работает рутинно, хотя в теории можно и по-другому.
Мне кажется, за этим может лежать самое разное. Например, так привыкли. Просто реагировать на внешние стимулы и плыть по течению. Либо это выученная беспомощность. У кого-то нет внутреннего перфекциониста, который заставляет делать вещи качественно, а не просто чтоб закрыть тикет.
много вопросов задавали, как все надоело.
И у любого человека есть более сложные потребности — в уважении, самореализации. Себя не обманешь и оно будет давать о себе знать.
Samouvazhektra
30.12.2017 09:26+7Интересно, а мне всегда казалось, что выгорание происходит из-за… "горения". Из-за почти маниакального прихода, когда пишешь очень увлеченно. У многих профессий не длительный цикл активного применения усилий, требующий концентрации: сделал работу/операцию — идешь домой. Для программиста процесс достижения результата может быть практически бесконечным, придумали фичу, рефакторинг, сменилось требование, заказчик передумал… а в случае пет-прожекта без тз, тем более. В какой-то момент эйфория отступает — надолго застрял на каком-то баге, или выложил и получил критику коммьюнити, QA разнес в пух и прах, появилось аналогичное решение, причем лучшее, просто в мозгу щёлкнуло что всё гавно, и то что ты делаешь нафиг никому не нужно и прочие деструктивные мысли. Аналогичное характерно и для других творческих профессий — художников, писателей и т.п. Обычно депрессивное состояние проходит довольно быстро, но если такие переходы будут частыми то наверное можно и в больничку загреметь, или "выгореть"
lxsmkv
31.12.2017 05:15мне бы очень хотелось понять, откуда у разработчика такая эмоциональная привязанность к продукту своего труда. Это наблюдаемый факт, но причина этого феномена мне не понятна.
Я думаю если бы можно было бы уговорить разработчиков не привязываться к с результату своего труда они были бы во многом счастливее, и не были бы порой такими токсичными (вы знаете о чем я).
Для программиста процесс достижения результата может быть практически бесконечным
Вот работая в коллцентре или на фабрике тоже не видешь результата своей работы. Но есть микрорезультат — обслужил одного клиента, обработал одну деталь. У разраба действительно пока твой код заработает в конечном продукте могут пройти месяцы. Но есть и микрорезультаты, закрыл тикет, закрыл задачу, сделал коммит.
Аналогичное характерно и для других творческих профессий — художников, писателей и т.п
Разница в том, что художник полностью отвечает за весь продукт. Если бы художество работало как производственный процесс, были бы люди смешивающие краски, подготавливающие холст, подающие кисточки, сравнивающие результат с текстовым описанием пейзажа. И художник бы ушел во фриланс. Потому что никакой свободы.
Но вот что интересно. Разработка это и не про творчество. Разработка про выполнение части работы каждым участником. Из этих частей потом сложится продукт. Зачастую программист просто переводит человеческий язык на язык программирования. Есть замечания? Поправил, забыл, живешь дальше. Программист на проекте — не создатель книги — он «литературный негр», ghostwriter. Он просто выполняет функцию. Поэтому и нет никакой похвалы со стороны начальника. И она не нужна. Ему нравится писать текст, он пишет текст, ему дают такую возможность. Ну и все.
soshnikov Сразу тут отвечу и про необходимость самообразования в профессии разработчика. Литературному негру тоже постоянно нужно читать книги и кто знает что еще делать чтобы соответствовать новым рыночным требованиям.
Samouvazhektra
31.12.2017 12:06Я приводила примеры больше с позиции работы над собственным/курируемым/проектируемым проектом, а не просто "негро-работы".
Но есть и микрорезультаты, закрыл тикет, закрыл задачу, сделал коммит.
это да… это норм. воркфлоу когда просто работаешь по чек-листу, но это не "горение"
soshnikov
30.12.2017 11:23+5Тут есть еще такой момент — нам приходиться постоянно обучаться. Наверное, другой такой профессии нет, где требуется такое интенсивное самообразование.
А потом заходишь на хабр, читаешь какую-нибудь крутую статью и ощущаешь себя полным бездарем.
Hokum
30.12.2017 15:02+1Не согласен, что можно рассматривать сработавшие собственноручно написанные тесты как "расплату". Если уж сравнивать программиста с художником, который пишет большое полотно, то правки кода — это мазки кистью, а тесты — способ отойти от картины, чтобы увидеть правильно ли лег мазок и каким должен быть следующий. А расплата — это когда баг выловился в продакшене. А учитывая, что большая часть программистов не пишут системы от которых прямым образом зависят жизни людей, то эмоциональная нагрузка не будет высокой. Если только нет "синдрома отличника", но им приходит не сладко не зависимо от выбранной профессии.
Я согласен с большинством высказавшимся выше. Программист может не видеть конечного результата своей деятельности. Я сейчас не о пройденных тестах или закрытых багах, а о конечном продукте. Хорошо когда разрабатываешь, навигатор для автомобиля и сам им пользуешься — ты можешь потрогать, пощупать результат. Ты можешь выступить в качестве пользователя. Проще получить обратную связь от пользователей и ты можешь понять, что они скажут. Гораздо сложнее почувствовать результат, если пишешь прошивку для маршрутизатора, какого-нибудь узла автомобиля или приложение которым в силы специфики сам пользоваться не будешь. Ты что-то пишешь, пишешь, пишешь. QA проверяют, это уходит заказчику, он принимает и все. Тишина. Ты не знаешь хорошо или плохо пользователю стало от того, что ты создал. А может то на что было потрачено гигантское количество усилий никому и не видно! Зато если бы сделал плохо, то все сразу бы заметили подвисающие сервисы, пропадающие данные и тому подобное. Возможно с точки зрения получения обратной связи от пользователей и возможности пощупать результат немного легче программистам фронтенда и UI. Результат их работы 100% заметят пользователи. И ты сам можешь запустить и посмотреть.
Так же не маловажным является актуальность используемых технологий. Стек устаревших технологий может быть обусловлен спецификой отрасли — необходимостью сертификации, специфичным оборудованием или просто большим проектом, который сложно переводить на новый стек. А бывает просто банальное нежелание остальной команды менять, что-то. И при этом ты не делаешь чего-то уникального. Как результат — ощущение, что ты каждый день отстаешь от отрасли, твоя конкурентоспособность на рынке падает и переход в другое место может быть связана с существенными финансовыми потерями. Все таки хочется некоторой стабильности в относительно долгосрочной перспективе.
Опять же расхождение ожидаемого результат деятельности и реальности. Думал, что пользователи побегут пользоваться продуктом, о нем расскажут в новостях и на конференциях. А на деле почти никто знать не знает, а конечным пользователям абсолютно все равно, что ты там для них улучшил и что теперь вместо 30 секунд им надо ждать только 20. Мы чаще встречаемся с отрицательной обратной связью — просто потому, что пользователь с меньшей вероятностью пойдет писать благодарственные письма, если все работает так как он ожидал (а ожидания обычно высоки). А вот если что-то не так, вылезают какие-то незначительные баги, но раздражающие конкретного пользователя (никогда не знаешь, что именно будет раздражать одного, а другой этого может и не заметить), то вероятность негативного отзыва гораздо выше.
P.S.
Желаю всем нам в новом году побольше положительных отзывов на наш повседневный труд!
ToSHiC
30.12.2017 19:07Как уже заметили выше, выгорание -оно из-за горения. А горят программисты потому, что не могут выключиться из работы. Когда ты переходишь со стадии "набирать код" в стадию программирования, то для создания программы или поиска бага код уже не так сильно нужен. И вечером, когда закрываешь ноутбук на работе, это не означает конец работы, в отличие от слесаря, например. И ты продолжаешь думать, как завтра ты поменяешь код, или почему же еще может случаться вот эта фигня.
И все это очень сильно усугубляется тем, что у многих разработчиков и хобби тоже писать код, ну или там ардуинки всякие. А надо бы регулярно заниматься такой деятельностью, при которой работает та часть мозга, которая отвечает за реальный мир, за движение, желательно на свежем воздухе, и тоже требует концентрации. Танцы, горные лыжи/сноуборд (но чтоб не на автомате ехать), да почти любой спорт на результат. Отлично заставляет мозги отключиться от программирования.
А если вдруг есть проблема с тем, что некуда девать деньги — автоспорт ждет вас, там можно разумно потратить любое количество денег :)
Germanets
31.12.2017 00:06И вечером, когда закрываешь ноутбук на работе, это не означает конец работы, в отличие от слесаря, например.
У слесаря тоже вполне себе есть возможность продумать весь вечер о возникших протечках и способах их устранения… И мне кажется, что вопрос выгорания программиста связан в первую очередь с тем, что программист, в отличии от слесаря, имеет куда больший простор для размышлений и практически всегда имеет кучу задач и проблем…
Hardcoin
30.12.2017 20:38+1И согласитесь, что малообщительность вряд ли может приводить к стрессу а затем к burnout.
Ещё как может. Особенно если малообщительность не из-за внутренней удовлетворенности, а по причине отсутствия общения интересного. Если нет достаточного количества хорошего общения — это стресс ещё тот.
visirok Автор
30.12.2017 21:36Ваше замечание интересное и верное, как мне кажется. Я размышляю, а не отобразить ли суть высказанных идей в виде Mind Map.
samsdemon
31.12.2017 00:39У вас есть очень срочное задание, которое необходимо делегировать, но вы не знаете кому. Рецепт: найдите самого занятого и продуктивного и поручите именно ему.
имхо.
Срочное и важное — ну, может быть, ок, но тогда вопрос, готовы ли вы жертвовать качеством. Занятые и продуктивые люди редко заняты фигнёй; соответственно в треугольнике время-стоимость-качество время останется таким же (вы же хотите, чтобы и то было в срок, и это, плюс всё срочное), стоимость тоже (один человек работает), итого — провалите по качеству и то, и другое. Оно вам надо?
Срочное и не важное — зачем? Можно спокойно дать любому другому не занятому человеку; точно есть люди, которых прекрасно мотивирует срочность.
Что бы сделал я — спросил бы у этого классного парня, кому можно передать это задание, и что вообще с ним можно сделать, вместо прямых поручений в незнакомой команде.
arheops
31.12.2017 03:30Тоесть в профессии шофера расплата не моментальна(машина в кювете).
Ага. Как и недоконца прикрученное колесо неотвратимо в профессии механика.
Как и сачкование практически в любой профессии. Включая шофера и механика, да.
Имхо программисты чаще ходят к психологу просто потому, что у них на него есть деньги и время.
tangro
31.12.2017 20:30+1Интересно сравнение интенсивности эмоционального выгорания программистов с докторами и полицейскими в последнем опросе. Доктора и полицейские каждый день, каждую минуту всё-таки делают очень общественно важную и полезную работу. И даже если они допускают ошибку — то это всё же ошибка при попытке, например, спасти чью-то жизнь.
А чем занимаются программисты? Да половина из нас пилит игры, разрабатывает какие-то казино, клепает баннерокрутилки, кто-то вирусы пишет и боты, кто-то для форекс-лохотрона ПО, плюс куча унылой бюрократизированной корпоративщины. Да мы ещё и ошибки при этом делаем! Ну, блин, мало того что цель часто откровенно глупа или зла, так мы ещё и достичь её оптимальным образом не способны. Как уж тут не «выгореть».visirok Автор
01.01.2018 18:10+1В профессии врача наверное куда больше рутины и ограничений. Как-то я был на приёме у кожника. Он спросил кем я работаю. Узнав, сказал — я Вам завидую. У вас можно делать совсем новое. А вот для меня в Вашем случае выбор ограничивается тремя мазями, разрешенных к применению при данном заболевании. А у следующего пациента другой диагноз, но тоже примерно такой же выбор.
Ирония судьбы заключалась в том, что мне в конце концов помогла не его мазь, а смена модели бритвы.
shoomyst
Забавная пятничная заметка получилась, не имеющая практически ничего общего с реальностью :)
Ну и про ошибки слесаря, хирурга и программиста: написал неверную функцию определения азимута — и вот уже спутник летит в океан))
brrr
Не соглашусь, статья — прекрасная иллюстрация проявлений современного невроза программиста. Но вот определить, откуда он — иногда задача воистину трудная и противоречивая.
vasIvas
Тоже не соглашусь, но виденье у меня другое. Когда человек выбирает профессию отличную от программирования, то он мысленно подписывается по рутиной. Слесарь знает что всю жизнь будет
крутить краны, врач — лечить те болезни, на которых специализируется, банкир — считать.
Программист же хочет создать сразу все — игры, программы, ИИ, программирование техники, как в startrack.
Вобщем он хочет быть немного богом.
И по себе могу сказать что стрессы начинаются, когда долго делаешь один проект, а перечисленные в статье факторы лишь усиливают стресс. Если начать больше спать, быть общительнее или заниматься медитацией, то устранятся лишь усилители стресса, но не причина. Но если попробовать перейти на новый проект, то стресс моментально проходит и снова появляется желание не спать и не есть.
В моем случаи это так и поэтому я считаю что задача руководителей прежде всего не дать чувакам заскучать.
Vasiliskov
Реальный случай: перемешали в разных частях кода метры и футы, и спутник вместо мягкой посадки на Марс впечатался в него на высокой скорости.