Комментарии 182
Работа в ИТ-сфере – это постоянная учеба. ПОСТОЯННАЯ.
Никогда не видел выгорания от необходимости учиться новому. Зато видел выгорание от обратного: когда твои знания оказываются необоснованно невостребованными.
Разберем на примере Lego. Работа инженера должна походить на его сборку. То есть есть блоки, каждый блок имеет предсказуемый размер и прочие свойства, есть инструкция по сборке -- сплошное удовольствие. Но на практике оказывается, что ты пришел в команду уже через пять лет после старта проекта, коробка от Lego открыта, инструкция потеряна, и ее даже никто не читал. Начало сборки было произведено неправильно, и исправить все можно только начав сначала. Часть блоков утеряна, часть поломана, часть заменена блоками от другого набора, причем более дешевого и вообще не-Lego (и у него другие размеры). Поскольку блоки не подходили друг другу, для их сборки активно использовался суперклей. Без него обходиться было все сложнее, поэтому в команду наняли двух специальных суперклейщиков, один из который в итоге дорос до менеджера, и руководит проектом. И тут в команду приходишь ты: человек, который когда-то имел возможность изучить утерянную инструкцию...
Плохая аналогия подобна котенку с дверцей, ага. Сборка лего по инструкции — не работа инженера.
+1 Это работа рабочего. :-)
Работа инженера — это написание этой самой инструкции.
А давайте я с вами соглашусь. Да, это написание инструкции того, как пользоваться изделием, спроектированным из частей... использованных по инструкции к этим частям. Возвращаясь к аналогии с Лего: в инструкции нигде написано, что требуется склейка суперклеем. Тот агрегат, который получится подобным способом вряд ли смогут адекватно использовать потребители вашей продукции.
Далее, сравнивая рабочих и инженеров, стоит отметить, что в профессии software engineer есть черты и того, и другого. То есть можно считать, что мы создаем код так, как инженеры "пишут инструкцию", но тогда в роли рабочего оказывается компилятор: аналогия как-то распадается. По сути, программист является и инженером, и рабочим одновременно, т.к. он создает продукт сам, а не только проект этого продукта. И вот качество создаваемого сильно зависит от того, насколько мы адекватны в использовании технологий.
чтобы не накручивать условия для своих же странных аналогий просто попробуйте аргументировать свое мнение БЕЗ аналогий. Например в вашем первом комментарии достаточно было бы написать, что SE часто сталкиваются с недокументированными системами, с плохой организацией процесса и т.п.
К чему там лего совершенно непонятно.
С этими проблемами может столкнуться равнозначно и "инженер" и "рабочий", но в случае рабочего — исправление и разбор — не его проблема. И инженеры в других областях абсолютно так же выгорают. Спросите любого инженера/архитектора/проектировщика со стройки например.
Хорошо, отбросим Лего. Возьмем книгу Стива Макконнелла "Совершенный код": признанная классика. В ней задача инженера описывается как минимизация избыточной сложности: то есть концентрация на сложности задачи при минимизации сложности реализации. В этом смысле если у вас есть хорошо документированная технология, то неграмотное ее использование (как правило, происходит из-за поверхностного ее понимания) сильно повышает сложность там, где ее можно было бы избежать. Производство плохо документированного загадочного кода также ее увеличивает. В итоге инженеры выгорают не от того, что жизнь их заставляет изучать новые технологии, а от того, что им приходится работать с недокументированными артефактами, нарушающими принятые стандарты.
Жизнь. не. идеальный. случай.
Люди ошибаются при проектировании, люди спешат и срезают углы. ВО ВСЕХ ОБЛАСТЯХ. Задача инженера — реализация бизнес задач, а не инженерия ради инженерии и код ради ХОРОШЕГО КОДА.
Ну вот отсюда и выгорание. И свойственно оно именно хорошим инженерам. Никогда не видел выгоревшего говнокодера... а жаль...
говнокодер понятие субъективное. я видел выгорание и у слабых программистов, им часто для решения задач приходится прилагать больше усилий.
собственно в этом и есть отличие инженера. когда у тебя четко определена задача и ты делаешь все по инструкции как положено -- это уже не инженерия, даже если ты пишешь текст/код/собираешь лего. инженерия всегда исходит из нечетких формулировок задачи и неопределенности при решении этой задачи.
Тут надо разделять задачи на два класса. Первый -- если нечеткость задачи можно разрешить аналитически (иными словами, у вас есть вся необходимая информация, ее лишь нужно обработать). Второй -- когда информации нет, и ее нужно добыть. Инженерия относится к первой категории, вторая -- это исследования. В процессе разработки мы часто сталкиваемся с задачами второго вида, и тогда наша работа начинает называться эвфемизмами типа "прототип", "proof of concept", и т.д. И вот беда в том, что мы редко выходим из состояния прототипа в реальный инженерный мир, где хороший дизайн гарантирует разумное качество.
в реальной жизни все живут в условиях неопределенности, реальный инженерный мир это что по вашему? все продукты инженерии — компромисс, идеала нет и не может быть. Инженер всегда делает допущения на уровне своей ответственности.
В том зачастую и есть отличие хорошего инженера от плохого. Иногда, когда один делает допущения (хорошие или плохие), другой не догадывается, а знает. Тут опять же есть варианты: один знает по опыту своих ошибок, другой -- по опыту чужих.
В современной индустрии ПО вообще инженерный принцип сильно нарушается. Если в других областях прототип никогда не идет в продакшн, а используется только как объект для эксперимента (позже выбрасывается или ставится в музей), а продакшн полностью переделывается с учетом поступившей новой информации -- то в ПО принято говнячить что есть, а потом накатывать патч за патчем. ИМХО, отсюда и выгорание.
Второе — это «постановка задачи». Мой отец очень любит и умеет этим заниматься.
Там, кстати серьёзная проблема — определить, что задачу вообще надо поставит, доформулировать.
Кстати, в программистских вещах, если ты занимаешься чем-то вроде стат. анализа программ или компиляции, то заказчиком можешь быть и сам. И тогда приходится заниматься самокопанием на тему «Медный король, Медный король. Возьми, что мне дорого, подай, что мне нужно».
Как опытный говнокодер, сообщаю: выгораем еще быстрей. Потому что когда делаешь плохо, то очень быстро становится сложно вносить изменения и много времени тратишь на борьбу со своим кодом, а не с реализацией задачи.
Реализация бизнес-задач - задача бизнесмена. Для этого он нанимает инженера, а не другого бизнесмена. А потом уже выкручивает ему руки, чтобы тот "срезал углы". Если же нанять сразу "решателя бизнес-задач", то он и будет решать бизнес-задачи, но не факт что бизнес-задачи нанимателя. Очень хорошо видно в строительстве.
По сути, программист является и инженером, и рабочим
Нет, исключительно инженером. Работает CPU. Собственно, вспомните «лень, гордыня и нетерпение — три главных добродетели программиста» и «компьютер должен работать, а человек — думать».
Программисты — не сборщики, мы — конструкторы. Собственно, вот на этом чуть не погорел лирический герой статьи: решил, что пришёл к рабочим на конвейер, а на самом деле он пришёл в ОКБ. На этом же горит агиле, сжигая миллионы человеко-лет.
На этом же горит агиле
Можно подробней? Мне казалось, в разработке ПО от применения agile толку больше, чем от тонн проектной документации.
Типичное агиле — это попытка сделать конвейер: вам пришла заявка, вы её отработали, следующая. При этом совершенно лесом идёт долгосрочное планирование, в результате вместо стройной системы получается хаотичная куча. Ну, это в случае, если с агиле не борятся «партизанскими методами».
С «тоннами проектной документации» – та же самая ситуация: программист низводится до исполнительного устройства/работяги. Понимаете, программа — это и есть «проектная документация». Особенно хорошо это видно на декларативных ЯВУ сверхвысокого уровня: тот же SQL — это описание того, что мы хотим получить, а не то, что конкретно нужно сделать, перевод же в императивный код делает движок базы данных.
Короче, «программа — это максимально проработанное Т.З., которое можно выдать абсолютно исполнительному идиоту». А «программист» — это человек, составляющий это Т.З. Поэтому подход с «тоннами проектной документации» просто превращает в программиста составителя этой документации (но у этого программиста нет развитых средств отладки — он отделён от компьютера), а «линейного программиста» превращает в машинистку, программу распознавания текста. Ну и КПД чудовищно падает.
этом совершенно лесом идёт долгосрочное планирование
Долгосрочное планирование в IT идет лесом просто по специфики современного мира и ИТ отрасли как таковой. Слишком много не определенности, что бы строить долгосрочные планы. Точнее вы можете строить roadmap, но не больше. У компании могут поменяться цели, могут поменять ожидания покупателей, появится новая технология, разработка встанет на пару недель в тупик из-за неизвестной проблемы и т.п..
стройной системы получается хаотичная куча
если получается хаотичная куча - не в аджайле дело.
если получается хаотичная куча - не в аджайле дело.
В нём, родимом. Разумеется, первопричина — это тот хаос рыночной экономики, который вы прекрасно описали в первом абзаце. Но непосредственный виновник, зачастую, агиле.
Проблема не в эджайле, а в том, что его мало кто понимает, и используют наподобие карго-культа. Атрибуты, вроде, похожие, стендапы по расписанию, вайтборд с красочными бумажками, бубен сертифицированный, КАК это использовать, все знают, а вот ЗАЧЕМ -- даже не задаются вопросом. Отсюда автоматически получают все cons, даже на зная, какие должны были быть pros.
Нет, исключительно инженером. Работает CPU
А, да? А можно мне CPU будет код писать? Я же инженер, а не рабочий!
А вообще интересный вопрос, кто является конструктором, а кто рабочим (хотя я размышлял в терминологии заказчик - исполнитель). И ответ на этот вопрос кроется в интересуемом уровне абстракции.
Например: начальник дал задание, программист его выполняет. Кто заказчик, кто исполнитель - понятно. А потом программист даёт задание компьютеру. Кто заказчик, кто программист - тоже понятно. Так и кто в итоге программист-то?..
Работа инженера несколько сложнее:
Собрать самому.
Собрать самому и понять как оно собирается в принципе.
Собрать самому так, что бы как оно собирается поняли другие.
Написать инструкцию по сборке.
Собрать самому по этой инструкции.
Проконтролировать сборку другими.
Допилить инструкцию по сборке с учетом всплывших нюансов.
Повторить пункты 6-7 несколько раз.
Выдохнуть, забыть и переключиться на следующий конструктор.
Периодически вспоминать и повторять пункты 6-9, иногда начиная с пункта 3, а иногда и 2.
У меня «лекция для колхозников», а вы — «дачник». :-)
Если приглядеться, то все ваши 10 пунктов описывают и работу программиста, с точностью до аналогии. Только «другие» — это «компьютеры».
коробка от Lego открыта, инструкция потеряна, и ее даже никто не читал
А на этот случай есть мы, индустриальные археологи.
Вот и я о том же. Есть исследование, а есть разработка, и их опасно смешивать.
Когда-то я работал в области биотехнологий. Так вот там было ощущение того, что какая-то криворукая нечистая сила написала нам код на языке ДНК, и явно пренебрегла логикой и инженерным смыслом. То есть для меня природа является олицетворением наихудшего инженера. Но то Природа, мать наша, и исследование ее работ является захватывающим, осмысленным и целесообразным процессом. Но вот когда те же ощущения нечистой силы у меня возникают при анализе кода на высокоуровневом языке программирования...
Но вот когда те же ощущения нечистой силы у меня возникают при анализе кода на высокоуровневом языке программирования...
Ничего удивительного в этом нет. Во-первых, проекты со временем именно эволюционируют, когда правки вносятся десятки и сотни раз. Во-вторых, различное применение эволюционных подходов при создании кода вполне себе работает, но вот пытаться понять такой код может быть бессмысленным занятием.
со временем именно эволюционируют, когда правки вносятся десятки и сотни раз. Во-вторых, различное применение эволюционных подходов при создании кода вполне себе работает, но вот пытаться понять такой код может быть бессмысленным занятием.
Немым (и не только) подтверждением истинности этого высказывания являются все человеки (и не только) на планете Земля.
Постоянно слышу жалобы про то что кто-то "неправильно" сделал проект, а то же время очевидно же "правильное" решение.
Но, на самом деле, невозможно написать что-либо реально хорошее с первого раза. За мою многолетнюю практику я такого ни разу не видел. Архитектурные баги так же неизбежны, как и программные. Тем более, что технологии меняются и то что вчера было ок, сегодня уже может выглядеть дичью.
Самая большая проблема - это на самом деле не ошибки, а неумение либо не желание их исправлять. Надо при оценке задач всегда закладывать хотя процентов 50 на рефакторинг и улучшения, это должно быть стандартной практикой. Причём проблемы должны фикситься по мере их обнаружения, а не так "рефакторинг на следующей неделе, пока живём с тем, что есть".
Постоянно слышу жалобы про то что кто-то "неправильно" сделал проект, а то же время очевидно же "правильное" решение.
А я пойду дальше, сказав, что не существует ни правильных, ни неправильных решений. Бывает только валидная аргументация (или отсутствие таковой).
Но, на самом деле, невозможно написать что-либо реально хорошее с первого раза.
Нальзя. И об этом стоит знать в момент, когда начинаешь разработку. И стоит приготовиться к тому, что все написанное придется выбросить. Формы бывают разные: непрерывный рефакторинг, прототипирование. Но если придерживаться принципа "херак-херак и в продакшн", то технический долг растет как ком снега. Отсюда и раздутые бюджеты, и погибающие под собственным весом проекты, и выгорание сотрудников -- о нем, собственно, я и писал.
Не обязательно, я работал летом по 14 часов в день 5 дней в неделю и обязательно в выходные. Инструктором. Выгорел, 2 недели отходил. Но это меньше чем от работы в ИТ, я пол года не хотел новую работу после увольнения с работы по ИТ профессии.
Так же сейчас шью - у меня есть определенный план и сроки. 20 дней шью, реально устал, хочется завершить вещь и отдохнуть. Но тут проще, выгорания нет и просто хочется завершить проект. А выгорания нет - потому что работаю сколько хочу, вот выходные отдыхаю сейчас.
В разработке постоянно нужно думать. А когда на пару часов перестаешь и делаешь на автомате, все начинает идти под откос, и тогда эффективнее вообще ничего не делать. (По крайней мере меньше убытков, чем написать Г-код и потом с ним мучиться, пока не выкинешь.) В этом основное отличие работы программиста, от крановщика и других профессий. Крановщик может успешно работать и на автомате, не думая.
Выгорание же начинается тогда, когда нужно работать, когда устал и котелок не варит. Работа через силу, без огонька для программиста подобна смерти.
Почему-то сравнивают с крановщиками, а не например с проектировщиками зданий. Там работа очень похожая на программирование и выгорание еще какое.
Потому что проектировщики стоят сильно дороже работяг, а бизнесу хочется платить меньше. Поэтому он пытается всех надурить, что программисты — это работяги. Ну получается надурить себя.
проектировщики сильно дешевле работяг? вы либо описку сделали, либо сомнительное утверждение
Спасибо, описался. Исправил.
Для баланса мнений не могу не заметить, что сейчас рабочие на стройке схожего опыта получают столько же, сколько и проектировщики, если не больше. К примеру, инженер-конструктор 1-2 категории и сварщик примерно 3-4 разряда где то 60 т.р
Вы таки удивитесь, но опытный работяга с документами вполне себе может получать сильно больше проектировщика здания. Я видел разницу в два раза.
Просто потому, что опытный работник с документами на той же стройке это человек настолько редкий, что в городе двухсоттысячнике они расписаны по стройкам на год вперед.
Ну да, капитализм сейчас регрессивная формация.
Мне как-то мнтажник лифтов рассказывал:
Знаешь как выглядит проектная документация на жилой многоквартирный дом?
Это размером с большой письменный стол.
Вот его отправили (был год 12 наверное) монтировать лифты в свеже построенные задния, он спрашивает где документация.
Вот, 3 листочка и печати, общий вид, всякими линиями показаны примерно коммуникации.
он спрашивает, а как мне монтировать, на что последовал ответ: вы же сами знаете.
Так что не зря проектировщикам 30 т. рублей платят. Уже нет тех проектировщиков.
P.S. Дело было на Украине
Уже нет тех проектировщиков.
...и вот тут в дело вступаем мы, индустриальные археологи.
А вот это хорошая мысль. Спасибо, я ее обдумаю)
Кстати, хорошо подметили. Я что-то уперся только в сложность профессии, оставив за рамками сложность задачи.
В этом основное отличие работы программиста, от крановщика и других профессий. Крановщик может успешно работать и на автомате, не думая.
Основное отличие в том, что некоторые программисты считают свою работу "особенной".
Какие ещё «противоположные мнения» ожидал автор в ответ на свою графоманию? Надеялся, что тут есть оживлённое сообщество крановщиков?
Я крановщик, но для души, на самом деле я стартапер :)
Скажем так, у меня тоже есть профессиональная деформация. И мне тут правильные мысли стали озвучивать. Про напряженность работы, про другие высококвалифицированные специальности. Повод задуматься.
Не знаю как у вас, а у меня есть проблема. Я живу в своем мирке. И мне бывает сложно посмотреть за его границы. Такие статьи и здоровая критика сильно помогают. Потому я сразу обозначаю цель статьи - подискутировать. Конечно, никто не обязан мне помогать, равно как и читать меня)))
Не стоит писать, что у какого-то рабочего ответственности нуль, а вот у нас, у программистов...! На химкомбинате цена ошибки рабочего может привезти к разрушению цеха, травмам и даже смертям рабочих и загрязнению окружающей среды и близлежащего города. А уровень нагрузки на руководство вам такой даже не снился, когда в четыре утра начальство все поднимают из кроватей по причине остановки цеха.
Я сам занимаюсь схемотехникой, а отец был начальником цеха на химкомбинате. Поэтому я знаю что моя работа разнообразная, творческая и не сложная, а у рабочих бывает нудная, ответственная и тяжёлая.
И про оператора крана не надо грязи. Вы неловким щелчком мыши оставите без интернет сервиса 1000 человек на полчаса, а крановщик неловким движением может оставить пару семей без отцов
Я как раз пишу, что всех под одну гребенку грести нельзя. И привожу ссылку на свою же статью, когда цена ошибки рабочего реально высокая. Да, я знаю, что так бывает. И все же если взять всех работяг на заводе и прикинуть, сколько из них реально отвечают за кого-то кроме своей бригады - не так уж и много наберется. Понятно, всегда можно придумать ситуацию: "А если он споткнется об этот шланг, весь завод полыхнет". Но я про прямые обязанности.
С бытом заводов я знаком очень хорошо, поверьте)
Но давайте не будем недооценивать айтишников. Они не только в провайдерах работают. И они, в том числе, поддерживают критическую инфраструктуру. Да, если ролик на порнохабе час времени будет недоступен, беды не случится. Но софт сейчас управляет фактически всем. И цены ошибки айтишников тоже бывают немаленькие. Я всегда привожу пример, как неудачно с Восточного взлетела ракета, думая, что она взлетает с Байконура. Бывает. А кто в ракете? А куда она упадет?
"Но давайте не будем недооценивать айтишников". Вы их, по-моему, переоцениваете. Описываете, как какую-то особую касту, "специфичные люди со специфичными потребностями и проблемами". Как-будто у других людей таких потребностей и проблем нет. А вот эта история, где они "все профукали", а потом, как я понял, пошли к эйчару жаловаться, мол, "начальник работать заставляет, не танцует, повозите его лицом об стол, а то разбежимся" - это вообще. :/ Спасибо, что тут же не "выгорели". Странные работники. Насколько я знаком с людьми из IT - это нормальные люди, работают, напрягаются, бывают проблемы. Как у большинства людей, которые работают.
Да, я считаю айтишников специфичными людьми со специфичными проблемами.
Равно как и врачей считаю специфичными людьми со специфичными проблемами.
Практически в любой профессии есть своя специфика. Но вот момент. Рабочих много. Водил много. Они своей массой формируют некое среднее отношение к работе в обществе. И они своей массой создают ... как назвать... ну повестку проблем что ли. То есть за счет их массы в обществе их проблемы в том же обществе поняты, равно как и их потребности.
А вот айтишников или, скажем, библиотекарей резко меньше. И их проблемы хорошо так отличаются, а за счет их немногочисленности обществу могут быть непонятны.
Работают, напрягаются, бывают проблемы - это слишком общее определение. Всю мою статью можно свести к тому, что у людей бывают проблемы и задача руководителя об этом не забывать. Но мы же копаем глубже.
Не знаю, с кем именно вы знакомы и насколько глубоко. Но работа накладывает свой отпечаток и у разных сфер проблемы реально разные.
Навсегда запомнил время, когда меня только поставили во главе команды
разработчиков. Я буднично раздал им задачи и обозначил сроки. Все
профукали.
Ну это замечательно: пришёл кадр управлять, ничего не зная про специфику управляемой области. Вот это, собственно, и есть основная мировая проблема нашего времени.
Если бы вы хоть что-то почитали про програзм (Брукса, Ди Марко), вы бы узнали, что это высокорисковая область, где сроки имеют распределение с длинными хвостами. Соответственно, 99% срок можно дать только после того, как работа будет сделана. А до этого ошибка примерно раза в 3 в обе стороны.
Это только если на написание кода закладывать 80% времени. А если на код 20%, а остальное это тестирование, документация и так далее - то даже при увеличении времени на кодирование втрое вполне можно уложиться в те же сроки. Раз уж тут проектировщиков вспомнили, так у них как раз планируется время на многоэтапное согласование, получение разрешительной документации, подключение к коммунальным сетям (вода, канализация, газ, электричество,…) и много всего еще, время на «укладку кирпичей» это лишь один из этапов проекта.
А никто на написание кода не закладывает 80% времени. Набор код занимает буквально десяток минут, как правило.
Тогда главное отличие с архитекторами в том, что они заранее оценивают реализуемость проекта - например, не делают парящий фундамент... а в программном проекте еще и не такое встречается :)
В программном проекте тоже заранее оценивают.
Если вы все заранее оцениваете, откуда у вас ошибка по срокам в 3 раза?
Реализуемость и сроки -- это принципиально разные вещи. Вопрос реализуемости стоит в исследовательских задачах (и, кстати, в исследованиях негативный ответ типа "метод не работает, спасибо, все расходимся" принимается как велидный и в какой-то мере успешный исход). Вопрос сроков -- это уже инженерия. И я призываю отделять одно от другого, иначи и одно не до конца выяснено, и другое криво реализовано.
Так все же почему у вас в реализуемых проектах ошибка по срокам в три раза? Одно дело, когда заранее не известна реализуемость этапов - доказать невозможность реализации может требовать сколько угодно времени, но если все этапы реализуемы, тогда и путь реализации заранее известен, следовательно, и время на реализацию поддается оценке. Тем более, если, как вы пишите, время реализации на многократно превышает время написания кода, так что даже ошибка в разы по срокам написания кода ни на что не влияет. Получается, дело вовсе не в программировании, а проблема вообще с проектом как таковым.
Вы пишите так как будто на этапе планирования вы уже знаете все конкретные алгоритмы и архитектуру. В реальности это возможно если только вы делали очень похожий проект, и новый имеет минимальную новизну. Если так то можно считать, что у вас уже есть рабочий код, который надо немного допилить и можно расходится.
Фундаментальная проблема в том, что "гладко было на бумаге но забыли про овраги". Предпосылки рушатся, алгоритмы взрываются от того что данных встало в 10 раз больше, архитектура не продумана и начинает буквально "сыпаться", ТЗ содержит ошибки и т.д.
архитектура не продумана
О том и речь, проблема с проектом. Архитектура программного проекта это как каркас здания, а программирование - отделка (в строительстве все аналогии найдутся, область буквально древняя). Конечно, когда на этапе отделки оказывается, что нет воды, света, канализации, связи и обогрева - даже отделку выполнить проблематично, не то что использовать помещения по назначению. Кодом проблемы проекта как такового не компенсировать.
Хорошие архитектуры "не приходят из космоса", это дитя опыта в конкретной предметной области, часто с первого раза не удачного.
Зачем беретесь, если заведомо знаете, что не можете выполнить проект? Сделайте внутренний или открытый проект, научитесь, а потом уже предлагайте сторонним заказчикам.
Это все просто крайние точки, реальный ландшафт сложнее. Гарантировать можно, если вы до этого делали практически тоже самое. И это если мы рассматриваем вопрос чисто с инженерной точки зрения. С точки зрения бизнеса, вы вполне можете понимать, что будет 3х, но обозначать 1х. В том числе из-за не совсем честных конкурентов.
Так все исполнители знают, что или «заведомо не могут» выполнить проект, или получат существенные трудности.
Но надо выполнить.
Я это объясняю с помощью Cynefin Framework https://en.wikipedia.org/wiki/Cynefin_framework, где проблемы разделяются на простые, усложненные, сложные и хаос. Простые полностью поддаются оценке сроков выполнения. Усложненные (complicated) не поддаются оценке сроков, но дают очевидный ответ на вопрос "реализуема ли задача при наличии неограниченных сроков и ресурсов". Complex не дает представления даже о том, может ли быть задача решена в принципе: требуются сложные эксперименты, чтобы дать ответ.
Отвечая на ваш вопрос: описанная вам задача явно complicated, и решающему ее не удалось адекватно разбить ее на простые.
решающему ее не удалось адекватно разбить ее на простые
Так и я о том - эта проблема началась гораздо раньше этапа программирования, еще ни строчки кода не было, а проблема была, и можно было уже по плану работ увидеть, что проект обречен. Аналогичное происходит порой и со строительными проектами, к примеру, так что ИТ специфики тут нет.
Оценка на то и оценка, чтобы быть приблизительной. Ну вот здесь такая точность обычна. Более точная оценка потребует много времени, поэтому нецелесообразно. Но в принципе можно давать и 100% точную оценку, когда работа уже сделана.
Набор код занимает буквально десяток минут, как правило.
Программист, который "набирает код за буквально десяток минут" — это примерно как та машинистка, которая "печатает 2000 знаков в минуту — правда, такая фигня получается!"
Представляете, так бывает. Я согласен с тем, что это неправильно. И клеймить меня каленым железом, ведь в жизни все должно происходить только правильно, верно?)))
Однако, многие команды рождаются, в силу внешних обстоятельств, на пустом месте. И у них есть два варианта - самим пройти путь и вырасти, либо загнуться. Ну либо пригласить внешнего консультанта (благо их полно) и понадеяться, что он все сделает как надо)
Да, у нас становление разработки и становление тим и техлидства прошло свой путь. Тернистый и с ошибками. Сейчас такая ситуация в компании уже уму не постижима. И все же так было. Мы учились, приглашали правильных (и не очень) людей, общались с коллегами, ездили по конфам, учились. И, знаете, вот мне не стыдно, что мы смогли вырасти, начиная оттуда, откуда начали. Ибо сразу готовые слаженные команды с клевым лидом из печки не пекутся.
Что же до сроков. Увы, сложная задача и правда сложна еще и тем, что в ней трудно адекватно рассчитать сроки. Только бизнесу каким-то образом сроки все же нужны. Ибо ему надо посчитать издержки. Это вечная проблема, она не только в ИТ-сфере. Такая битва льда и пламени)
Представляете, так бывает. Я согласен с тем, что это неправильно. И клеймить меня каленым железом, ведь в жизни все должно происходить только правильно, верно?)))
Это просто всеобщая беда нынешнего времени: деградация управления.
Увы, сложная задача и правда сложна еще и тем, что в ней трудно адекватно рассчитать сроки.
Оно не сложное, оно высокорисковое. В смысле, у вас всё просто, перекладывание JSON'ов, никаких мегаалгоритмов и т.д., просто внезапно выясняется, что нужно дописать там, там и там куски, здесь что-то сломалось и т.д. Поскольку программа — это просто максимально проработанное Т.З., предусмотреть на этапе постановки задачи (создания Т.З. на программу) эти вещи вы можете только с некоторой, далеко не 100%, вероятностью.
К нам, однажды, на работе пришел управлять вояка.. На работе у нас началась армия =)
Зачем так умнО ? :) " почитали про програзм (Брукса, Ди Марко), вы бы узнали, что это высокорисковая область " - ведь можно "потанцевать" :)
Мальчика "поставили", он "буднично раздал" и так же "буднично получил реакцию". А еще там у него HR-ша с правами CIO присутствует - изюминка :)
Дать себе отдохнуть. И с новыми силами в проект. Ибо на дохлой кобыле далеко не уедешь.
Последнее предложение столь же логично, сколько и ценнично...
Звучит как то: Эгегей, мустанги вы мои, не выгорайте, отдохнем и снова в путь!
Шопотом: А то если вы копыта откините, кто ж меня дотянет до места назначения.
Но статья интересная)
Спасибо) Некоторые истины просты до безобразия, но их нужно постичь. И работа - это вообще циничная история. Мы приходим и вкладываем свой труд, чтобы собственник получил прибыль. Вопрос лишь в том, как сделать нашу циничную историю комфортной и выгодной для обеих сторон. Рынок - он такой.
Про отдых - это отдельная большая тема. Я не стал ее тут разбирать, возможно стоит. Но многие люди в нашей стране правда не приучены отдыхать...
Сейчас трудно освоить какую-то область, чтобы потом этим кормиться хотя бы лет десять. Сужу по своему увлечению 3D-моделированием.
Ну есть же в ИТ сфере более стабильные отрасли.
Где технологии меняются медленно.
Например
1)Админить — Сети
2)Физика — Микроэлектроника( Схемотехник,Embedded...).
3)Математика — Data(Scientist, Analyst, Engineer ), Возможно ML
Про сети однозначно не соглашусь. Сетевик сейчас и 15 лет назад - это две большие разницы.
Тут уже теплее. Я не схемотехник, потому спорить не стану. Хотя пример того же wi-fi6 хорошо показывает, как из эфира сегодня могут выжать то, что еще десять лет назад казалось фантастикой. И многое там завязано на новые разработки в области антенн, плюс математика кодирования сигнала.
А вот ML - одна из самых динамичных областей. Это видно даже по уровню нейросетей, которые сейчас творят научные чудеса.
т.е. там за последние 60 лет придумали что-то кроме numpy(или его более молодых аналогов)? ну действительно же - мало что меняется в ML, просто то что было начали использовать в разных отраслях.
в 1 и 2 для большинства работников области действительно мало что меняется - потому что они никогда этих технологий в живую и не пощупают в виду малораспространнености дорогих железок и вакантных мест на необходимые навыки
ML чрезвычайно динамичен. Помню, начинал использовать ML для изображений лет 15-20 назад — свёрточных нейронных сетей не было. Точнее, для изображений они существовали лишь теоретически, а на практике были вычислительно очень тяжёлыми. Архитектуры сетей, программное обеспечение, и подходы к их обучению были неразвиты.
Изображения надо было обрабатывать, но практичных методов не было никаких. Лично мне приходилось изобретать свёрточные деревья решений, свёрточные решающие джунгли, и прочие методы, чтобы хоть как-то выкрутиться.
Потом, как гром среди ясного неба грянул GPGPU (2006 год) — графические процессоры были доработаны, чтобы производить произвольные вычисления. Через пару лет после этого пошло массовое практическое применение нейросетей. В результате такого массового применения вскрылась инфантильность теории (например, широкое распространение активации ReLU случилось лишь в 2011 году, до этого исследователи с умным видом твердили о «теоретической оптимальности» сигмоида). Позже, в 2016-м году, появились специализированные вычислители для нейросетей.
Архитектуры типа Transformer (которые используются в ChatGPT) появились в 2017-году.
Каждые пару лет появляются новые методы обучения, семплирования, и прочее. Новые алгоритмы, новые фреймворки. И это не «одни и те же яйца, только сбоку» — там разные подходы. TensorFlow — 2015-й год, PyTorch — 2016, CoreML — 2017.
В итоге в области ML знания и умения превращаются в тыкву примерно за 5 лет.
Дополню: AdaBoost — 1995-й год. Перевернул ML и получил премию Гёделя. О каких 60-ти годах идёт речь?
https://en.wikipedia.org/wiki/Timeline_of_machine_learning
о таких 60ти годах.
вы говорите об инструментах, я говорю об области знаний.
на примере сетей - TCP/IP не менялось туеву хучу лет, хотя инструменты менялись постоянно.
так то и в других областях - к примеру водителям не приходится ездить на одной машине всю жизнь.
Ну, во-первых область знаний в современном мире неотделима от инструментов и развития этих инструментов. Кто такие программисты без компьютеров, или астрономы без телескопов?
А, во-вторых, машинное обучение именно как область знаний полностью меняется каждые лет 15. Если взять современного ML-специалиста (специалиста именно в области знаний, а не в области инструментов), и послать его лет на 30 назад, то он со своими знаниями (деревья решений, решающие леса, бустинг, подходы feature engineering, понимание случайных корреляций и шорткатов) положит на лопатки методы 30-летней давности и всех специалистов того времени, даже с учётом вычислительных возможностей тех времён.
Это как шахматы. Современные шахматы известны с 15-го века. Но если современного профессионального шахматиста отправить в прошлое (лет на 50 назад), то он порвёт всех. Это не моё мнение, это как раз мнение шахматистов. Всё дело в том, что именно компьютеры с их вычислительной мощью «наконец-то научили шахматистов играть».
Про сети однозначно не соглашусь. Сетевик сейчас и 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 профессия меняется медленнее(или чуть медленнее) чем разработка.
Отвечу за ту область, в которой понимаю. Радио.
Что принципиально изменилось в Радио за последние 15 лет? Революционные открытия? Инновационные материалы антенн? Может физика поменялась? Нет, ничего этого не было. Но почему сейчас спецы по радиосвязи другие?
Математика. Мы давно умеем кодировать сигналы. И можем делать это по очень сложным алгоритмам. Раньше подобные вычисления требовали серьезной техники. Но сейчас уровень микропроцессоров разогнался так, что любой роутер умнее многих компов пятнадцать лет назад. Он может позволить себе сложную математику на борту. И разработчикам приходится ее учить. Сама математика была, просто раньше потребности в ней не было.
Элементная база. Когда-то позволить себе сложные микропроцессоры или антенны могли единичные дорогущие гаджеты. Сейчас тот же роутер умеет beamforming. Технология не нова, но пока в связи использовали омни, да направленные антенны спецов по ней шибко и не было. Сейчас они нужны.
Смежные области. Если мы говорим про вай-фай или сотовую связь, то нормальный специалист должен хоть что-то понимать в проводных сетях. Когда я только начинал работу в СС в далеком 2006м, я понятия не имел что такое vlan. Ибо этим занимался наш сетевик и все БС жили, по сути, в локальной сети коммутатора. Когда к каждой БС подходит своя оптика или релейка у которой второй конец упирается в коммутатор, жизнь хороша. Но когда между коммутатором и БС может оказаться черти-че, вы должны осознавать как это черти-че работает.
Но! Раньше базовая станция - это шкаф с оборудованием. Он стоит на земле, антенны сверху. Надо уметь дотянуть до нее кабель, разделать разъемы, нигде не накосячить, проверить КСВ. Сейчас это отходит в прошлое. БС имеет внешний юнит, который крепится прямо за антенной. Соединение с антенной - заводским кабелем-джампером. Сигнал наверх по оптике. Умение разделать кабель стало не так критично (хотя навык полезный).
Вот и получается. Физика не поменялась. Фундаментальных открытий не сделано. А профессия изменилась.
> Сетевик:
> 1)Знание стеков протоколов ТСР/IP
IPv6 вышел из младенчества и где-то перешёл в большинство. Дополняется множеством технологий типа SLAAC.
> 2)Задачи с коммутаторами D-Link и Huawei Cisco
Не помню, когда в последний раз про D-Link слышал и когда видел Cisco. Дома TP-Link, Asus, Microtik, ещё какие-то. На работе по-разному, но чаще Juniper, Extreme Networks, ещё разные. На ряде задач Arista. Huawei вспоминается очень вскользь в связи с некоторыми специфическими сетями.
На прошлом проекте вообще принципиально использовались «off-the-shelf servers» (так народ прямым текстом и называл) + Linux + DPDK. И это не частная прихоть, а стандарт — почитайте спеки 5G от 3GPP, там всё считай заточено на этот подход. Делать железяки с собственным дизайном, кроме аналоговой радиочасти (ЦАП/АЦП и антенны) — самоубийц нет. А кто там посредине эти потоки через себя гоняет — никого не волнует.
> 3)модели OSI, принципов IP коммутации и маршрутизации
OSI уже 100500 лет это только учебная схема, на которой учатся понимать слоёную структуру и после этого переходят к практике.
IP коммутация — вы видели тот же DPDK и какими управляющими тулзами он сопровождается? Там фактически свой раутинг со своими протоколами. Особенно когда это всё ещё в кубере.
Расширения сетевого управления для кубера своими CNI — это отдельный мир, сравнимый по сложности со всем TCP/IP вместе взятым.
Ну и туннелирование всего этого со своими особенностями.
А SDN? Тоже фактически отдельный мир (пересекающийся с предыдущим).
> 4)Знание построения VPN соединений.
Просто VPN это сейчас база. А вот так чтобы при этом правильные файрволлы, кастомные подсети и всё такое…
Сопутствующее: время раздавать? (критически важная, хоть и мелкая задача)
До ~2005 кроме NTP вариантов не знали. Сейчас PTP чаще встретишь в большом мире, чем NTP. Вчера вот разбирали, одна конкретная софтина его неверно понимала…
Ну и так далее.
То есть и сети сейчас это совсем не те сети, что 15 лет назад, или по когда там вы список рисовали.
У вас есть какие то идеалы, по какой то причине вы им перестали соответствовать, усе привет, вы в яме. Случится это может с кем угодно и где угодно.
> И выгорание – вполне себе обычное дело в этой среде. Все мы выгораем. Это надо принять.
нет не надо, выгорание часто бывает просто от нарушения баланса положительных и отрицательных эмоций получаемых от работы, если заставить хорошую лошадь ходить на привязи по кругу, типа как было на шахте, то долго не протянет даже при хорошем корме, если проект не интересен или вообще работа плохо организована, отдых мало что изменит, современное программирование становится все более промышленным, меньше собственного кода, больше интеграции, porting, и т.п., к сожалению это изменить невозможно, интересных самостоятельных проектов становится меньше,
вывод простой - либо надо все больше усилий для нахождения проектов которые Вам интересны, либо вообще уходить в новые области типа bioinformatics и пр., принятие выгорания как нормы, и продажа собственных мозгов даже за хорошие деньги себя не оправдывает
дочитал статью и выгорел )
Какое-то время назад — тут давали очень хорошее и конструктивное определение выгорания: истощение ресурсов психики, возникающее вследствие эмоциональной привязанности человека к своей (сложной, не гарантирующей результат) деятельности и хронического нарушения баланса работа/отдых.
Из этого определения следуют два очень важных вывода. Во-первых, вы не сможете выгореть если будете копать землю лопатой. Потому что в какой-то момент вы физически устанете, у вас будет все болеть — и на лопату без отвращения смотреть не сможете, а пойдете отдыхать от этой работы. Аналогично и все другие рабочие специальности — устать вы там можете, травму можете получить, а выгореть — не получится. Потому что нет эмоционального компонента. И возможности работать за пределами смены тоже обычно нет.
Второй вывод — выгорание бывает не только у программистов. Также со свистом горят врачи, горят учителя, горят творческие работники. Потому что есть эмоциональный компонент (спасать людей, учить людей, заниматься творчеством — это мощнейшие эмоциональные стимулы), есть элемент неподконтрольной неопределенности (люди несмотря на лечение умирают, ученики не учатся, книги не пишутся), и нет предохранителя в виде физической усталости. Вам должно стать уже совсем-совсем худо, чтобы вы не смогли выписать рецепт, заполнить классный журнал или нажать кнопки на компьютере.
А дальше начинается вот такая штопорная спираль: не получается — работаем больше — устаем (эффективность падает) — ощущаем чувство вины перед собой/работой/людьми — работаем больше — устаем больше — еще больше работаем — и так пока организм не начнет отказывать.
Теперь о том, как с этим бороться. Устранить эмоциональный компонент — не получится. Устранить случайность и неопределенность в результате — тоже не получится. Остается только одно — знать причины выгорания, уметь заниматься само- и взаимодиагностикой. А руководителям — не радоваться что программисты сидят допоздна, а организовывать нормальный режим труда и отдыха (хотя это абсолютно противоречит идеям «эффективного менеджмента»). С другой стороны, надо понимать что определенным видам бизнеса выгоднее выжечь разработчиков в обмен на продукт сейчас, а что будет завтра — их не волнует. Бегите оттуда… Бегите…
Хороший комментарий, плюсую.
Добавлю только один момент. Часто сотрудники от руководителя ждут какой-то заботы, защиты, понимания. Честно скажу - мне это понятно. Я в своей работе всегда старался создать подчиненным комфортные условия и все общение с руководством выше пропускать через себя. Если где-то кто-то накосячил, не должны бигбоссы обычного программера по столу мордой возить. Меня должны, а я дальше сам оргмероприятия проведу. Это правильно как с точки зрения бигбоссов (одна точка входа и один ответственный), так и с точки зрения сотрудника.
И все же работая по найму надо держать в голове, что вы приносите пользу, обменивате свой труд на деньги. Это не междусобойчик и дружба, это сделка. Потому надо внимательно условия сделки смотреть.
Действительно, сделка может быть весьма суровой. Тут глупо жаловаться. Если не получается условия сделки сместить в свою пользу - штош... Либо принимать, либо уходить.
Но по моим наблюдениям, команды, где все как-то по-человечески добиваются куда большего успеха, чем "конвейер из людей".
И да, стабильная команда — работающая в нормальном режиме на долгом промежутке времени всегда даст больше годного. Но это же надо уметь вдолгую играть, чем бизнес (впрочем, он — скорее отражение политики в этом вопросе) редко занимается. В условиях неопределенности, ему проще зарезать корову и продать мясо, чем кормить, поить, убирать и доить несколько лет в будущем…
Стратегия вин-вин эффективна именно вдолгую. Вопрос тут скорее формулируется так. Бигбосс, к которому вы идете работать строит что-то большое и глобальное? Он понимает, где хотел бы оказаться лет через пять-десять? Или у него изначально задача срубить бабла и свалить?
Обе стратегии имеют место быть. Просто во втором случае не стоит мысленно связывать себя с этой компанией на годы. А если для вас важно работать долго на одном месте - идти к тем, кто играет вдолгую.
Но тут важный момент. В больших серьезных компаниях и время течет чуть медленнее. Там все не быстро - рост, развитие, повышение зп. Ибо стабильность не любит резких движений. При прочих равных там дольше делать карьеру.
Впрочем, из любого правила бывают исключения.
"Потому что нет эмоционального компонента."
Есть. Может это личное, но есть. Закладывающий уши ор оглашенного "Я работаю. Я такой невероятный труженник. Я такая звезда. 24\7 работаю."
Ты ж не один на работе, с лопатой или клавиатурой.
С лопатой тоже можно выгореть на раз-два. Болезнь уже давно описана - золотая лихорадка. И, лихорадка, если кто не задумывался, это как раз высокая температура, когда организм сам себя заживо сжигает.
Конечно, золотоискатель это особый случай, в чем-то ближе к работе програмиста, чем "полтора землекопа роют полтора метра траншеи за полтора часа". Даром, что мыть золото лет двести назад можно было не зная ни одной буквы.
Возможно, суть даже не в эмоциональной привязанности, а в том, что физическая усталость очевидна, ее легко определить и сложно преодолеть без отдыха, а усталость мозга можно спутать с ленью и, преодолевая, исчерпать все резервы. И заказчику не всякому объяснишь, т.к. он, может, и не доходил никогда до такого уровня сосредоточения растянутого во времени.
Мне гораздо интереснее читать про решение физиологических проблем: спины, шеи, запястья. Но охотно верю, что кому-то хочется найти единомышленников в нудности. Я встречал людей, которым действительно в радость писать под копирку (это на олдовском), и им, возможно, учить все это новое очень выгорательно. Мне кажется, что это обычное желание человека пожалеть себя. Не деньги, так скука, а нет - болячки или комфорт. Человек, который успокоился не станет работать. Не отрицаю выгорания, просто мне кажется оно лечится кончившимися деньгами. Или стартапом..
Ооооо, нет!) Я уже понял, что нужна статья по мотивации персонала и сделаю ее в ближайшее время. Если коротко суть - у каждого человека есть своя ведущая мотивация. И это далеко не всегда деньги. Деньги тоже важны, хотя клинические примеры, когда гениальный программист трудится над интересной задачей за гроши тоже встречаются.
И все-таки не все решается именно деньгами. Определить ведущую мотивацию сотрудника - важнейшая задача руководителя. Ибо без этого можно его кормить огромными зарплатами и удивляться - а че глаза-то не горят???)
Я не видел гениев за гроши. Нужно быть очень глупым, чтобы не платить достойных денег таланту. Но это отдельная тема. Я не про достойную оплату совсем. Я про желание работать (горящие глаза в аджайле - нонсенс, в который я не верю). Нет ничего проще, чем оставить работу на месяц-год-пять, на сколько позволят накопления, которые часто есть у тружеников табуретки и клавиатуры, и желание писать какой-угодно тупой код вернется. Просто осознание разницы вернет желание.
> Определить ведущую мотивацию сотрудника - важнейшая задача руководителя.
Олег, Вы не переоцениваете свои силы?
Для этого надо min понимать людей, что не просто, если напишете статью по предмету, конечно будет интересно.
Из личного опыта, который у всех разный - по серьезному единственное чем можно мотивировать своих сотрудников в трудных ситуациях это личным примером, это после 50+ лет в программировании, в том числе работы с сильными командами
А кто ж меня знает?) В душе я для себя самый лучший и умный) Но по факту я понимаю, что это не так. Вот, статьи пишу, стараюсь критику поймать, вещи, которые задуматься заставят)
Минимально понимать людей можно и нужно. И даже этого минимума я много где не вижу. Хороший руководитель - это еще и психолог.
Насчет личного примера - он важен. Конечно, сотрудники должны уважать своего руководителя. Он должен быть не нахлебником, а лидером. И все же горящий Данко, вынувший из груди сердце, сможет мотивировать лишь отдельных людей. Остальным нужны иные персонажи)
Стать идеалом для всех невозможно. Отсюда вывод. Вдохновлять всех личным примером, набрав команду тех, кого ваш пример вдохновляет. Либо искать ключики, разные ключики)
проекты разные бывают, организации тоже отличаются сильно, соответственно требования к командам, бывает что членов семьи не совсем понимаешь, про мотивацию сотрудников это сложнее, по серьезному от адекватного руководителя требуются качества типа wolf pack alpha, в том числе никогда не обманывать своих сотрудников, что иногда бывает сложно, т.к. знаешь больше
ps
если что пишите в личку, занимался в основном сетями и real time
Статья вредная, но автор пишет на столько хорошо и убедительно, что заслуживает плюса.
Во-первых, «зелёный змий» ни разу не спасает. Да, «выпил с утра – весь день свободен», но это только перекладывает задачи на завтра.
Во-вторых, разработчику не дают погрузиться в задачу. Пример: только погрузился, разогнался, как звонок – исправь в коде трёхлетней давности то-то и то-то. Это как если бы условного крановщика попросили бы: «Вась, слезай с крана и дуй в корпус Б – теперь ты сварщик». Смешно? А в IT такое каждый день по нескольку раз.
В-третьих, господство Agile приводит к тому, что ТЗ меняется каждый день и изменения ТЗ нигде не фиксируются. Пример: типичный звонок начальства:
А это что за х..ня?
Так Вы же сами об этой фиче месяц назад просили!
Нет! Не! Просил! Переделать!
(месяц спустя, тот же начальник)
А та фича, о которой мы говорили два месяца назад, почему не реализована???
… (разработчик ищет на полу свою челюсть)
Вот из всего этого и вытекает выгорание.
Ох, чует моё сердце, сейчас отхвачу минусов по самое нехочу, но это моё мнение и от него не отступлюсь.
Да, многозадачность - серьезный угнетающий фактор. Я его в явном виде не учел.
Насчет алкоголя - я не про "утром выпил". Все же народ у нас синярит не настолько отбито. Но пятничный забух с переходом на выходные - обычное дело. И я не говорю, что это нормальный и адекватный способ. Но им пользуются.
Что же касается меняющихся задач - это вообще бич. Тоже помню, как с командой сидели и вспоминали, зачем мы тут галку сделали))) Решается документированием задач. Да, это бюрократия, но без нее никуда.
На самом деле, если к этому относиться как "ТЗ крутится, зарплата капает" - то можно выгорать меньше, чем если болеть душой за каждый проект. Но надо делать это умеючи, иначе вас спалят, что вы не из "компания семья, вовлечённость наше всё" и выгонят раньше, чем доездят выгоревших.
Но да, для этого надо довольно хорошо самому выстраивать баланс "работа-жизнь". Работодатель (особенно на просторах СНГ) за вас это делать не будет, скорее всего.
типичный звонок начальства
Есть проблема — создавайте тикет в багтрекере, нет тикета — идите в баню, начальник. А телефон сломался и нового на складе нет.
Справедливости ради, я инженером в конструкторском отделе тоже испытывал каждый день. Но поправляло, что когда ты занят конкретным делом, то ты просто говоришь всем "Я сейчас занят такой-то деталью в такой-то сборке. Как освобожусь - посмотрю." и тебя никто не смеет одёрнуть. Ни один начальник не решился настаивать до последнего, даже если работа срочная.
И тут тоже приходится доделывать работу за других. Часто это требует практически переделывать работу за другого, но вынужден вручную исправлять косяки. А когда на испытательном тебя садили за чужой компьютер, и каждого она настроена под себя, то это превращается в незабываемый опыт, где такие миграции чуть ли не каждые 2 дня. Позже уже по опыту понял, что проще приобрести внешний SSD, настроить на нём ОС и софт под себя, и работать только с него, вне зависимости с какой машины ты запущен - тем более SSD большого объема нынче стоят не так дорого, как раньше.
Просто крановщик, как и водитель, оператор ЧПУ, токарь, слесарь, моляр, и прочие спецы видят результат своей работы в процессе прямо перед собой и их никто не пытается держать в невиденье. В IT (я работал программистом, знаю какого это) и часто у автоматчиков (АСУ ТП, тоже там работал, почерпнул проект, над которым сейчас работаю) такое случается с регулярностью.
Есть золотое правило: "На каждого программиста должно приходится не менее 2 тестировщиков", но кто же в наше время в контрактных конторах будет уделять внимание тестированию вообще? Вот и получается, что людям помимо того, что работать приходится с "чужими заслугами", так ещё делать фактически двойную работу. А когда тебя ещё дёргают внерабочее время, и никто тебе за такие "визиты" не платит, то тут ни то что выгоришь, а уйдёшь к первому встречному, лишь бы оставил в покое.
Переделать!
Штош, бизнес - требования иногда меняются. Завели таску в трекере, объединили с предыдущей. В предыдущей таске зафиксирован хеш коммита, которым запилили изменение? Сделали, не думая, revert, пошли пить смузи.
Все верно написано. У меня было несколько раз выгорание
От перенапряжения. В огромном проекте по миграции на новый карточный процессинг забыли небольшую деталь: собственно программу миграции. Я работал несколько месяцев в режиме нонстоп и получил премию в 500 баксов. От этого выгорания отходил лет 5. Прошло само но не конца.
От несовпадения ожидания и реальности. Мне нравится руководить разработчиками а пришлось заниматься совсем другими более абстрактными делами.
На все это накладывается неумение отдыхать и недостаток времени на отдых. Я понимаю, что просто пешая прогулка километров на 5 поможет восстановить силы, но не могу заставить себя, а отдых на диване никак не помогает.
Для борьбы использую следующую тактику: начинаю делать не те дела, которые нужно, а то что мне нравится делать, после того как разработаюсь, переключаюсь на нужные дела.
> Для борьбы использую следующую тактику: начинаю делать не те дела, которые нужно, а то что мне нравится делать, после того как разработаюсь, переключаюсь на нужные дела.
т.е. работа на адреналине взятом взаймы у более интересного проекта, как и любой самообман долго не работает, типа вообще интерес пройдет, творческие способности надо растить, а не тратить на лабуду, хотя дело глубоко личное разумеется
Модное слово, мне кажется его используют слишком часто и не по назначению. Слишком часто что бы обращать на это внимание. Особенно странно бывает слышать про выгорание от людей работающих пару лет в профессии, это не выгорание - лень, завышенные ожидания, стандартные проблемы новичка, после малых успехов видеть себя архитектором через год и потом "выгореть" когда станет понятен масштаб.
Мне больше нравится слово "усталость". Устают в ИТ от разного, чаще, мне кажется от обычных человеческих взаимоотношений чем от необходимости постоянного обучения или решать сложные задачи.
Хороший пример про Юлю в отпуске. Очень важно отдыхать: вечером после работы, в выходные, не забывать про отпуска. Да, можно поработать и 16 часов в день, и без выходных, и подключиться с пляжа поднимать продакшн. Но это должно быть исключением, а не правилом. Иначе ни кому не хватит сил и он устанет. Устанет, даже если делает любимое дело для души. Когда все вокруг привыкнут и решат что это норма и они такие крутые менеджеры. Знаю это, как тот самый человек, который заражает коллег мотивацией работать и который уже уходил в отпуск на полгода.
На мой взгляд главная причина выгорания в отсутствии результатов реальных работы или же ощущаемое несоответствие вложенных усилий и результатов, для человека важно ощущать такой баланс, вероятно это какая-то очень древняя эволюционно обусловленная потребность. Например я 3 года работал на проекте, а потом его признали неудачным и закрыли, потом еще 2 года работал на отличном проекте с отличной командой, но деньги кончились и проект закрыли.
Как и у любой комплексной проблемы причины тоже комплексные. Горят даже на успешных проектах с хорошими деньгами и мотивацией. Встречал я таких людей. Все прет, а глаза потухшие.
Но если усилий много, а на выходе пшик - это демотивирует, спорить глупо.
У всех по-разному. Я могу работать на каком угодно проекте, если за это платят деньги. Что с ним дальше будет — проблема уже не моя, а менеджеров. Мне на поесть хватило, квартплату заплатил — ну и ок. Вернее, хотелось бы побольше, конечно, чтобы я струны на гитаре менял хотя бы раз в квартал, ну уж, как есть — и то хорошо. Опять работу менять — это опять стресс, опять поход по врачам, опять нужно через силу засесть за учебники.
хотелось бы побольше, конечно, чтобы я струны на гитаре менял хотя бы раз в квартал
Судя по https://www.muztorg.ru/category/struny новый комплект струн это максимум один поход в кабак. У вас всё настолько плохо?
От месяца к месяцу по-разному. На повремёнке сижу. Чуть расслабился или задач не поставили — уже надо внимательно следить за расходами. С весны накоплений не откладывал, всё только в минус получается, ещё и продукты подорожали. А в кабаки я не хожу, давно уж бросил это занятие. Со струнами, конечно, несколько преувеличил, я их не меняю, потому что устраивают, но если бы я готов был не считая потратить 500 рублей, то может и поменял бы по прихоти. А вот купить прикольный ремень для гитары за 1000 — это мне пока перебор, потому что ради прикола тысячу выкладывать не хочу. И то же с симпатичным чёрным выключателем для света за 1200. Есть же работающий, чего его менять-то.
Речь-то изначально про то, что важен результат. Для меня результат — это зарплата. Я не Стив Джобс, новые устройства не изобретаю, я сайтики клепаю, в них обычно ничего нового не придумывают, только по-разному компонуют уже имеющееся. Может, я уже в выгорании, просто не заметил? Год назад я из полугодового отпуска вышел, в который уходил, потому что работа совсем задолбала и здоровье пошатнулось. Но вроде ж отдохнул. Правда, если б не наш президент, я бы отдохнул подольше, почитал бы учебники. А сейчас вообще нет сил что-то читать после работы, поэтому мне будет тяжело новую работу искать — сперва придётся уйти со старой, а у меня запасов месяца на два, не больше.
Выгорание, нет сил на учёбу, новая пачка струн как праздник, как же это знакомо! Я собрался и поменял работу. В принципе, по деньгам ничего не изменилось, но работать стало гораздо интереснее. У меня был страх, страх потери дохода. Сейчас я стал немного увереннее :)
Может быть у вас выгорание как раз из-за нестабильного заработка? Типа то густо, то пусто, вот оно и действует на нервы потихоньку.
С доходом так стало недавно, а учиться ломает уже несколько лет. Работу-то я не так уж давно сменил, меньше года прошло. Когда мне было лет 25, всё было интересно, я что-то придумывал, пописывал для себя всякие придумки, но я тогда не работал программистом. Потом это стало работой и больше не хочется этим заниматься помимо работы. Может, это просто возраст.
Эту проблему (отчуждения труда) описывали лет пятдесят тому назад, тогда она считалась некоторыми чуть ли не основной причиной вызывающей психические расстройства у работников.
Идёт программист по рынку труда, видит - стартап появился. Ну, он устроился в него и сгорел...
Начать надо с того что не использовать синтетические, искусственные термины, коим является "выгорание" и эта статья познакомила меня еще с одним - техностресс. Все это не помогает, а запутывает и уводит от сути. Правильно: усталость. Но усталость не физическая, а психологическая. Именно дедуктивный разбор с использованием простых, понятных определений поможет понять что происходит и как с этим бороться.
Я догадываюсь что человеку или что может быть более верно - отдельным людям противопоказан 1. сам метод ведения какой-либо деятельности, в виде неподвижного сидения и наблюдения различных картин - достаточно абстрагироваться от "компьютера", заменив его на допустим, сложный пульт управления. 2. Монотонная деятельность (ответы я уверен есть в исследовании производственной деятельности у станков и конвееров) 3. Ведение подобной деятельности под принуждением (финансовый прессинг, страх потери дохода, страх в итоге оказаться на улице). — Внимательное рассмотрение всего лишь 3х этих обстоятельств уже дает почву для размышления.
И наконец, совершенно отдельный вид психологический усталости (ветвь), но связанной не с монотонной деятельностью у сложного "пульта" под принуждением, а связанный с грузом ответственности (своего рода тоже постоянный прессинг страха). Понятно, что человек постоянно навязчиво испытывающий страх неудачи стремится избавиться от неприятных обстоятельств, сбежать, (уволиться), прекратить стрессовую ситуацию.
Вот что есть названное словом "выгорание". Это психологическая усталость, вызванная статической неподвижностью, сопровождаемая одним и тем же монотонным действием под принуждением (страхом) и еще вдовесок заряженная страхом порожденным ответственностью за неудачу. Разумеется, человек начинает неосознанно избегать негативных обстоятельств, начинает блуждать, только бы не возвращаться к источнику стресса. И это, между прочим и есть так называемая "прокрастинация", её причина.
Начать надо с того что не использовать синтетические, искусственные термины, коим является "выгорание" и эта статья познакомила меня еще с одним - техностресс. Все это не помогает, а запутывает и уводит от сути. Правильно: усталость.
Выгорание и усталость - очень разные вещи. Одно из важных отличий - при усталости отдых полностью снимает проблему, а при выгорании - никак. Втррое важное отличие - при усталости не теряется интерес к жизни. При выгорании все становится по барабану.
И основная причина выгорания, каа мне представляется, это постоянное несоответствие ожиданий или желаний с одной стороны и достигнутого результата с другой, причем исключительно в худшую сторону. Тут, естественно, и усталость может рядом крутиться, например, когда следуешь путем "надо еще больше работать", а вместо ожидаемого праздника жизни в награду получаешь одну лишь только усталость. При этом формально поставленная цель может быть даже достигнута (проект закончен, деньги получены), но ожидаемой радости оно почему-то не приносит.
Одно из важных отличий — при усталости отдых полностью снимает проблему, а при выгорании — никак.
Отдых великолепно снимает проблему.
Увольняешься, полгода — год пинаешь балду и снова как новенький.
Что-то мне подсказывает, что смысл вполне конкретного понятия выгорание размывается так же, как уже размылся смысл понятия депрессия. Человеку грустно - "У меня депрессия! Человек подустал - "У меня выгорание!"
Если у человека реально выгорание, он уже не может выкарабкаться сам, просто пиная балду (срок не имеет значения). Ему нужна как минимум серьезная психологическая поддержка. Лучше со стороны нормального специалиста, но хотя бы со стороны близких людей.
Не говоря уже о такой мелочи, как невозможность для многих пинать балду полгода без существенных потерь в социальном статусе и квалификации, что весьма часто способствует не выходу из выгорания, а скорее к дальнейшему погружению в него. Или (в случае счастливого исцеления при наличии какой-никакой помощи) закладывает фундамент для нового выгорания.
Люди разные. И ситуации разные. Вы описываете совсем уж клинику. Но человек - существо весьма адаптивное. И многие вещи может преодолеть сам. Существует множество болезней, где без помощи хорошего врача не обойтись. И все же все мы болеем простудой или гриппом, при которых нужна лишь неделя покоя и мы как новенькие) А вот если грипп переносить на ногах... то тоже может ничего не случиться. А может потребоваться помощь специалистов.
Если у человека реально выгорание, он уже не может выкарабкаться сам, просто пиная балду (срок не имеет значения).
Не нужно смешивать выгорание и клиническую депрессию, это разные вещи.
Ему нужна как минимум серьезная психологическая поддержка.
Приведите авторитетный источник для этого утверждения.
Не говоря уже о такой мелочи, как невозможность для многих пинать балду полгода без существенных потерь в социальном статусе и квалификации,
Для поддержания квалификации во время отдыха открыт весь опенсорс мира, а для поддержания социального статуса существует толстая финансовая подушка.
Не нужно смешивать выгорание и клиническую депрессию, это разные вещи.
Разные, там и механизм формирования разный (хотя часть симптомов схожа), и лечение сильно отличается. Но просто пиная балду не выкарабкаться ни из одного, ни из другого состояния.
Приведите авторитетный источник для этого утверждения.
Это утверждение - эмпирический опыт множестаа человек. Психологическая поддержка хотя бы со стороны близких крайне необходима (а вот близкие часто вместо этой самой поддержки как раз начинают "кончай фигней страдать, возьми себя в руки и работай больше").
Для поддержания квалификации во время отдыха открыт весь опенсорс мира,
Странные у вас представления о процессе пинания балды. Да и в условиях выхода из выгорания не всегда приемлемое занятие.
а для поддержания социального статуса существует толстая финансовая подушка.
Социальный статус определяется не только финансовыми моментами. Да и самой толстой подушки на момент выгорания у пациента может не оказаться по разным причинам (например, многие успевают выгореть толком не заработав, зато успев повесить себе на шею ипотеку и еще пару кредитов).
Странные у вас представления о процессе пинания балды. Да и в условиях выхода из выгорания не всегда приемлемое занятие.
В процессе пинания балды совершенно нормально часть освободившегося времени посвятить любимым занятиям. Ну, а если человека в IT привлекают исключительно деньги и он выгорает от одной только мысли об условном программировании, то такой человек не заслуживает ни капли сочуствия. Может хоть дотла выгорать, такого не жалко.
Социальный статус определяется не только финансовыми моментами.
Финансовый момент позволяет купить всё остальное.
Да и самой толстой подушки на момент выгорания у пациента может не оказаться по разным причинам
Лучше быть молодым, здоровым и богатым, чем старым, больным и бедным.
Финансовый момент позволяет купить всё остальное
Заблуждение. Финансовый момент облегчает получение всего остального, но даже с финансами потребуется время и некоторое количество работы (возможно, даже очень большое и в общем-то без гарантий). В частности, "всегда есть рыба покрупнее", а потому ваш финансовый момент может внезапно уступить более мощному финансовому моменту.
Лучше быть молодым, здоровым и богатым, чем старым, больным и бедным.
Иногда богатым быть очень вредно для здоровья. Молодым и здоровым тоже, как ни странно оно звучит. Да и не следует забывать, что молодость - это не навсегда.
Одно из важных отличий — при усталости отдых полностью снимает проблему, а при выгорании — никак.Просто наивно думать, что можно два года пахать без выходных а потом отдохнуть недельку, и всё пройдет. Отдыхать надо постоянно — в идеале каждый день.
Сам работал 8 лет на заводе и пару раз "подгорел". Согласен только с одним пунктом
В IT больше необычных(странных, замкнутых и т.д.) людей, чем в других сферах - соответственно, у них больше необычных проблем (тараканов), Что и приводит к повышеному проценту выгораний
Мое мнение на этот счёт - айтишники, в большинстве случаев, достаточно молоды и получают хорошие деньги. Что позволяет им перейти из режима "не сдохнуть с голоду" в режим -"в чем смысл жизни и мое предназначение". Простого ответа на этот вопрос нет, да ещё и с ютуба-инстаграмма постоянно втирают, что нельзя просто перерабатывать воздух в метан и со2, А НУЖНО ДЕЛАТЬ ЧТО-ТО ПО-НАСТОЯЩЕМУ ВАЖНОЕ (для кого?почему? Делает ли кот или рыба что-то важное?) - отсюда и всяческие метания, сомнения и поиски.
На заводе денег платят сильно меньше и люди там в среднем проще, потому и горят не так как в айтишке, но тоже бывает.
Интересная статья на сайте Роспортебназдора про выгорание и профилактику: https://39.rospotrebnadzor.ru/content/emocionalnoe-vygoranie-i-ego-profilaktika. Там есть хорошие рекомендации по контролю стресса и предупреждению выгорания.
Кстати, "повышение уровня профессионального мастерства" как раз указывается как один ис способов борьбы с вызгоранием. Кто учится новому - реже выгорает.
По поводу эмоциональных стрессов, приводящий к выгоранию, слышал интересное утверждение, что основныи источником их являются "неразрешенные профессиональные конфликты"... Вот об этом стоит задуматься (и руководителю, и команде) и сосредоточится на выявлении и устранении таких факторов.
Прогеров надо мерять с подобными. Инженерами-разработчиками, конструкторами, научными работниками, учителями, врачами. У них часто бесконечный аврал, сложность работы намного выше, чем у программистов, а зп кратно ниже программистских.
1. Непрерывное обучение. Мы используем концепции CS, подавляющее большинство которых предложено к 70м; сейчас идеи Lisp переползают в мейнстримные языки, и все такие «ооо!». Датасотонизм и ML во многом матстат, матан и тервер, которые читают в универах по почти нестареющим учебникам. Получается, что мы вынуждены в основном изучать новые инструменты поверх старых концепций. Ну ок, книжная полочка в сортире у меня есть, хотя надо посмотреть, что если средний срок жизни инструмента год, может, не имеет смысла на него перескакивать? Может, это погоня за модой, круг которой замыкается раз в несколько лет?
2. Ответственность. Серьезно? За что ответственность? Может, вам за ответственность доплачивают или за сбой на проде могут оштрафовать и посадить? Более общо: насколько прибыль компании привязана к твоим задачам, можешь ли ты иметь процент, если твои усилия повысят прибыль компании, насколько значимы лично твои усилия в прибыли компании? В большинстве случаев ответ «никак/нет/нисколько», и к работе можно просто относиться как к месту, где ты с 9 до 6 закрываешь кем-то нарезанные или самостоятельно выбранные таски. Нужен в нерабочее время по причине, которая отсутствует в должностной инструкции? Пусть звонят, очень просят, дают двойной оклад и оплачивают такси. Если упадет прод после всех тестов, то с 6 до 9 это не твоя проблема. Работа не твой ребенок, и твоя жизнь не станет лучше, если ты начнешь болеть за нее душой.
3. Сроки и культ продуктивности. Мне дали сроки, задачу, я сижу и работаю. Честно работаю, без перерывов на мемасики, чтобы не загнаться — переключаюсь между задачами или иду покурить. Я работаю, а менеджер недоволен. Ну и хер с ним, в общем-то, особенно если протоколировать распорядок дня и отвлечения: митинги, созвоны, «у нас срочная задача»… Тут или работать мешают, или поставили нереалистичные сроки. Ну или я неправ был при назначении сроков, задачу недооценил, например, но за это все равно не уволят. А даже если уволят… Ну и что, собсно? Мир развалится?
Так что мои рекомендации про выгорание
1. Учитесь говорить «нет», а в некоторых случаях «пнх».
2. Работа — это то, за что платят. Что не оплачивают — не делать и тем более не брать в голову.
3. Учите основы, они не стареют.
4. Бюрократия и отчетность — твои друзья.
5. Don't worry, be happy.
1. Учитесь говорить «нет», а в некоторых случаях «пнх».
Вот это, кстати, отличный совет! Наберут на себя обязательств, а потом под их весом тонут )))
Действительно важные советы. сам к ним пришел, но не сразу и жить стало легче.
Хотя все еще не научился говорить нет, на "быструю"(полчаса-час) внеурочную работу, за которую явно не заплатят.
Поэтому нужно научиться очень хорошо чувствовать ту фазу, откуда начинается выгорание. Но обычно на этой фазе человек чувствует, что ещё немного может работать. Он пропускает эту фазу, так как чаще всего не хочет оторваться от роботы и скорее хочет закончить задачу. Чем дальше пойти этой фазы, чем больше дней понадобиться, чтобы восстановиться.
Рабочий же может реально всю жизнь делать примерно одно и то же. Наш оператор козлового крана лет через тридцать вообще может не думать.
А разве от рутинной работы человек не может выгорать? Думаю, больше, чем от творческой, Хотя, все зависит от темперамента человека. Но, когда ты каждым годом делаешь одно и то же, ты перестаешь развиваться и к чему-то стремиться. Это тоже может стать причиной выгорания.
Если рутина позволяет каждый раз проявлять собственную экспертность, то не выгорает, но при условии что у него нет декомпенсированного стресса в других сферах жизни.
Михай Чиксентмихаи исследовал жизнь и труд людей, которые десятки лет проработали за одним делом, например раздельщиком рыбы, и некоторые из них избавлялись от рутины через совершенствование навыков.
Для психики куда хуже задачи типа долго нудно что-то делаем и потом это идёт на свалку потому что не пригодилось или устарело.
Наш оператор козлового крана лет через тридцать вообще может не думать
Вспоминается документальная видеозапись с ютуба, где рассказывается про водителя грузовика с выраженной деменцией. Он крутил баранку уже будучи глубоко инвалидизированным и никто ничего не замечал, при том что работу исполнял...
Ну и еще мысль хотел сказать, возможно кто-то в комментариях уже высказал. Есть интересное наблюдение над тем, что сегодняшний ИТ-шник не может выйти на "плато экспертности" т.к. знания слишком быстро обесцениваются из за прогресса и быстрых изменениях во многих сферах ИТ. А раньше, еще лет 40 назад, человек мог почивать на лаврах капитала своих компетенций. Т.е. здание опыта, которое он строил годами труда не разваливалось.
Наверняка в ИТ есть более фундаментальные сферы, а есть те, которые слишком переменчивы.
Выгорают как правило те кто пошел в ИТ за бабками, а не ради интереса
Надо различать 2 вещи.
1 — Когда не хочешь что-то делать, и делаешь через нежелание. Нежелание возникает от того, что у организма почему-то есть неприятные ощущения, обычно потому что ему сложно это делать. На преодоление тратятся нервные ресурсы, и когда делаешь это постоянно, они не успевают восстанавливаться.
2 — Когда хочешь что-то делать, тебе нравится процесс, или нравится получать результат. Кажется, что еще вот это вот сделать и всё, но новая работа появляется постоянно, ищешь способ как сделать ее эффективнее, где-то приходится срезать углы, делать всё быстрее, отвлекаться от предыдущей задачи. Каждая новая задача воспринимается как отвлекающий фактор от предыдущей, которую еще не успел сделать, это вызывает раздражение. Здесь нервные ресурсы тратятся по собственному желанию, без преодоления нежелания, но из-за количества работы тоже не успевают восстанавливаться. Этот вид выгорания опаснее, чем первый, в него легко попасть, но сложно это вовремя заметить, и восстанавливаться после него дольше и сложнее.
Их почему-то часто путают, или считают одним и тем же, особенно те, кто выгорания не испытывал. Многие считают выгоранием только первый вариант, причем только начало, которое называется просто "усталость", "надоело", "задолбало". Но это не выгорание, выгорание наступает если пытаться это постоянно преодолевать.
У нервных клеток тоже есть ресурс, как и у мышц. Поэтому им тоже надо давать отдых. Клетки адаптируются к нагрузке и начинают работать в другом режиме. Поэтому на отдых нужно время, необходимое для того, чтобы клетки вернулись в нормальный режим работы. Забыть главные детали задачи, выкинуть их из головы. Обычно оно сравнимо с временем усиленной работы. Сон восполняет ресурсы клеток после рабочего дня, но режим их работы не меняется. Для изменения нужно отвлечение внимания, нужно подумать о чем-то другом. Поэтому так важно отвлекаться и не работать по выходным. Надо смотреть фильмы, гулять, заниматься хобби, чтобы клетки не оставались в этом напряженнном состоянии готовности к работе.
Следующая статья серии уже в эфире) Там подробно про мотивацию) https://habr.com/ru/post/713650/
Навсегда запомнил время, когда меня только поставили во главе команды разработчиков. Я буднично раздал им задачи и обозначил сроки. Все профукали. Я начал разборки на тему: «какого хрена???».
Стесняюсь спросить, а до этого вы кем работали? В смысле, вас повысили из разработчиков, или вы были менеджером в другой области?
На следующий день прибежала наш HR с круглыми глазами и стала возить лицом по столу уже меня.
А вот это интересно, как она узнала? Кто-то нажаловался?
Кто угодно нажаловался, это же HR, с проблемами в коллективе надо к ней идти, она для этого и работает.
Я был начальником отдела беспроводных технологий. Мы тогда начали подключать приборы учета и потребовалась платформа для сбора данных с них.
На тот момент я успел глубоко погрузиться в специфику, потому задача написать платформу как-то логично легла на меня. В помощь мне дали команду джунов.
Я даже спорить не буду, что подход неверный. Но опыта не было, а вера в свои силы была. Пришлось учиться по ходу. История довольно интересная, это вообще моя маленькая гордость, но писать про это отдельную статью пока не решаюсь.
Процесс трансформации в полноценную ИТ-компанию из провайдера у нас продолжался года три и был не без шероховатостей, да. За это время создано приличное число проектов, и платформа диспетчеризации лишь один из. Но я ее привожу в пример как свой проект, на котором могу разбирать ошибки.
А узнала - да, нажаловались. Сказали - пришел какой-то беспроводной чувак и давай свои порядки внедрять, хотя он нам даже не босс. Я ни на кого не в обиде) было и было, главное, что сделали.
это уже притча во языцах
это уже притча во языцех
Хандра - явление самостоятельное, наблюдалось ещё в пушкинскую эпоху :) Решается духовными практиками, т.е. тюнингом своего сознания (не уверен только, у всех ли есть доступ в свою админку). На личном примере могу пояснить, что уже лет 25 не испытываю состояний хандры или депрессии.
Видосы с разборкой работы Блендера трехгодичной давности смотреть нет смысла
А вот сейчас обидно было. Я пока учился понимать работу в Blender смотрел и много старых видосов тоже. Интерфейс некоторых инструментов меняется, это да, но суть очень часто остаётся прежней. Этот скил мне позволяет сейчас смотреть практически любые уроки с любой давностью и понимать суть отдельно от интерфейса. Есть очень качественные уроки у того же Глеба Александрова или Артёма Слаквы, которые они делали больше трёх лет назад и которые полезно посмотреть даже сегодня.
Больше выгораю от сложных багов и невозможности видеть будущее, чтобы выбрать нужную архитектуру. Решаю эту проблему радикально — свой дебаггер и свой язык программирования.
Естественно, пока делаю — продолжаю выгорать от тех же проблем, но теперь хотя бы есть надежда, что приближаю окончательный конец мучениям.
"Одни уверены, что на них мир держится, а все остальные фигней занимаются и ничего не производят"
"И все же образ «бородатого и чудаковатого сисадмина» имеет место быть."
Товарищи менеджеры. Первое правда, а ваше представление о сисадминах идет лесом
Зачем они выгорают?