Я сколько лет на заводе козловой кран вожу, ни разу не выгорел! А эти, прям неженки!
Знакомо?
Выгорание айтишников – это уже притча во языцах. Если в своей среде IT-специалисты еще находят понимание, то во вне они сталкиваются с диким отрицанием.
Ишь какие, депрессия у него! Работать не может! Дури вам в голову напихали, вот и оправдываете свою лень!
За свои скромные семь лет на руководящей позиции мне довелось управлять разными людьми. Был опыт тимлидства над командой разработчиков. Не претендую на истину и уж тем более на какое-то серьезное научное исследование. Но все же хочу систематизировать свои наблюдения и сделать цикл статей «команда глазами начальника».
Как и всегда – крайне рад комментариям, дополнениям и противоположным мнениям. Ведь моя главная цель не транслировать свой «бесценный опыт», а скорее посмотреть со стороны на свою работу. И сделать выводы. Начну свой цикл с одной из самых горячих тем – выгорания.
Последние несколько лет я активно работал с заводами, приходилось слышать много нелестного в адрес разрабов. Для меня рабочие и ИТ-специалисты – это два полюса. Одни уверены, что на них мир держится, а все остальные фигней занимаются и ничего не производят. Для других получить профессию в ПТУ и потом всю жизнь работать по специальности сродни проклятию.
ОК, давайте попробуем разобрать основные моменты.
У нас в цеху не выгорают
Этот аргумент я слышал не только от работяг, он так или иначе сквозит во многих мнениях. Мол, как вы себе вообще представляете выгорание оператора козлового крана? Такой, ой, все, не могу больше за рычаги дергать, белый свет мне более не мил… Ну не бывает же такого???
Вообще, бывает.
Просто каждая сфера имеет свои традиции. Есть эти традиции и в решении проблем. По моим наблюдениям, все рабочие делятся на два типа. Те, кто любят прибухнуть и странные чудики с окологиковскими увлечениями. Как первый, так и второй способ – это возможность снять стресс. Я сейчас не буду обсуждать действенность и спорность этих способов. Но факт остаётся фактом. Не выгорание, а «зеленая тоска», от которой хорошо спасет зеленый же «змий». Чем вам не выгорание и терапия?
Те, кто не пьет, находят разные хобби, в которых так же отводят душу. Копание в моторе старенькой «шестерки» или выпиливание лобзиком именно им помогают вырваться из пены дней и переключиться на что-то более милое сердцу. Это точно такая же терапия, просто найденная интуитивно, методом проб и ошибок.
И все-таки, выгорание рабочих – процесс куда более редкий и не столь деструктивный, как у айтишников. Значит есть еще причины? Есть.
Техностресс
На самом деле, техностресс – это вообще, на мой взгляд, основная проблема ИТ-сферы.
Поясню. В 21м веке скорость развития технологий просто поражает. Эволюционируют языки программирования и приложения, постоянно появляется что-то новое. А для решения поступающих задач и роста айтишники еще мигрируют. То есть учат новые языки, фреймворки, осваивают новые инструменты. И этот процесс не прекращается.
Сейчас трудно освоить какую-то область, чтобы потом этим кормиться хотя бы лет десять. Сужу по своему увлечению 3D-моделированием. Видосы с разборкой работы Блендера трехгодичной давности смотреть нет смысла. Половина решений, которые показывают эти видосы, уже либо не работают, либо работают как-то иначе. Базовые принципы неизменны, но мы говорим о более глубоком погружении. И вот тут надо смотреть по принципу «чем свежее, тем лучше».
Работа в ИТ-сфере – это постоянная учеба. ПОСТОЯННАЯ.
Мне сложно привести аналогию с какой-либо профессией, скажем, времен СССР. Наверное, только какие-то топовые врачи и ученые.
Рабочий же может реально всю жизнь делать примерно одно и то же. Наш оператор козлового крана лет через тридцать вообще может не думать. Он этим краном с завязанными глазами управлять способен. И даже если привезут кран другой модели, переучиться и кормиться этим следующие лет пятнадцать вполне реально.
Если не учиться – мозг теряет пластичность, зато получает стабильность. И это, в том числе, защита от выгорания.
ОК, но как быть с высказываниями некоторых олдов? Я говорю про программистов, которые код писали еще на Фортране. Периодически натыкаюсь на статьи таких людей (порой весьма именитых), которые продвигают мысль: «Надо просто писать код. Нет там ничего такого, от чего выгореть можно».
Да, олды имеют право на свою точку зрения. Но тут важно спросить – а сейчас они продолжают что-то разрабатывать? И если да, то на чем? Простите, но пример Фортрана или Паскаля прям совсем мимо. Эти языки прожили несколько ревизий и все же их развитие – вопрос десятилетий. Темп современных инструментов им и не снился. Многие олды, при всем моем к ним уважении, точно так же когда-то освоили свой стек и живут в нем годами. В России это не так ощущается, а вот на Западе, где в том же банкинге продолжают трудиться программы на Коболе, там да. Программист давно на пенсии, но продолжает обслуживать код, написанный много лет назад. Не развивается ни язык, ни программист.
Странные люди
Помимо объективной причины техностресса есть причины субъективные. И кроются они в личностях отдельных разработчиков. Я подчеркну – тут грести всех под одну гребенку прям вообще неверно. И все же образ «бородатого и чудаковатого сисадмина» имеет место быть.
В программирование идет много специфичных людей. Интровертов, не самых устойчивых психологически, но имеющих способности и усидчивость. А часто и довольно особенный ход мыслей, который в работе им помогает.
Однако, для таких людей стресс переносится очень и очень тяжело. Специалисты по персоналу не дадут соврать – к айтишникам нужен свой подход. Просто выдать им задание и обозначить сроки — не вариант. Это может сработать на уровне техлида, но когда мы спускаемся ниже, то приходится уже копать индивидуально.
Навсегда запомнил время, когда меня только поставили во главе команды разработчиков. Я буднично раздал им задачи и обозначил сроки. Все профукали. Я начал разборки на тему: «какого хрена???». На следующий день прибежала наш HR с круглыми глазами и стала возить лицом по столу уже меня. «С ума сошел, ты их всех распугаешь, где я новых буду искать???». Я был в замешательстве: «Но что я такого сделал? Они приказов не слушаются. Я че, танцевать перед ними должен???». Ответ был простой: «Танцуй».
И да, я начал танцевать. Искал подход, делал спринты, старался заинтересовать ребят задачей, создавал круговую поруку (профукал сроки – подставил остальных). В то же время вовлекал, чтобы для них это было не просто работой, но личным проектом.
Не буду судить о том насколько успешно у меня получилось, но платформу мы зарелизили в срок.
Возвращаясь к нашей теме. Если бы в айти все было так легко, туда бы шли толпами и там не платили бы столько денег. Но нет, там могут работать не все. А кто могут действительно требуют своего подхода и действительно подвержены выгоранию больше обычных людей.
Ненормированный график и ответственность
Еще одна ключевая причина выгорания. Специфика работы многих айтишников такова, что приходится включаться в процесс в любое время. Тут бывают перегибы со стороны руководителей и объективные причины, когда приложение штормит, а за ним тысячи пользователей. Хочешь-не хочешь, нужно включаться.
За что отвечает наш рабочий на заводе? За свои пальцы, может за здоровье своей бригады. Тоже немало, надо отметить. И все-таки его ошибки не так фатальны. Повторюсь – не всегда. Одним движением руки отдельные индивиды могут обесточить целый завод или город (я писал об этом раньше). И все же, в среднем, уровень ответственности меньше. А у айтишников больше. Это давит. Есть механизмы минимизации рисков. Поставить на всех рубежах QA, быть осторожнее с релизами. Но мы все понимаем – ну случается, блин. Случается. И это часть работы. Специфика, если можно так выразиться.
Среда
Тоже причина, хотя я бы не стал ставить ее на первое место. И все-таки, техлиды и кадры держат в уме, что айтишники могут выгорать. Есть даже специальные должности, специальные люди, которые следят, чтобы персонал чувствовал себя хорошо. Когда все твои коллеги ходят к психоаналитику, а хандра является чем-то обыденным, это дает некую свободу маневра. Вчера захандрил Петя, сегодня Даша, а завтра меня что-то не прет. Увы, не так уж редко выгорание путают с обычной ленью. Повторюсь – это не первоочередная причина, но имеет место быть.
Неумение отдыхать
Культ продуктивности, который пышным цветом цветет в среде IT тоже имеет свои последствия. Вы даже не представляете, сколько людей не могут элементарно отдохнуть. Ибо сениор Женя делает мою недельную работу за два часа. Я должен быть таким же. Отдохнул, значит потерял время! Фигачить, фигачить, хрр… пшшш… фигачить…
Как сказал известный банкир Морган: «Я могу сделать годовой объем работы за девять месяцев, но не за двенадцать». Отдыхать надо уметь. Выключаться из задач и поехать кататься на сноуборде, нюхать фиалки или зазырить новый фильм, о котором столько говорят. Спланированный регулярный отдых – это подпитка сил на текущую работу. Не надо делать ставку на отпуск через три месяца. Подпитывать свои ресурсы надо здесь и сейчас и это постоянный процесс. Следить за тем, чтобы отдых не выходил за рамки – это да. Если вы скроллите рилсы инсты не час, как запланировали, а три, у вас проблема. И все же «рабочие выходные» — это не есть правильно.
Резюмирую. IT – это очень специфичная область. В ней работают специфичные люди со специфичными потребностями и проблемами. И выгорание – вполне себе обычное дело в этой среде. Все мы выгораем. Это надо принять. Убедиться, что не лень. Дать себе отдохнуть. И с новыми силами в проект. Ибо на дохлой кобыле далеко не уедешь.
Комментарии (162)
maluta
29.01.2023 05:16+9В разработке постоянно нужно думать. А когда на пару часов перестаешь и делаешь на автомате, все начинает идти под откос, и тогда эффективнее вообще ничего не делать. (По крайней мере меньше убытков, чем написать Г-код и потом с ним мучиться, пока не выкинешь.) В этом основное отличие работы программиста, от крановщика и других профессий. Крановщик может успешно работать и на автомате, не думая.
Выгорание же начинается тогда, когда нужно работать, когда устал и котелок не варит. Работа через силу, без огонька для программиста подобна смерти.
druidvav
29.01.2023 05:27+7Почему-то сравнивают с крановщиками, а не например с проектировщиками зданий. Там работа очень похожая на программирование и выгорание еще какое.
vkni
29.01.2023 05:51+6Потому что проектировщики стоят сильно дороже работяг, а бизнесу хочется платить меньше. Поэтому он пытается всех надурить, что программисты — это работяги. Ну получается надурить себя.
druidvav
29.01.2023 05:52+1проектировщики сильно дешевле работяг? вы либо описку сделали, либо сомнительное утверждение
koresh_builder
29.01.2023 08:54Для баланса мнений не могу не заметить, что сейчас рабочие на стройке схожего опыта получают столько же, сколько и проектировщики, если не больше. К примеру, инженер-конструктор 1-2 категории и сварщик примерно 3-4 разряда где то 60 т.р
Samedi_Da_Kapa
29.01.2023 08:55+3Вы таки удивитесь, но опытный работяга с документами вполне себе может получать сильно больше проектировщика здания. Я видел разницу в два раза.
Просто потому, что опытный работник с документами на той же стройке это человек настолько редкий, что в городе двухсоттысячнике они расписаны по стройкам на год вперед.
DonAgosto
29.01.2023 09:45+1проектировщики стоят сильно дороже работяг
Как тут уже указывали, это обычно не верно (по крайней мере в провинции в РФ). Дело просто в обычной жадности бизнеса как таковой.
Не знаю ни одного предприятия, на котором не пытались однажды «пересадить ИТР на сделку». Ну это примерно как в IT-конторах пытаются зарплату программиста привязать к количеству закрытых тикетов (коммитов или даже sloc) в месяц.
Interfer Автор
29.01.2023 10:15Кстати, хорошо подметили. Я что-то уперся только в сложность профессии, оставив за рамками сложность задачи.
IronKaput
29.01.2023 13:35+2В этом основное отличие работы программиста, от крановщика и других профессий. Крановщик может успешно работать и на автомате, не думая.
Основное отличие в том, что некоторые программисты считают свою работу "особенной".
Maccimo
29.01.2023 05:52+8Листал я эту воду, листал, всё ждал, когда же автор от воды с двадцатиоднометровыми веками перейдёт к обозначенной теме. Не дождался.
Какие ещё «противоположные мнения» ожидал автор в ответ на свою графоманию? Надеялся, что тут есть оживлённое сообщество крановщиков?druidvav
29.01.2023 05:55+8Я крановщик, но для души, на самом деле я стартапер :)
PowerMetall
29.01.2023 10:54+2А я таксую, но это так, от скуки и для души. Так то у меня собственная мясохладобойня в Самаре ))
Interfer Автор
29.01.2023 10:18+5Скажем так, у меня тоже есть профессиональная деформация. И мне тут правильные мысли стали озвучивать. Про напряженность работы, про другие высококвалифицированные специальности. Повод задуматься.
Не знаю как у вас, а у меня есть проблема. Я живу в своем мирке. И мне бывает сложно посмотреть за его границы. Такие статьи и здоровая критика сильно помогают. Потому я сразу обозначаю цель статьи - подискутировать. Конечно, никто не обязан мне помогать, равно как и читать меня)))
Kudriavyi
29.01.2023 23:20Не стоит писать, что у какого-то рабочего ответственности нуль, а вот у нас, у программистов...! На химкомбинате цена ошибки рабочего может привезти к разрушению цеха, травмам и даже смертям рабочих и загрязнению окружающей среды и близлежащего города. А уровень нагрузки на руководство вам такой даже не снился, когда в четыре утра начальство все поднимают из кроватей по причине остановки цеха.
Я сам занимаюсь схемотехникой, а отец был начальником цеха на химкомбинате. Поэтому я знаю что моя работа разнообразная, творческая и не сложная, а у рабочих бывает нудная, ответственная и тяжёлая.
И про оператора крана не надо грязи. Вы неловким щелчком мыши оставите без интернет сервиса 1000 человек на полчаса, а крановщик неловким движением может оставить пару семей без отцов
Interfer Автор
30.01.2023 00:11Я как раз пишу, что всех под одну гребенку грести нельзя. И привожу ссылку на свою же статью, когда цена ошибки рабочего реально высокая. Да, я знаю, что так бывает. И все же если взять всех работяг на заводе и прикинуть, сколько из них реально отвечают за кого-то кроме своей бригады - не так уж и много наберется. Понятно, всегда можно придумать ситуацию: "А если он споткнется об этот шланг, весь завод полыхнет". Но я про прямые обязанности.
С бытом заводов я знаком очень хорошо, поверьте)
Но давайте не будем недооценивать айтишников. Они не только в провайдерах работают. И они, в том числе, поддерживают критическую инфраструктуру. Да, если ролик на порнохабе час времени будет недоступен, беды не случится. Но софт сейчас управляет фактически всем. И цены ошибки айтишников тоже бывают немаленькие. Я всегда привожу пример, как неудачно с Восточного взлетела ракета, думая, что она взлетает с Байконура. Бывает. А кто в ракете? А куда она упадет?
WerkEng
30.01.2023 14:06"Но давайте не будем недооценивать айтишников". Вы их, по-моему, переоцениваете. Описываете, как какую-то особую касту, "специфичные люди со специфичными потребностями и проблемами". Как-будто у других людей таких потребностей и проблем нет. А вот эта история, где они "все профукали", а потом, как я понял, пошли к эйчару жаловаться, мол, "начальник работать заставляет, не танцует, повозите его лицом об стол, а то разбежимся" - это вообще. :/ Спасибо, что тут же не "выгорели". Странные работники. Насколько я знаком с людьми из IT - это нормальные люди, работают, напрягаются, бывают проблемы. Как у большинства людей, которые работают.
Interfer Автор
31.01.2023 15:59+1Да, я считаю айтишников специфичными людьми со специфичными проблемами.
Равно как и врачей считаю специфичными людьми со специфичными проблемами.
Практически в любой профессии есть своя специфика. Но вот момент. Рабочих много. Водил много. Они своей массой формируют некое среднее отношение к работе в обществе. И они своей массой создают ... как назвать... ну повестку проблем что ли. То есть за счет их массы в обществе их проблемы в том же обществе поняты, равно как и их потребности.
А вот айтишников или, скажем, библиотекарей резко меньше. И их проблемы хорошо так отличаются, а за счет их немногочисленности обществу могут быть непонятны.
Работают, напрягаются, бывают проблемы - это слишком общее определение. Всю мою статью можно свести к тому, что у людей бывают проблемы и задача руководителя об этом не забывать. Но мы же копаем глубже.
Не знаю, с кем именно вы знакомы и насколько глубоко. Но работа накладывает свой отпечаток и у разных сфер проблемы реально разные.
vkni
29.01.2023 05:59+17Навсегда запомнил время, когда меня только поставили во главе команды
разработчиков. Я буднично раздал им задачи и обозначил сроки. Все
профукали.Ну это замечательно: пришёл кадр управлять, ничего не зная про специфику управляемой области. Вот это, собственно, и есть основная мировая проблема нашего времени.
Если бы вы хоть что-то почитали про програзм (Брукса, Ди Марко), вы бы узнали, что это высокорисковая область, где сроки имеют распределение с длинными хвостами. Соответственно, 99% срок можно дать только после того, как работа будет сделана. А до этого ошибка примерно раза в 3 в обе стороны.
N-Cube
29.01.2023 10:12+1Это только если на написание кода закладывать 80% времени. А если на код 20%, а остальное это тестирование, документация и так далее - то даже при увеличении времени на кодирование втрое вполне можно уложиться в те же сроки. Раз уж тут проектировщиков вспомнили, так у них как раз планируется время на многоэтапное согласование, получение разрешительной документации, подключение к коммунальным сетям (вода, канализация, газ, электричество,…) и много всего еще, время на «укладку кирпичей» это лишь один из этапов проекта.
vkni
29.01.2023 15:14-1А никто на написание кода не закладывает 80% времени. Набор код занимает буквально десяток минут, как правило.
N-Cube
29.01.2023 18:43Тогда главное отличие с архитекторами в том, что они заранее оценивают реализуемость проекта - например, не делают парящий фундамент... а в программном проекте еще и не такое встречается :)
vkni
29.01.2023 18:53В программном проекте тоже заранее оценивают.
N-Cube
29.01.2023 20:00Если вы все заранее оцениваете, откуда у вас ошибка по срокам в 3 раза?
dkuzminov
29.01.2023 20:11+2Реализуемость и сроки -- это принципиально разные вещи. Вопрос реализуемости стоит в исследовательских задачах (и, кстати, в исследованиях негативный ответ типа "метод не работает, спасибо, все расходимся" принимается как велидный и в какой-то мере успешный исход). Вопрос сроков -- это уже инженерия. И я призываю отделять одно от другого, иначи и одно не до конца выяснено, и другое криво реализовано.
N-Cube
29.01.2023 20:28+1Так все же почему у вас в реализуемых проектах ошибка по срокам в три раза? Одно дело, когда заранее не известна реализуемость этапов - доказать невозможность реализации может требовать сколько угодно времени, но если все этапы реализуемы, тогда и путь реализации заранее известен, следовательно, и время на реализацию поддается оценке. Тем более, если, как вы пишите, время реализации на многократно превышает время написания кода, так что даже ошибка в разы по срокам написания кода ни на что не влияет. Получается, дело вовсе не в программировании, а проблема вообще с проектом как таковым.
thevlad
29.01.2023 21:03Вы пишите так как будто на этапе планирования вы уже знаете все конкретные алгоритмы и архитектуру. В реальности это возможно если только вы делали очень похожий проект, и новый имеет минимальную новизну. Если так то можно считать, что у вас уже есть рабочий код, который надо немного допилить и можно расходится.
Фундаментальная проблема в том, что "гладко было на бумаге но забыли про овраги". Предпосылки рушатся, алгоритмы взрываются от того что данных встало в 10 раз больше, архитектура не продумана и начинает буквально "сыпаться", ТЗ содержит ошибки и т.д.
N-Cube
30.01.2023 08:01+1архитектура не продумана
О том и речь, проблема с проектом. Архитектура программного проекта это как каркас здания, а программирование - отделка (в строительстве все аналогии найдутся, область буквально древняя). Конечно, когда на этапе отделки оказывается, что нет воды, света, канализации, связи и обогрева - даже отделку выполнить проблематично, не то что использовать помещения по назначению. Кодом проблемы проекта как такового не компенсировать.
thevlad
30.01.2023 12:57Хорошие архитектуры "не приходят из космоса", это дитя опыта в конкретной предметной области, часто с первого раза не удачного.
N-Cube
30.01.2023 13:13Зачем беретесь, если заведомо знаете, что не можете выполнить проект? Сделайте внутренний или открытый проект, научитесь, а потом уже предлагайте сторонним заказчикам.
thevlad
30.01.2023 13:19Это все просто крайние точки, реальный ландшафт сложнее. Гарантировать можно, если вы до этого делали практически тоже самое. И это если мы рассматриваем вопрос чисто с инженерной точки зрения. С точки зрения бизнеса, вы вполне можете понимать, что будет 3х, но обозначать 1х. В том числе из-за не совсем честных конкурентов.
dkuzminov
29.01.2023 21:36Я это объясняю с помощью Cynefin Framework https://en.wikipedia.org/wiki/Cynefin_framework, где проблемы разделяются на простые, усложненные, сложные и хаос. Простые полностью поддаются оценке сроков выполнения. Усложненные (complicated) не поддаются оценке сроков, но дают очевидный ответ на вопрос "реализуема ли задача при наличии неограниченных сроков и ресурсов". Complex не дает представления даже о том, может ли быть задача решена в принципе: требуются сложные эксперименты, чтобы дать ответ.
Отвечая на ваш вопрос: описанная вам задача явно complicated, и решающему ее не удалось адекватно разбить ее на простые.
N-Cube
30.01.2023 08:06+1решающему ее не удалось адекватно разбить ее на простые
Так и я о том - эта проблема началась гораздо раньше этапа программирования, еще ни строчки кода не было, а проблема была, и можно было уже по плану работ увидеть, что проект обречен. Аналогичное происходит порой и со строительными проектами, к примеру, так что ИТ специфики тут нет.
vkni
30.01.2023 00:26Оценка на то и оценка, чтобы быть приблизительной. Ну вот здесь такая точность обычна. Более точная оценка потребует много времени, поэтому нецелесообразно. Но в принципе можно давать и 100% точную оценку, когда работа уже сделана.
Wesha
29.01.2023 22:20Набор код занимает буквально десяток минут, как правило.
Программист, который "набирает код за буквально десяток минут" — это примерно как та машинистка, которая "печатает 2000 знаков в минуту — правда, такая фигня получается!"
vkni
30.01.2023 00:24Я обладаю навыками слепой печати, поэтому если код написан на бумажке (мной же), набор составляет ничтожное время.
Wesha
30.01.2023 02:58Я не про набор. Я про то, что когда "пишешь быстро", не хватает времени подумать про всякие мелочи. Ну, типа дыры в безопасности, которую новый код может создать.
Interfer Автор
29.01.2023 10:27+1Представляете, так бывает. Я согласен с тем, что это неправильно. И клеймить меня каленым железом, ведь в жизни все должно происходить только правильно, верно?)))
Однако, многие команды рождаются, в силу внешних обстоятельств, на пустом месте. И у них есть два варианта - самим пройти путь и вырасти, либо загнуться. Ну либо пригласить внешнего консультанта (благо их полно) и понадеяться, что он все сделает как надо)
Да, у нас становление разработки и становление тим и техлидства прошло свой путь. Тернистый и с ошибками. Сейчас такая ситуация в компании уже уму не постижима. И все же так было. Мы учились, приглашали правильных (и не очень) людей, общались с коллегами, ездили по конфам, учились. И, знаете, вот мне не стыдно, что мы смогли вырасти, начиная оттуда, откуда начали. Ибо сразу готовые слаженные команды с клевым лидом из печки не пекутся.
Что же до сроков. Увы, сложная задача и правда сложна еще и тем, что в ней трудно адекватно рассчитать сроки. Только бизнесу каким-то образом сроки все же нужны. Ибо ему надо посчитать издержки. Это вечная проблема, она не только в ИТ-сфере. Такая битва льда и пламени)
vkni
29.01.2023 15:10+1Представляете, так бывает. Я согласен с тем, что это неправильно. И клеймить меня каленым железом, ведь в жизни все должно происходить только правильно, верно?)))
Это просто всеобщая беда нынешнего времени: деградация управления.
Увы, сложная задача и правда сложна еще и тем, что в ней трудно адекватно рассчитать сроки.
Оно не сложное, оно высокорисковое. В смысле, у вас всё просто, перекладывание JSON'ов, никаких мегаалгоритмов и т.д., просто внезапно выясняется, что нужно дописать там, там и там куски, здесь что-то сломалось и т.д. Поскольку программа — это просто максимально проработанное Т.З., предусмотреть на этапе постановки задачи (создания Т.З. на программу) эти вещи вы можете только с некоторой, далеко не 100%, вероятностью.
butsan
29.01.2023 18:54+1К нам, однажды, на работе пришел управлять вояка.. На работе у нас началась армия =)
Red_Nose
29.01.2023 23:32+1Зачем так умнО ? :) " почитали про програзм (Брукса, Ди Марко), вы бы узнали, что это высокорисковая область " - ведь можно "потанцевать" :)
Мальчика "поставили", он "буднично раздал" и так же "буднично получил реакцию". А еще там у него HR-ша с правами CIO присутствует - изюминка :)
vkni
30.01.2023 00:28Она лирического героя истории, скорее, просто спасла, подав идею, что он делает что-то не то. Ну, типа, если вы видите, что все вокруг едут по встречке, это некоторый повод задуматься.
stackjava
29.01.2023 08:33+2Дать себе отдохнуть. И с новыми силами в проект. Ибо на дохлой кобыле далеко не уедешь.
Последнее предложение столь же логично, сколько и ценнично...
Звучит как то: Эгегей, мустанги вы мои, не выгорайте, отдохнем и снова в путь!
Шопотом: А то если вы копыта откините, кто ж меня дотянет до места назначения.
Но статья интересная)
Interfer Автор
29.01.2023 10:30Спасибо) Некоторые истины просты до безобразия, но их нужно постичь. И работа - это вообще циничная история. Мы приходим и вкладываем свой труд, чтобы собственник получил прибыль. Вопрос лишь в том, как сделать нашу циничную историю комфортной и выгодной для обеих сторон. Рынок - он такой.
Про отдых - это отдельная большая тема. Я не стал ее тут разбирать, возможно стоит. Но многие люди в нашей стране правда не приучены отдыхать...
justPersonage
29.01.2023 09:53+1Сейчас трудно освоить какую-то область, чтобы потом этим кормиться хотя бы лет десять. Сужу по своему увлечению 3D-моделированием.
Ну есть же в ИТ сфере более стабильные отрасли.
Где технологии меняются медленно.
Например
1)Админить — Сети
2)Физика — Микроэлектроника( Схемотехник,Embedded...).
3)Математика — Data(Scientist, Analyst, Engineer ), Возможно MLInterfer Автор
29.01.2023 10:34+5Про сети однозначно не соглашусь. Сетевик сейчас и 15 лет назад - это две большие разницы.
Тут уже теплее. Я не схемотехник, потому спорить не стану. Хотя пример того же wi-fi6 хорошо показывает, как из эфира сегодня могут выжать то, что еще десять лет назад казалось фантастикой. И многое там завязано на новые разработки в области антенн, плюс математика кодирования сигнала.
А вот ML - одна из самых динамичных областей. Это видно даже по уровню нейросетей, которые сейчас творят научные чудеса.
CrzyDocTI
30.01.2023 01:39т.е. там за последние 60 лет придумали что-то кроме numpy(или его более молодых аналогов)? ну действительно же - мало что меняется в ML, просто то что было начали использовать в разных отраслях.
в 1 и 2 для большинства работников области действительно мало что меняется - потому что они никогда этих технологий в живую и не пощупают в виду малораспространнености дорогих железок и вакантных мест на необходимые навыки
justPersonage
30.01.2023 10:46Про сети однозначно не соглашусь. Сетевик сейчас и 15 лет назад — это две большие разницы.
15 лет?
В любой сфере (не только ИТ) за 15 лет много что изменилось.
5 лет. Обычно смотрят.
Во многих вакансиях сетевика требуется почти тоже самое что и 5 лет назад.
С разработкой такой номер не прокатит.
Сетевик:
1)Знание стеков протоколов ТСР/IP
2)Задачи с коммутаторами D-Link и Huawei Cisco
3)модели OSI, принципов IP коммутации и маршрутизации
4)Знание построения VPN соединений.
5)Иметь представление о межсетевых экранах
6)Знание технологии SD WAN
Что изменилось из этого за 5 лет?Тут уже теплее. Я не схемотехник, потому спорить не стану.
А что тут спорить?
Физика. Математика.
Эти 2 предмета меняются медленее чем Dev индустрия.А вот ML — одна из самых динамичных областей. Это видно даже по уровню нейросетей, которые сейчас творят научные чудеса.
Требования в вакансиях:
1)Знание математической статистики, теории вероятностей, основ математического анализа и векторной алгебры;
2)Знание одного из языков программирования– R, Python, SAS Base;
3)Знание SQL;
4)Знание основных моделей машинного обучения (для прогнозирования, классификации, кластеризации).
Ну и что тут быстро меняется?
Статистика?
R? SQL?
основные модели ML?
ML отрасль меняется медленее чем Dev индустрия.
Так а что насчет Data(Scientist, Analyst, Engineer )?
Типичная вакансия Data Engineer
1)Опыт разработки оптимальных пайплайнов и оптимизации SQL-запросов;
2)RDBMS / MPP;
3)Python/Java;
4)ETL (AirFlow).
5)AWS(S3....)
6)PostgreSQL, ClickHouse (опционально);
7)BI-инструментами (TABLEAU/Looker/Mode) (опционально).
Даже Data Engineer профессия меняется медленнее(или чуть медленнее) чем разработка.Interfer Автор
31.01.2023 16:13+1Отвечу за ту область, в которой понимаю. Радио.
Что принципиально изменилось в Радио за последние 15 лет? Революционные открытия? Инновационные материалы антенн? Может физика поменялась? Нет, ничего этого не было. Но почему сейчас спецы по радиосвязи другие?
Математика. Мы давно умеем кодировать сигналы. И можем делать это по очень сложным алгоритмам. Раньше подобные вычисления требовали серьезной техники. Но сейчас уровень микропроцессоров разогнался так, что любой роутер умнее многих компов пятнадцать лет назад. Он может позволить себе сложную математику на борту. И разработчикам приходится ее учить. Сама математика была, просто раньше потребности в ней не было.
Элементная база. Когда-то позволить себе сложные микропроцессоры или антенны могли единичные дорогущие гаджеты. Сейчас тот же роутер умеет beamforming. Технология не нова, но пока в связи использовали омни, да направленные антенны спецов по ней шибко и не было. Сейчас они нужны.
Смежные области. Если мы говорим про вай-фай или сотовую связь, то нормальный специалист должен хоть что-то понимать в проводных сетях. Когда я только начинал работу в СС в далеком 2006м, я понятия не имел что такое vlan. Ибо этим занимался наш сетевик и все БС жили, по сути, в локальной сети коммутатора. Когда к каждой БС подходит своя оптика или релейка у которой второй конец упирается в коммутатор, жизнь хороша. Но когда между коммутатором и БС может оказаться черти-че, вы должны осознавать как это черти-че работает.
-
Но! Раньше базовая станция - это шкаф с оборудованием. Он стоит на земле, антенны сверху. Надо уметь дотянуть до нее кабель, разделать разъемы, нигде не накосячить, проверить КСВ. Сейчас это отходит в прошлое. БС имеет внешний юнит, который крепится прямо за антенной. Соединение с антенной - заводским кабелем-джампером. Сигнал наверх по оптике. Умение разделать кабель стало не так критично (хотя навык полезный).
Вот и получается. Физика не поменялась. Фундаментальных открытий не сделано. А профессия изменилась.
iggr63
29.01.2023 23:2235 лет работаю в одной области и по специальности. Правда проработал в трех исследовательских лабораториях и одной фирме. При этом специальность — радиофизика. Звучит совсем не современно. Однако работа есть везде.
Interfer Автор
30.01.2023 00:16Радио - отличный пример. Да, есть сферы, где ничего не меняется десятилетиями. Но тот же wi-fi6 показывает, что технологии прут вперед. И если раньше упихнуть в эфир гигабиты казалось невозможным, то сейчас запросто)
victor_1212
29.01.2023 10:09+2> И выгорание – вполне себе обычное дело в этой среде. Все мы выгораем. Это надо принять.
нет не надо, выгорание часто бывает просто от нарушения баланса положительных и отрицательных эмоций получаемых от работы, если заставить хорошую лошадь ходить на привязи по кругу, типа как было на шахте, то долго не протянет даже при хорошем корме, если проект не интересен или вообще работа плохо организована, отдых мало что изменит, современное программирование становится все более промышленным, меньше собственного кода, больше интеграции, porting, и т.п., к сожалению это изменить невозможно, интересных самостоятельных проектов становится меньше,
вывод простой - либо надо все больше усилий для нахождения проектов которые Вам интересны, либо вообще уходить в новые области типа bioinformatics и пр., принятие выгорания как нормы, и продажа собственных мозгов даже за хорошие деньги себя не оправдывает
ruomserg
29.01.2023 10:41+30Значит, давайте так! С моей точки зрения — в статье все смешано в кучу: усталость, монотонность, выгорание, и в таком духе. И вообще, почему-то выгорание стало модным словом, и им называют все подряд негативное связанное с работой.
Какое-то время назад — тут давали очень хорошее и конструктивное определение выгорания: истощение ресурсов психики, возникающее вследствие эмоциональной привязанности человека к своей (сложной, не гарантирующей результат) деятельности и хронического нарушения баланса работа/отдых.
Из этого определения следуют два очень важных вывода. Во-первых, вы не сможете выгореть если будете копать землю лопатой. Потому что в какой-то момент вы физически устанете, у вас будет все болеть — и на лопату без отвращения смотреть не сможете, а пойдете отдыхать от этой работы. Аналогично и все другие рабочие специальности — устать вы там можете, травму можете получить, а выгореть — не получится. Потому что нет эмоционального компонента. И возможности работать за пределами смены тоже обычно нет.
Второй вывод — выгорание бывает не только у программистов. Также со свистом горят врачи, горят учителя, горят творческие работники. Потому что есть эмоциональный компонент (спасать людей, учить людей, заниматься творчеством — это мощнейшие эмоциональные стимулы), есть элемент неподконтрольной неопределенности (люди несмотря на лечение умирают, ученики не учатся, книги не пишутся), и нет предохранителя в виде физической усталости. Вам должно стать уже совсем-совсем худо, чтобы вы не смогли выписать рецепт, заполнить классный журнал или нажать кнопки на компьютере.
А дальше начинается вот такая штопорная спираль: не получается — работаем больше — устаем (эффективность падает) — ощущаем чувство вины перед собой/работой/людьми — работаем больше — устаем больше — еще больше работаем — и так пока организм не начнет отказывать.
Теперь о том, как с этим бороться. Устранить эмоциональный компонент — не получится. Устранить случайность и неопределенность в результате — тоже не получится. Остается только одно — знать причины выгорания, уметь заниматься само- и взаимодиагностикой. А руководителям — не радоваться что программисты сидят допоздна, а организовывать нормальный режим труда и отдыха (хотя это абсолютно противоречит идеям «эффективного менеджмента»). С другой стороны, надо понимать что определенным видам бизнеса выгоднее выжечь разработчиков в обмен на продукт сейчас, а что будет завтра — их не волнует. Бегите оттуда… Бегите…Interfer Автор
29.01.2023 10:49+2Хороший комментарий, плюсую.
Добавлю только один момент. Часто сотрудники от руководителя ждут какой-то заботы, защиты, понимания. Честно скажу - мне это понятно. Я в своей работе всегда старался создать подчиненным комфортные условия и все общение с руководством выше пропускать через себя. Если где-то кто-то накосячил, не должны бигбоссы обычного программера по столу мордой возить. Меня должны, а я дальше сам оргмероприятия проведу. Это правильно как с точки зрения бигбоссов (одна точка входа и один ответственный), так и с точки зрения сотрудника.
И все же работая по найму надо держать в голове, что вы приносите пользу, обменивате свой труд на деньги. Это не междусобойчик и дружба, это сделка. Потому надо внимательно условия сделки смотреть.
Действительно, сделка может быть весьма суровой. Тут глупо жаловаться. Если не получается условия сделки сместить в свою пользу - штош... Либо принимать, либо уходить.
Но по моим наблюдениям, команды, где все как-то по-человечески добиваются куда большего успеха, чем "конвейер из людей".
ruomserg
29.01.2023 10:56Совершенно согласен. Если на уже имеющуюся эмоциональную нагрузку от работы добавить еще негатива от биг-боссов, процесс экспоненциально ускоряется.
И да, стабильная команда — работающая в нормальном режиме на долгом промежутке времени всегда даст больше годного. Но это же надо уметь вдолгую играть, чем бизнес (впрочем, он — скорее отражение политики в этом вопросе) редко занимается. В условиях неопределенности, ему проще зарезать корову и продать мясо, чем кормить, поить, убирать и доить несколько лет в будущем…Interfer Автор
29.01.2023 11:04Стратегия вин-вин эффективна именно вдолгую. Вопрос тут скорее формулируется так. Бигбосс, к которому вы идете работать строит что-то большое и глобальное? Он понимает, где хотел бы оказаться лет через пять-десять? Или у него изначально задача срубить бабла и свалить?
Обе стратегии имеют место быть. Просто во втором случае не стоит мысленно связывать себя с этой компанией на годы. А если для вас важно работать долго на одном месте - идти к тем, кто играет вдолгую.
Но тут важный момент. В больших серьезных компаниях и время течет чуть медленнее. Там все не быстро - рост, развитие, повышение зп. Ибо стабильность не любит резких движений. При прочих равных там дольше делать карьеру.
Впрочем, из любого правила бывают исключения.
twid
29.01.2023 10:57"Потому что нет эмоционального компонента."
Есть. Может это личное, но есть. Закладывающий уши ор оглашенного "Я работаю. Я такой невероятный труженник. Я такая звезда. 24\7 работаю."
Ты ж не один на работе, с лопатой или клавиатурой.
bkar
29.01.2023 21:01С лопатой тоже можно выгореть на раз-два. Болезнь уже давно описана - золотая лихорадка. И, лихорадка, если кто не задумывался, это как раз высокая температура, когда организм сам себя заживо сжигает.
Конечно, золотоискатель это особый случай, в чем-то ближе к работе програмиста, чем "полтора землекопа роют полтора метра траншеи за полтора часа". Даром, что мыть золото лет двести назад можно было не зная ни одной буквы.
otchgol
29.01.2023 10:53+1Мне гораздо интереснее читать про решение физиологических проблем: спины, шеи, запястья. Но охотно верю, что кому-то хочется найти единомышленников в нудности. Я встречал людей, которым действительно в радость писать под копирку (это на олдовском), и им, возможно, учить все это новое очень выгорательно. Мне кажется, что это обычное желание человека пожалеть себя. Не деньги, так скука, а нет - болячки или комфорт. Человек, который успокоился не станет работать. Не отрицаю выгорания, просто мне кажется оно лечится кончившимися деньгами. Или стартапом..
Interfer Автор
29.01.2023 10:58Ооооо, нет!) Я уже понял, что нужна статья по мотивации персонала и сделаю ее в ближайшее время. Если коротко суть - у каждого человека есть своя ведущая мотивация. И это далеко не всегда деньги. Деньги тоже важны, хотя клинические примеры, когда гениальный программист трудится над интересной задачей за гроши тоже встречаются.
И все-таки не все решается именно деньгами. Определить ведущую мотивацию сотрудника - важнейшая задача руководителя. Ибо без этого можно его кормить огромными зарплатами и удивляться - а че глаза-то не горят???)
otchgol
29.01.2023 18:37Я не видел гениев за гроши. Нужно быть очень глупым, чтобы не платить достойных денег таланту. Но это отдельная тема. Я не про достойную оплату совсем. Я про желание работать (горящие глаза в аджайле - нонсенс, в который я не верю). Нет ничего проще, чем оставить работу на месяц-год-пять, на сколько позволят накопления, которые часто есть у тружеников табуретки и клавиатуры, и желание писать какой-угодно тупой код вернется. Просто осознание разницы вернет желание.
victor_1212
29.01.2023 21:31> Определить ведущую мотивацию сотрудника - важнейшая задача руководителя.
Олег, Вы не переоцениваете свои силы?
Для этого надо min понимать людей, что не просто, если напишете статью по предмету, конечно будет интересно.
Из личного опыта, который у всех разный - по серьезному единственное чем можно мотивировать своих сотрудников в трудных ситуациях это личным примером, это после 50+ лет в программировании, в том числе работы с сильными командами
Interfer Автор
31.01.2023 16:20А кто ж меня знает?) В душе я для себя самый лучший и умный) Но по факту я понимаю, что это не так. Вот, статьи пишу, стараюсь критику поймать, вещи, которые задуматься заставят)
Минимально понимать людей можно и нужно. И даже этого минимума я много где не вижу. Хороший руководитель - это еще и психолог.
Насчет личного примера - он важен. Конечно, сотрудники должны уважать своего руководителя. Он должен быть не нахлебником, а лидером. И все же горящий Данко, вынувший из груди сердце, сможет мотивировать лишь отдельных людей. Остальным нужны иные персонажи)
Стать идеалом для всех невозможно. Отсюда вывод. Вдохновлять всех личным примером, набрав команду тех, кого ваш пример вдохновляет. Либо искать ключики, разные ключики)
victor_1212
31.01.2023 19:13проекты разные бывают, организации тоже отличаются сильно, соответственно требования к командам, бывает что членов семьи не совсем понимаешь, про мотивацию сотрудников это сложнее, по серьезному от адекватного руководителя требуются качества типа wolf pack alpha, в том числе никогда не обманывать своих сотрудников, что иногда бывает сложно, т.к. знаешь больше
ps
если что пишите в личку, занимался в основном сетями и real time
Krasnoarmeec
29.01.2023 11:17+4Статья вредная, но автор пишет на столько хорошо и убедительно, что заслуживает плюса.
Во-первых, «зелёный змий» ни разу не спасает. Да, «выпил с утра – весь день свободен», но это только перекладывает задачи на завтра.
Во-вторых, разработчику не дают погрузиться в задачу. Пример: только погрузился, разогнался, как звонок – исправь в коде трёхлетней давности то-то и то-то. Это как если бы условного крановщика попросили бы: «Вась, слезай с крана и дуй в корпус Б – теперь ты сварщик». Смешно? А в IT такое каждый день по нескольку раз.
В-третьих, господство Agile приводит к тому, что ТЗ меняется каждый день и изменения ТЗ нигде не фиксируются. Пример: типичный звонок начальства:
А это что за х..ня?
Так Вы же сами об этой фиче месяц назад просили!
Нет! Не! Просил! Переделать!
(месяц спустя, тот же начальник)
А та фича, о которой мы говорили два месяца назад, почему не реализована???
… (разработчик ищет на полу свою челюсть)
Вот из всего этого и вытекает выгорание.
Ох, чует моё сердце, сейчас отхвачу минусов по самое нехочу, но это моё мнение и от него не отступлюсь.
Interfer Автор
29.01.2023 12:15+1Да, многозадачность - серьезный угнетающий фактор. Я его в явном виде не учел.
Насчет алкоголя - я не про "утром выпил". Все же народ у нас синярит не настолько отбито. Но пятничный забух с переходом на выходные - обычное дело. И я не говорю, что это нормальный и адекватный способ. Но им пользуются.
Что же касается меняющихся задач - это вообще бич. Тоже помню, как с командой сидели и вспоминали, зачем мы тут галку сделали))) Решается документированием задач. Да, это бюрократия, но без нее никуда.
zlat_zlat
29.01.2023 12:50+4На самом деле, если к этому относиться как "ТЗ крутится, зарплата капает" - то можно выгорать меньше, чем если болеть душой за каждый проект. Но надо делать это умеючи, иначе вас спалят, что вы не из "компания семья, вовлечённость наше всё" и выгонят раньше, чем доездят выгоревших.
Но да, для этого надо довольно хорошо самому выстраивать баланс "работа-жизнь". Работодатель (особенно на просторах СНГ) за вас это делать не будет, скорее всего.
Maccimo
29.01.2023 16:38+3типичный звонок начальства
Есть проблема — создавайте тикет в багтрекере, нет тикета — идите в баню, начальник. А телефон сломался и нового на складе нет.
Koval97
30.01.2023 00:21+2Справедливости ради, я инженером в конструкторском отделе тоже испытывал каждый день. Но поправляло, что когда ты занят конкретным делом, то ты просто говоришь всем "Я сейчас занят такой-то деталью в такой-то сборке. Как освобожусь - посмотрю." и тебя никто не смеет одёрнуть. Ни один начальник не решился настаивать до последнего, даже если работа срочная.
И тут тоже приходится доделывать работу за других. Часто это требует практически переделывать работу за другого, но вынужден вручную исправлять косяки. А когда на испытательном тебя садили за чужой компьютер, и каждого она настроена под себя, то это превращается в незабываемый опыт, где такие миграции чуть ли не каждые 2 дня. Позже уже по опыту понял, что проще приобрести внешний SSD, настроить на нём ОС и софт под себя, и работать только с него, вне зависимости с какой машины ты запущен - тем более SSD большого объема нынче стоят не так дорого, как раньше.
Просто крановщик, как и водитель, оператор ЧПУ, токарь, слесарь, моляр, и прочие спецы видят результат своей работы в процессе прямо перед собой и их никто не пытается держать в невиденье. В IT (я работал программистом, знаю какого это) и часто у автоматчиков (АСУ ТП, тоже там работал, почерпнул проект, над которым сейчас работаю) такое случается с регулярностью.
Есть золотое правило: "На каждого программиста должно приходится не менее 2 тестировщиков", но кто же в наше время в контрактных конторах будет уделять внимание тестированию вообще? Вот и получается, что людям помимо того, что работать приходится с "чужими заслугами", так ещё делать фактически двойную работу. А когда тебя ещё дёргают внерабочее время, и никто тебе за такие "визиты" не платит, то тут ни то что выгоришь, а уйдёшь к первому встречному, лишь бы оставил в покое.
randomsimplenumber
30.01.2023 10:50Переделать!
Штош, бизнес - требования иногда меняются. Завели таску в трекере, объединили с предыдущей. В предыдущей таске зафиксирован хеш коммита, которым запилили изменение? Сделали, не думая, revert, пошли пить смузи.
sonepotam
29.01.2023 11:29+3Все верно написано. У меня было несколько раз выгорание
От перенапряжения. В огромном проекте по миграции на новый карточный процессинг забыли небольшую деталь: собственно программу миграции. Я работал несколько месяцев в режиме нонстоп и получил премию в 500 баксов. От этого выгорания отходил лет 5. Прошло само но не конца.
-
От несовпадения ожидания и реальности. Мне нравится руководить разработчиками а пришлось заниматься совсем другими более абстрактными делами.
На все это накладывается неумение отдыхать и недостаток времени на отдых. Я понимаю, что просто пешая прогулка километров на 5 поможет восстановить силы, но не могу заставить себя, а отдых на диване никак не помогает.
Для борьбы использую следующую тактику: начинаю делать не те дела, которые нужно, а то что мне нравится делать, после того как разработаюсь, переключаюсь на нужные дела.
victor_1212
29.01.2023 17:37> Для борьбы использую следующую тактику: начинаю делать не те дела, которые нужно, а то что мне нравится делать, после того как разработаюсь, переключаюсь на нужные дела.
т.е. работа на адреналине взятом взаймы у более интересного проекта, как и любой самообман долго не работает, типа вообще интерес пройдет, творческие способности надо растить, а не тратить на лабуду, хотя дело глубоко личное разумеется
mirwide
29.01.2023 11:58+3Модное слово, мне кажется его используют слишком часто и не по назначению. Слишком часто что бы обращать на это внимание. Особенно странно бывает слышать про выгорание от людей работающих пару лет в профессии, это не выгорание - лень, завышенные ожидания, стандартные проблемы новичка, после малых успехов видеть себя архитектором через год и потом "выгореть" когда станет понятен масштаб.
Мне больше нравится слово "усталость". Устают в ИТ от разного, чаще, мне кажется от обычных человеческих взаимоотношений чем от необходимости постоянного обучения или решать сложные задачи.
Хороший пример про Юлю в отпуске. Очень важно отдыхать: вечером после работы, в выходные, не забывать про отпуска. Да, можно поработать и 16 часов в день, и без выходных, и подключиться с пляжа поднимать продакшн. Но это должно быть исключением, а не правилом. Иначе ни кому не хватит сил и он устанет. Устанет, даже если делает любимое дело для души. Когда все вокруг привыкнут и решат что это норма и они такие крутые менеджеры. Знаю это, как тот самый человек, который заражает коллег мотивацией работать и который уже уходил в отпуск на полгода.
Interfer Автор
29.01.2023 12:12А вот про новичков с завышенными ожиданиями очень интересная мысль. Я ее обдумаю, спасибо вам)
mirwide
29.01.2023 20:49Новички и завышенные ожидания две разных причины, беда с пунктуацией просто. Первые переоценивают свои возможности пока не видят всей картины, а вторые уже понимают, но надеются на чудо.
kazimir17
29.01.2023 12:01+2На мой взгляд главная причина выгорания в отсутствии результатов реальных работы или же ощущаемое несоответствие вложенных усилий и результатов, для человека важно ощущать такой баланс, вероятно это какая-то очень древняя эволюционно обусловленная потребность. Например я 3 года работал на проекте, а потом его признали неудачным и закрыли, потом еще 2 года работал на отличном проекте с отличной командой, но деньги кончились и проект закрыли.
Interfer Автор
29.01.2023 12:11Как и у любой комплексной проблемы причины тоже комплексные. Горят даже на успешных проектах с хорошими деньгами и мотивацией. Встречал я таких людей. Все прет, а глаза потухшие.
Но если усилий много, а на выходе пшик - это демотивирует, спорить глупо.
Metotron0
29.01.2023 16:24У всех по-разному. Я могу работать на каком угодно проекте, если за это платят деньги. Что с ним дальше будет — проблема уже не моя, а менеджеров. Мне на поесть хватило, квартплату заплатил — ну и ок. Вернее, хотелось бы побольше, конечно, чтобы я струны на гитаре менял хотя бы раз в квартал, ну уж, как есть — и то хорошо. Опять работу менять — это опять стресс, опять поход по врачам, опять нужно через силу засесть за учебники.
Maccimo
29.01.2023 16:56хотелось бы побольше, конечно, чтобы я струны на гитаре менял хотя бы раз в квартал
Судя по https://www.muztorg.ru/category/struny новый комплект струн это максимум один поход в кабак. У вас всё настолько плохо?
Metotron0
30.01.2023 03:03От месяца к месяцу по-разному. На повремёнке сижу. Чуть расслабился или задач не поставили — уже надо внимательно следить за расходами. С весны накоплений не откладывал, всё только в минус получается, ещё и продукты подорожали. А в кабаки я не хожу, давно уж бросил это занятие. Со струнами, конечно, несколько преувеличил, я их не меняю, потому что устраивают, но если бы я готов был не считая потратить 500 рублей, то может и поменял бы по прихоти. А вот купить прикольный ремень для гитары за 1000 — это мне пока перебор, потому что ради прикола тысячу выкладывать не хочу. И то же с симпатичным чёрным выключателем для света за 1200. Есть же работающий, чего его менять-то.
Речь-то изначально про то, что важен результат. Для меня результат — это зарплата. Я не Стив Джобс, новые устройства не изобретаю, я сайтики клепаю, в них обычно ничего нового не придумывают, только по-разному компонуют уже имеющееся. Может, я уже в выгорании, просто не заметил? Год назад я из полугодового отпуска вышел, в который уходил, потому что работа совсем задолбала и здоровье пошатнулось. Но вроде ж отдохнул. Правда, если б не наш президент, я бы отдохнул подольше, почитал бы учебники. А сейчас вообще нет сил что-то читать после работы, поэтому мне будет тяжело новую работу искать — сперва придётся уйти со старой, а у меня запасов месяца на два, не больше.
Palpatin
30.01.2023 12:38Выгорание, нет сил на учёбу, новая пачка струн как праздник, как же это знакомо! Я собрался и поменял работу. В принципе, по деньгам ничего не изменилось, но работать стало гораздо интереснее. У меня был страх, страх потери дохода. Сейчас я стал немного увереннее :)
Может быть у вас выгорание как раз из-за нестабильного заработка? Типа то густо, то пусто, вот оно и действует на нервы потихоньку.
Metotron0
31.01.2023 04:06С доходом так стало недавно, а учиться ломает уже несколько лет. Работу-то я не так уж давно сменил, меньше года прошло. Когда мне было лет 25, всё было интересно, я что-то придумывал, пописывал для себя всякие придумки, но я тогда не работал программистом. Потом это стало работой и больше не хочется этим заниматься помимо работы. Может, это просто возраст.
engine9
29.01.2023 23:08Эту проблему (отчуждения труда) описывали лет пятдесят тому назад, тогда она считалась некоторыми чуть ли не основной причиной вызывающей психические расстройства у работников.
F376
29.01.2023 17:56-1Начать надо с того что не использовать синтетические, искусственные термины, коим является "выгорание" и эта статья познакомила меня еще с одним - техностресс. Все это не помогает, а запутывает и уводит от сути. Правильно: усталость. Но усталость не физическая, а психологическая. Именно дедуктивный разбор с использованием простых, понятных определений поможет понять что происходит и как с этим бороться.
Я догадываюсь что человеку или что может быть более верно - отдельным людям противопоказан 1. сам метод ведения какой-либо деятельности, в виде неподвижного сидения и наблюдения различных картин - достаточно абстрагироваться от "компьютера", заменив его на допустим, сложный пульт управления. 2. Монотонная деятельность (ответы я уверен есть в исследовании производственной деятельности у станков и конвееров) 3. Ведение подобной деятельности под принуждением (финансовый прессинг, страх потери дохода, страх в итоге оказаться на улице). — Внимательное рассмотрение всего лишь 3х этих обстоятельств уже дает почву для размышления.
И наконец, совершенно отдельный вид психологический усталости (ветвь), но связанной не с монотонной деятельностью у сложного "пульта" под принуждением, а связанный с грузом ответственности (своего рода тоже постоянный прессинг страха). Понятно, что человек постоянно навязчиво испытывающий страх неудачи стремится избавиться от неприятных обстоятельств, сбежать, (уволиться), прекратить стрессовую ситуацию.
Вот что есть названное словом "выгорание". Это психологическая усталость, вызванная статической неподвижностью, сопровождаемая одним и тем же монотонным действием под принуждением (страхом) и еще вдовесок заряженная страхом порожденным ответственностью за неудачу. Разумеется, человек начинает неосознанно избегать негативных обстоятельств, начинает блуждать, только бы не возвращаться к источнику стресса. И это, между прочим и есть так называемая "прокрастинация", её причина.
geher
29.01.2023 18:45Начать надо с того что не использовать синтетические, искусственные термины, коим является "выгорание" и эта статья познакомила меня еще с одним - техностресс. Все это не помогает, а запутывает и уводит от сути. Правильно: усталость.
Выгорание и усталость - очень разные вещи. Одно из важных отличий - при усталости отдых полностью снимает проблему, а при выгорании - никак. Втррое важное отличие - при усталости не теряется интерес к жизни. При выгорании все становится по барабану.
И основная причина выгорания, каа мне представляется, это постоянное несоответствие ожиданий или желаний с одной стороны и достигнутого результата с другой, причем исключительно в худшую сторону. Тут, естественно, и усталость может рядом крутиться, например, когда следуешь путем "надо еще больше работать", а вместо ожидаемого праздника жизни в награду получаешь одну лишь только усталость. При этом формально поставленная цель может быть даже достигнута (проект закончен, деньги получены), но ожидаемой радости оно почему-то не приносит.
Maccimo
29.01.2023 18:55Одно из важных отличий — при усталости отдых полностью снимает проблему, а при выгорании — никак.
Отдых великолепно снимает проблему.
Увольняешься, полгода — год пинаешь балду и снова как новенький.geher
29.01.2023 23:03Что-то мне подсказывает, что смысл вполне конкретного понятия выгорание размывается так же, как уже размылся смысл понятия депрессия. Человеку грустно - "У меня депрессия! Человек подустал - "У меня выгорание!"
Если у человека реально выгорание, он уже не может выкарабкаться сам, просто пиная балду (срок не имеет значения). Ему нужна как минимум серьезная психологическая поддержка. Лучше со стороны нормального специалиста, но хотя бы со стороны близких людей.
Не говоря уже о такой мелочи, как невозможность для многих пинать балду полгода без существенных потерь в социальном статусе и квалификации, что весьма часто способствует не выходу из выгорания, а скорее к дальнейшему погружению в него. Или (в случае счастливого исцеления при наличии какой-никакой помощи) закладывает фундамент для нового выгорания.
Interfer Автор
30.01.2023 00:19Люди разные. И ситуации разные. Вы описываете совсем уж клинику. Но человек - существо весьма адаптивное. И многие вещи может преодолеть сам. Существует множество болезней, где без помощи хорошего врача не обойтись. И все же все мы болеем простудой или гриппом, при которых нужна лишь неделя покоя и мы как новенькие) А вот если грипп переносить на ногах... то тоже может ничего не случиться. А может потребоваться помощь специалистов.
geher
30.01.2023 18:47Вы описываете совсем уж клинику
А выгорание - это и есть "клиника".
Потому и важно отдыхать до того, как выгорел.
Maccimo
31.01.2023 01:17Если у человека реально выгорание, он уже не может выкарабкаться сам, просто пиная балду (срок не имеет значения).
Не нужно смешивать выгорание и клиническую депрессию, это разные вещи.
Ему нужна как минимум серьезная психологическая поддержка.
Приведите авторитетный источник для этого утверждения.
Не говоря уже о такой мелочи, как невозможность для многих пинать балду полгода без существенных потерь в социальном статусе и квалификации,
Для поддержания квалификации во время отдыха открыт весь опенсорс мира, а для поддержания социального статуса существует толстая финансовая подушка.
geher
31.01.2023 19:23Не нужно смешивать выгорание и клиническую депрессию, это разные вещи.
Разные, там и механизм формирования разный (хотя часть симптомов схожа), и лечение сильно отличается. Но просто пиная балду не выкарабкаться ни из одного, ни из другого состояния.
Приведите авторитетный источник для этого утверждения.
Это утверждение - эмпирический опыт множестаа человек. Психологическая поддержка хотя бы со стороны близких крайне необходима (а вот близкие часто вместо этой самой поддержки как раз начинают "кончай фигней страдать, возьми себя в руки и работай больше").
Для поддержания квалификации во время отдыха открыт весь опенсорс мира,
Странные у вас представления о процессе пинания балды. Да и в условиях выхода из выгорания не всегда приемлемое занятие.
а для поддержания социального статуса существует толстая финансовая подушка.
Социальный статус определяется не только финансовыми моментами. Да и самой толстой подушки на момент выгорания у пациента может не оказаться по разным причинам (например, многие успевают выгореть толком не заработав, зато успев повесить себе на шею ипотеку и еще пару кредитов).
BigBeaver
30.01.2023 10:40Одно из важных отличий — при усталости отдых полностью снимает проблему, а при выгорании — никак.
Просто наивно думать, что можно два года пахать без выходных а потом отдохнуть недельку, и всё пройдет. Отдыхать надо постоянно — в идеале каждый день.
iosuslov
29.01.2023 19:35Сам работал 8 лет на заводе и пару раз "подгорел". Согласен только с одним пунктом
-
В IT больше необычных(странных, замкнутых и т.д.) людей, чем в других сферах - соответственно, у них больше необычных проблем (тараканов), Что и приводит к повышеному проценту выгораний
Мое мнение на этот счёт - айтишники, в большинстве случаев, достаточно молоды и получают хорошие деньги. Что позволяет им перейти из режима "не сдохнуть с голоду" в режим -"в чем смысл жизни и мое предназначение". Простого ответа на этот вопрос нет, да ещё и с ютуба-инстаграмма постоянно втирают, что нельзя просто перерабатывать воздух в метан и со2, А НУЖНО ДЕЛАТЬ ЧТО-ТО ПО-НАСТОЯЩЕМУ ВАЖНОЕ (для кого?почему? Делает ли кот или рыба что-то важное?) - отсюда и всяческие метания, сомнения и поиски.
На заводе денег платят сильно меньше и люди там в среднем проще, потому и горят не так как в айтишке, но тоже бывает.
-
serhit
29.01.2023 19:39Интересная статья на сайте Роспортебназдора про выгорание и профилактику: https://39.rospotrebnadzor.ru/content/emocionalnoe-vygoranie-i-ego-profilaktika. Там есть хорошие рекомендации по контролю стресса и предупреждению выгорания.
Кстати, "повышение уровня профессионального мастерства" как раз указывается как один ис способов борьбы с вызгоранием. Кто учится новому - реже выгорает.
По поводу эмоциональных стрессов, приводящий к выгоранию, слышал интересное утверждение, что основныи источником их являются "неразрешенные профессиональные конфликты"... Вот об этом стоит задуматься (и руководителю, и команде) и сосредоточится на выявлении и устранении таких факторов.
LeoSv
29.01.2023 19:41Прогеров надо мерять с подобными. Инженерами-разработчиками, конструкторами, научными работниками, учителями, врачами. У них часто бесконечный аврал, сложность работы намного выше, чем у программистов, а зп кратно ниже программистских.
Gryphon88
29.01.2023 21:21+5Сразу оговорюсь, я из не очень динамичной области — embedded, и давно перестал быть юношей с горящими глазами. Я не очень понимаю и само выгорание, и приведенные автором предпосылки. Похоже на навязанные ценности и хипеш на пустом месте.
1. Непрерывное обучение. Мы используем концепции CS, подавляющее большинство которых предложено к 70м; сейчас идеи Lisp переползают в мейнстримные языки, и все такие «ооо!». Датасотонизм и ML во многом матстат, матан и тервер, которые читают в универах по почти нестареющим учебникам. Получается, что мы вынуждены в основном изучать новые инструменты поверх старых концепций. Ну ок, книжная полочка в сортире у меня есть, хотя надо посмотреть, что если средний срок жизни инструмента год, может, не имеет смысла на него перескакивать? Может, это погоня за модой, круг которой замыкается раз в несколько лет?
2. Ответственность. Серьезно? За что ответственность? Может, вам за ответственность доплачивают или за сбой на проде могут оштрафовать и посадить? Более общо: насколько прибыль компании привязана к твоим задачам, можешь ли ты иметь процент, если твои усилия повысят прибыль компании, насколько значимы лично твои усилия в прибыли компании? В большинстве случаев ответ «никак/нет/нисколько», и к работе можно просто относиться как к месту, где ты с 9 до 6 закрываешь кем-то нарезанные или самостоятельно выбранные таски. Нужен в нерабочее время по причине, которая отсутствует в должностной инструкции? Пусть звонят, очень просят, дают двойной оклад и оплачивают такси. Если упадет прод после всех тестов, то с 6 до 9 это не твоя проблема. Работа не твой ребенок, и твоя жизнь не станет лучше, если ты начнешь болеть за нее душой.
3. Сроки и культ продуктивности. Мне дали сроки, задачу, я сижу и работаю. Честно работаю, без перерывов на мемасики, чтобы не загнаться — переключаюсь между задачами или иду покурить. Я работаю, а менеджер недоволен. Ну и хер с ним, в общем-то, особенно если протоколировать распорядок дня и отвлечения: митинги, созвоны, «у нас срочная задача»… Тут или работать мешают, или поставили нереалистичные сроки. Ну или я неправ был при назначении сроков, задачу недооценил, например, но за это все равно не уволят. А даже если уволят… Ну и что, собсно? Мир развалится?
Так что мои рекомендации про выгорание
1. Учитесь говорить «нет», а в некоторых случаях «пнх».
2. Работа — это то, за что платят. Что не оплачивают — не делать и тем более не брать в голову.
3. Учите основы, они не стареют.
4. Бюрократия и отчетность — твои друзья.
5. Don't worry, be happy.iosuslov
30.01.2023 03:45+11. Учитесь говорить «нет», а в некоторых случаях «пнх».
Вот это, кстати, отличный совет! Наберут на себя обязательств, а потом под их весом тонут )))
websitedev
29.01.2023 22:21Поэтому нужно научиться очень хорошо чувствовать ту фазу, откуда начинается выгорание. Но обычно на этой фазе человек чувствует, что ещё немного может работать. Он пропускает эту фазу, так как чаще всего не хочет оторваться от роботы и скорее хочет закончить задачу. Чем дальше пойти этой фазы, чем больше дней понадобиться, чтобы восстановиться.
Рабочий же может реально всю жизнь делать примерно одно и то же. Наш оператор козлового крана лет через тридцать вообще может не думать.
А разве от рутинной работы человек не может выгорать? Думаю, больше, чем от творческой, Хотя, все зависит от темперамента человека. Но, когда ты каждым годом делаешь одно и то же, ты перестаешь развиваться и к чему-то стремиться. Это тоже может стать причиной выгорания.
engine9
29.01.2023 23:18Если рутина позволяет каждый раз проявлять собственную экспертность, то не выгорает, но при условии что у него нет декомпенсированного стресса в других сферах жизни.
Михай Чиксентмихаи исследовал жизнь и труд людей, которые десятки лет проработали за одним делом, например раздельщиком рыбы, и некоторые из них избавлялись от рутины через совершенствование навыков.
Для психики куда хуже задачи типа долго нудно что-то делаем и потом это идёт на свалку потому что не пригодилось или устарело.
engine9
29.01.2023 23:05Наш оператор козлового крана лет через тридцать вообще может не думать
Вспоминается документальная видеозапись с ютуба, где рассказывается про водителя грузовика с выраженной деменцией. Он крутил баранку уже будучи глубоко инвалидизированным и никто ничего не замечал, при том что работу исполнял...
Ну и еще мысль хотел сказать, возможно кто-то в комментариях уже высказал. Есть интересное наблюдение над тем, что сегодняшний ИТ-шник не может выйти на "плато экспертности" т.к. знания слишком быстро обесцениваются из за прогресса и быстрых изменениях во многих сферах ИТ. А раньше, еще лет 40 назад, человек мог почивать на лаврах капитала своих компетенций. Т.е. здание опыта, которое он строил годами труда не разваливалось.
Наверняка в ИТ есть более фундаментальные сферы, а есть те, которые слишком переменчивы.
DSRussell
30.01.2023 00:24-2Выгорают как правило те кто пошел в ИТ за бабками, а не ради интереса
Interfer Автор
30.01.2023 00:40И снова нужно вернуться к теме индивидуальной мотивации. Что движет человеком, когда он берется за ту или иную работу? Самый очевидный ответ - деньги! Но он не всегда правильный. Я уже готовлю новую статью на эту тему, думаю, там будет о чем поговорить)
michael_v89
30.01.2023 01:42Надо различать 2 вещи.
1 — Когда не хочешь что-то делать, и делаешь через нежелание. Нежелание возникает от того, что у организма почему-то есть неприятные ощущения, обычно потому что ему сложно это делать. На преодоление тратятся нервные ресурсы, и когда делаешь это постоянно, они не успевают восстанавливаться.
2 — Когда хочешь что-то делать, тебе нравится процесс, или нравится получать результат. Кажется, что еще вот это вот сделать и всё, но новая работа появляется постоянно, ищешь способ как сделать ее эффективнее, где-то приходится срезать углы, делать всё быстрее, отвлекаться от предыдущей задачи. Каждая новая задача воспринимается как отвлекающий фактор от предыдущей, которую еще не успел сделать, это вызывает раздражение. Здесь нервные ресурсы тратятся по собственному желанию, без преодоления нежелания, но из-за количества работы тоже не успевают восстанавливаться. Этот вид выгорания опаснее, чем первый, в него легко попасть, но сложно это вовремя заметить, и восстанавливаться после него дольше и сложнее.Их почему-то часто путают, или считают одним и тем же, особенно те, кто выгорания не испытывал. Многие считают выгоранием только первый вариант, причем только начало, которое называется просто "усталость", "надоело", "задолбало". Но это не выгорание, выгорание наступает если пытаться это постоянно преодолевать.
У нервных клеток тоже есть ресурс, как и у мышц. Поэтому им тоже надо давать отдых. Клетки адаптируются к нагрузке и начинают работать в другом режиме. Поэтому на отдых нужно время, необходимое для того, чтобы клетки вернулись в нормальный режим работы. Забыть главные детали задачи, выкинуть их из головы. Обычно оно сравнимо с временем усиленной работы. Сон восполняет ресурсы клеток после рабочего дня, но режим их работы не меняется. Для изменения нужно отвлечение внимания, нужно подумать о чем-то другом. Поэтому так важно отвлекаться и не работать по выходным. Надо смотреть фильмы, гулять, заниматься хобби, чтобы клетки не оставались в этом напряженнном состоянии готовности к работе.
Interfer Автор
30.01.2023 13:55Следующая статья серии уже в эфире) Там подробно про мотивацию) https://habr.com/ru/post/713650/
Gradiens
31.01.2023 00:02Навсегда запомнил время, когда меня только поставили во главе команды разработчиков. Я буднично раздал им задачи и обозначил сроки. Все профукали. Я начал разборки на тему: «какого хрена???».
Стесняюсь спросить, а до этого вы кем работали? В смысле, вас повысили из разработчиков, или вы были менеджером в другой области?
На следующий день прибежала наш HR с круглыми глазами и стала возить лицом по столу уже меня.
А вот это интересно, как она узнала? Кто-то нажаловался?
Metotron0
31.01.2023 16:16Кто угодно нажаловался, это же HR, с проблемами в коллективе надо к ней идти, она для этого и работает.
Interfer Автор
31.01.2023 16:26+1Я был начальником отдела беспроводных технологий. Мы тогда начали подключать приборы учета и потребовалась платформа для сбора данных с них.
На тот момент я успел глубоко погрузиться в специфику, потому задача написать платформу как-то логично легла на меня. В помощь мне дали команду джунов.
Я даже спорить не буду, что подход неверный. Но опыта не было, а вера в свои силы была. Пришлось учиться по ходу. История довольно интересная, это вообще моя маленькая гордость, но писать про это отдельную статью пока не решаюсь.
Процесс трансформации в полноценную ИТ-компанию из провайдера у нас продолжался года три и был не без шероховатостей, да. За это время создано приличное число проектов, и платформа диспетчеризации лишь один из. Но я ее привожу в пример как свой проект, на котором могу разбирать ошибки.
А узнала - да, нажаловались. Сказали - пришел какой-то беспроводной чувак и давай свои порядки внедрять, хотя он нам даже не босс. Я ни на кого не в обиде) было и было, главное, что сделали.
dkuzminov
Никогда не видел выгорания от необходимости учиться новому. Зато видел выгорание от обратного: когда твои знания оказываются необоснованно невостребованными.
Разберем на примере Lego. Работа инженера должна походить на его сборку. То есть есть блоки, каждый блок имеет предсказуемый размер и прочие свойства, есть инструкция по сборке -- сплошное удовольствие. Но на практике оказывается, что ты пришел в команду уже через пять лет после старта проекта, коробка от Lego открыта, инструкция потеряна, и ее даже никто не читал. Начало сборки было произведено неправильно, и исправить все можно только начав сначала. Часть блоков утеряна, часть поломана, часть заменена блоками от другого набора, причем более дешевого и вообще не-Lego (и у него другие размеры). Поскольку блоки не подходили друг другу, для их сборки активно использовался суперклей. Без него обходиться было все сложнее, поэтому в команду наняли двух специальных суперклейщиков, один из который в итоге дорос до менеджера, и руководит проектом. И тут в команду приходишь ты: человек, который когда-то имел возможность изучить утерянную инструкцию...
druidvav
Плохая аналогия подобна котенку с дверцей, ага. Сборка лего по инструкции — не работа инженера.
vkni
+1 Это работа рабочего. :-)
Работа инженера — это написание этой самой инструкции.
dkuzminov
А давайте я с вами соглашусь. Да, это написание инструкции того, как пользоваться изделием, спроектированным из частей... использованных по инструкции к этим частям. Возвращаясь к аналогии с Лего: в инструкции нигде написано, что требуется склейка суперклеем. Тот агрегат, который получится подобным способом вряд ли смогут адекватно использовать потребители вашей продукции.
Далее, сравнивая рабочих и инженеров, стоит отметить, что в профессии software engineer есть черты и того, и другого. То есть можно считать, что мы создаем код так, как инженеры "пишут инструкцию", но тогда в роли рабочего оказывается компилятор: аналогия как-то распадается. По сути, программист является и инженером, и рабочим одновременно, т.к. он создает продукт сам, а не только проект этого продукта. И вот качество создаваемого сильно зависит от того, насколько мы адекватны в использовании технологий.
druidvav
чтобы не накручивать условия для своих же странных аналогий просто попробуйте аргументировать свое мнение БЕЗ аналогий. Например в вашем первом комментарии достаточно было бы написать, что SE часто сталкиваются с недокументированными системами, с плохой организацией процесса и т.п.
К чему там лего совершенно непонятно.
С этими проблемами может столкнуться равнозначно и "инженер" и "рабочий", но в случае рабочего — исправление и разбор — не его проблема. И инженеры в других областях абсолютно так же выгорают. Спросите любого инженера/архитектора/проектировщика со стройки например.
dkuzminov
Хорошо, отбросим Лего. Возьмем книгу Стива Макконнелла "Совершенный код": признанная классика. В ней задача инженера описывается как минимизация избыточной сложности: то есть концентрация на сложности задачи при минимизации сложности реализации. В этом смысле если у вас есть хорошо документированная технология, то неграмотное ее использование (как правило, происходит из-за поверхностного ее понимания) сильно повышает сложность там, где ее можно было бы избежать. Производство плохо документированного загадочного кода также ее увеличивает. В итоге инженеры выгорают не от того, что жизнь их заставляет изучать новые технологии, а от того, что им приходится работать с недокументированными артефактами, нарушающими принятые стандарты.
druidvav
Жизнь. не. идеальный. случай.
Люди ошибаются при проектировании, люди спешат и срезают углы. ВО ВСЕХ ОБЛАСТЯХ. Задача инженера — реализация бизнес задач, а не инженерия ради инженерии и код ради ХОРОШЕГО КОДА.
dkuzminov
Ну вот отсюда и выгорание. И свойственно оно именно хорошим инженерам. Никогда не видел выгоревшего говнокодера... а жаль...
druidvav
говнокодер понятие субъективное. я видел выгорание и у слабых программистов, им часто для решения задач приходится прилагать больше усилий.
druidvav
собственно в этом и есть отличие инженера. когда у тебя четко определена задача и ты делаешь все по инструкции как положено -- это уже не инженерия, даже если ты пишешь текст/код/собираешь лего. инженерия всегда исходит из нечетких формулировок задачи и неопределенности при решении этой задачи.
dkuzminov
Тут надо разделять задачи на два класса. Первый -- если нечеткость задачи можно разрешить аналитически (иными словами, у вас есть вся необходимая информация, ее лишь нужно обработать). Второй -- когда информации нет, и ее нужно добыть. Инженерия относится к первой категории, вторая -- это исследования. В процессе разработки мы часто сталкиваемся с задачами второго вида, и тогда наша работа начинает называться эвфемизмами типа "прототип", "proof of concept", и т.д. И вот беда в том, что мы редко выходим из состояния прототипа в реальный инженерный мир, где хороший дизайн гарантирует разумное качество.
druidvav
в реальной жизни все живут в условиях неопределенности, реальный инженерный мир это что по вашему? все продукты инженерии — компромисс, идеала нет и не может быть. Инженер всегда делает допущения на уровне своей ответственности.
dkuzminov
В том зачастую и есть отличие хорошего инженера от плохого. Иногда, когда один делает допущения (хорошие или плохие), другой не догадывается, а знает. Тут опять же есть варианты: один знает по опыту своих ошибок, другой -- по опыту чужих.
В современной индустрии ПО вообще инженерный принцип сильно нарушается. Если в других областях прототип никогда не идет в продакшн, а используется только как объект для эксперимента (позже выбрасывается или ставится в музей), а продакшн полностью переделывается с учетом поступившей новой информации -- то в ПО принято говнячить что есть, а потом накатывать патч за патчем. ИМХО, отсюда и выгорание.
0xd34df00d
ИМХО второй класс задач тоже делится на два принципиально два разных подкласса. В одном вам нужно понять, условно, как решать ту или иную задачу и можно ли вообще её решить. Во втором — понять, какую вообще задачу нужно решать. В первом случае вы занимаетесь CS/математическим ресёрчем, во втором — общаетесь с клиентами.
Лично я первые задачи обожаю, вторые — терпеть не могу.
vkni
Второе — это «постановка задачи». Мой отец очень любит и умеет этим заниматься.
Там, кстати серьёзная проблема — определить, что задачу вообще надо поставит, доформулировать.
Кстати, в программистских вещах, если ты занимаешься чем-то вроде стат. анализа программ или компиляции, то заказчиком можешь быть и сам. И тогда приходится заниматься самокопанием на тему «Медный король, Медный король. Возьми, что мне дорого, подай, что мне нужно».
Ksoo
Как опытный говнокодер, сообщаю: выгораем еще быстрей. Потому что когда делаешь плохо, то очень быстро становится сложно вносить изменения и много времени тратишь на борьбу со своим кодом, а не с реализацией задачи.
dkuzminov
Слова не говнокодера, но мужа.
vkni
Нет, исключительно инженером. Работает CPU. Собственно, вспомните «лень, гордыня и нетерпение — три главных добродетели программиста» и «компьютер должен работать, а человек — думать».
Программисты — не сборщики, мы — конструкторы. Собственно, вот на этом чуть не погорел лирический герой статьи: решил, что пришёл к рабочим на конвейер, а на самом деле он пришёл в ОКБ. На этом же горит агиле, сжигая миллионы человеко-лет.
Akon32
Можно подробней? Мне казалось, в разработке ПО от применения agile толку больше, чем от тонн проектной документации.
vkni
Типичное агиле — это попытка сделать конвейер: вам пришла заявка, вы её отработали, следующая. При этом совершенно лесом идёт долгосрочное планирование, в результате вместо стройной системы получается хаотичная куча. Ну, это в случае, если с агиле не борятся «партизанскими методами».
С «тоннами проектной документации» – та же самая ситуация: программист низводится до исполнительного устройства/работяги. Понимаете, программа — это и есть «проектная документация». Особенно хорошо это видно на декларативных ЯВУ сверхвысокого уровня: тот же SQL — это описание того, что мы хотим получить, а не то, что конкретно нужно сделать, перевод же в императивный код делает движок базы данных.
Короче, «программа — это максимально проработанное Т.З., которое можно выдать абсолютно исполнительному идиоту». А «программист» — это человек, составляющий это Т.З. Поэтому подход с «тоннами проектной документации» просто превращает в программиста составителя этой документации (но у этого программиста нет развитых средств отладки — он отделён от компьютера), а «линейного программиста» превращает в машинистку, программу распознавания текста. Ну и КПД чудовищно падает.
BorisTheAnimal
Долгосрочное планирование в IT идет лесом просто по специфики современного мира и ИТ отрасли как таковой. Слишком много не определенности, что бы строить долгосрочные планы. Точнее вы можете строить roadmap, но не больше. У компании могут поменяться цели, могут поменять ожидания покупателей, появится новая технология, разработка встанет на пару недель в тупик из-за неизвестной проблемы и т.п..
если получается хаотичная куча - не в аджайле дело.
vkni
В нём, родимом. Разумеется, первопричина — это тот хаос рыночной экономики, который вы прекрасно описали в первом абзаце. Но непосредственный виновник, зачастую, агиле.
dkuzminov
Проблема не в эджайле, а в том, что его мало кто понимает, и используют наподобие карго-культа. Атрибуты, вроде, похожие, стендапы по расписанию, вайтборд с красочными бумажками, бубен сертифицированный, КАК это использовать, все знают, а вот ЗАЧЕМ -- даже не задаются вопросом. Отсюда автоматически получают все cons, даже на зная, какие должны были быть pros.
ProMix
А, да? А можно мне CPU будет код писать? Я же инженер, а не рабочий!
А вообще интересный вопрос, кто является конструктором, а кто рабочим (хотя я размышлял в терминологии заказчик - исполнитель). И ответ на этот вопрос кроется в интересуемом уровне абстракции.
Например: начальник дал задание, программист его выполняет. Кто заказчик, кто исполнитель - понятно. А потом программист даёт задание компьютеру. Кто заказчик, кто программист - тоже понятно. Так и кто в итоге программист-то?..
vkni
Вы как господин Журден сейчас узнаете, что всю жизнь говорите прозой.
CPU и пишет код для CPU, когда вы запускаете компилятор.
dimao79
Работа инженера несколько сложнее:
Собрать самому.
Собрать самому и понять как оно собирается в принципе.
Собрать самому так, что бы как оно собирается поняли другие.
Написать инструкцию по сборке.
Собрать самому по этой инструкции.
Проконтролировать сборку другими.
Допилить инструкцию по сборке с учетом всплывших нюансов.
Повторить пункты 6-7 несколько раз.
Выдохнуть, забыть и переключиться на следующий конструктор.
Периодически вспоминать и повторять пункты 6-9, иногда начиная с пункта 3, а иногда и 2.
iggr63
Точно. А еще засекать по часам сколько времени требуется на операции. После запуска в серию посмотреть на средний процент выхода изделий с первого раза. И среднее время на отказ.
vkni
А это называется заграничным словом benchmark. Наработки на отказ, правда нет в програзме — по-умолчанию это бесконечность.
vkni
У меня «лекция для колхозников», а вы — «дачник». :-)
Если приглядеться, то все ваши 10 пунктов описывают и работу программиста, с точностью до аналогии. Только «другие» — это «компьютеры».
dimao79
Они описывают практически любого инженера - разобраться, сделать, обучить, проконтролировать.
vkni
Это я доказываю, что программист — это тоже инженер, а не рабочий.
Wesha
А на этот случай есть мы, индустриальные археологи.
dkuzminov
Вот и я о том же. Есть исследование, а есть разработка, и их опасно смешивать.
Когда-то я работал в области биотехнологий. Так вот там было ощущение того, что какая-то криворукая нечистая сила написала нам код на языке ДНК, и явно пренебрегла логикой и инженерным смыслом. То есть для меня природа является олицетворением наихудшего инженера. Но то Природа, мать наша, и исследование ее работ является захватывающим, осмысленным и целесообразным процессом. Но вот когда те же ощущения нечистой силы у меня возникают при анализе кода на высокоуровневом языке программирования...
Akon32
Ничего удивительного в этом нет. Во-первых, проекты со временем именно эволюционируют, когда правки вносятся десятки и сотни раз. Во-вторых, различное применение эволюционных подходов при создании кода вполне себе работает, но вот пытаться понять такой код может быть бессмысленным занятием.
Wesha
Немым (и не только) подтверждением истинности этого высказывания являются все человеки (и не только) на планете Земля.
sved
Постоянно слышу жалобы про то что кто-то "неправильно" сделал проект, а то же время очевидно же "правильное" решение.
Но, на самом деле, невозможно написать что-либо реально хорошее с первого раза. За мою многолетнюю практику я такого ни разу не видел. Архитектурные баги так же неизбежны, как и программные. Тем более, что технологии меняются и то что вчера было ок, сегодня уже может выглядеть дичью.
Самая большая проблема - это на самом деле не ошибки, а неумение либо не желание их исправлять. Надо при оценке задач всегда закладывать хотя процентов 50 на рефакторинг и улучшения, это должно быть стандартной практикой. Причём проблемы должны фикситься по мере их обнаружения, а не так "рефакторинг на следующей неделе, пока живём с тем, что есть".
dkuzminov
А я пойду дальше, сказав, что не существует ни правильных, ни неправильных решений. Бывает только валидная аргументация (или отсутствие таковой).
Нальзя. И об этом стоит знать в момент, когда начинаешь разработку. И стоит приготовиться к тому, что все написанное придется выбросить. Формы бывают разные: непрерывный рефакторинг, прототипирование. Но если придерживаться принципа "херак-херак и в продакшн", то технический долг растет как ком снега. Отсюда и раздутые бюджеты, и погибающие под собственным весом проекты, и выгорание сотрудников -- о нем, собственно, я и писал.
Frevv
Не обязательно, я работал летом по 14 часов в день 5 дней в неделю и обязательно в выходные. Инструктором. Выгорел, 2 недели отходил. Но это меньше чем от работы в ИТ, я пол года не хотел новую работу после увольнения с работы по ИТ профессии.
Так же сейчас шью - у меня есть определенный план и сроки. 20 дней шью, реально устал, хочется завершить вещь и отдохнуть. Но тут проще, выгорания нет и просто хочется завершить проект. А выгорания нет - потому что работаю сколько хочу, вот выходные отдыхаю сейчас.