Comments 56
Везет) Моя фрустрация иногда не отпускает меня неделями. И это у меня работа попроще (не говорю, что нервная, проще)
я тут недавно выяснил удивительную для себя вещь, когда занимался с племянницей-пятикласницей, очень отстающей по математике.
Оказалось она не усвоила/пропустила/не знает основное правило из 2-го(!) класса из математики, правило порядка операций в записи мат-выражений! Естественно математика вызывает у нее что-то вроде осознания собственной ущербности, потому что она не может предположить что надо просто знать одно простое правило чтобы все понять, но самое главное что ей не внушили фатальность не соблюдения этого правила:
типа соблюдаешь = ты молодец, у тебя все получается;
не соблюдаешь = ты балбес, ты ничего не можешь решить.
Потом я догадался спросить своего однокласника-механника(очень хорошего!)-шофера, который также признавался что не понимает математику, я спросил его знает ли он это правило из 2-го класса школы, и выяснилось что и он не знает в его 50-лет!
А мне вот где то уже в 1-м, 2-м классах настолько вдолбили ощущение этой фатальности не соблюдения правил математики, что я кроме того что их прочуствовал (даже не осознавая долгое время), я еще и научился проверять и контролировать, фактически ощущать их соблюдение или не соблюдение, и даже восхищаться их неумолимым действием в окружающей нас действительности.
Придумать бы историю чтобы оформить это в виде статьи...
Чем больше читаю о подобном, тем больше осознаю разницу между разными подходами к мотивации. Когда ты работаешь ради удовольствия, а удовольствие не наступает, соблазн всё бросить - велик. Когда ты работаешь ради практического результата предназначенного для потребителя, это видится иначе.
У автора совсем не случайно аналогия с игрой из детства упомянута. Похоже, что и для него, и для многих других, подобная работа - просто "взрослая игра" за которую ещё и деньги платят. Это объясняет также то, как некоторые разработчики реагируют на критику продукта, будто это не нормальная обратная связь, а намеренное оскорбление (когда критика выражена максимально нейтрально). Конечно, если ты "прошёл уровень", а кто-то говорит тебе, что с этим есть какие-то проблемы, в твоих глазах это выглядит, будто тебе хотят испортить удовольствие, потому что удовольствие остаётся главным критерием, а то, что результат труда вообще-то должны использовать третьи лица - это всё не так важно.
Этот антагонизм между for fun и for purpose ещё может выйти боком в будущем.
Иногда и с целью for fun получались отличные продукты(Линукс) :).
Во-первых, я не уверен, что можно обоснованно утверждать что-то столько категоричное о мотивах разработчиков Linux.
Во-вторых, столь сложная система, выполняющая довольно конкретные практические функции и т.п., просто не может быть спроектирована чисто for fun.
В-третьих, я не утверждал, что ничто не может быть создано ради удовольствия.
Ну, как минимум потому, что кто-то должен)
Скажем так, есть множество людей,которые понимают, что если каждый будет делать работу нормально только до момента, пока ему прикольно, мы дружно утонем в одноразовом дерьме. А любой критический продукт придётся обложить гос.стандартами качества с разного рода карами за их несоблюдение. Потому что, например, авиамеханик ради удовольствия от процесса закрутит только половину гаек.
В принципе, удовольствие от качественно (по критериям третьих лиц) сделанной работы - тоже удовольствие, только определенным образом отложенное. А иногда, если ты взялся что-то делать, приходится доводить до конца
Скажем так, есть множество людей,которые понимают, что если каждый будет делать работу нормально только до момента, пока ему прикольно, мы дружно утонем в одноразовом дерьме.
Ну не совсем. Программировать это же не только (и не столько) нажимание кнопок, сколько умственная деятельность. То, что человек делает какую-то работу "пока прикольно" не значит, что у него должно выходить "одноразовое дерьмо". Если провести аналогию с художниками и музыкантами: они же нередко тоже делают "пока прикольно", но за счёт долгого делания похожих действий получается гораздо лучше, чем у тех, кто это не делает. И у музыкантов ТОЧНО не меньшая фрустрация от "не получается".
А ещё в "прикольно" может входить много аспектов: кому-то это поиск ошибок и граничных случаев - тогда продукт получается стабильнее, кому-то - спроектировать удобный API, кому-то выжать максимум по производительности.
"Не прикольно" часто относится к рутине и неоправданной сложности, но это не значит, что эти задачи необходимы.
Как я уже написал выше, речь идёт о том, что продукт, который потребляют другие люди, должен удовлетворять их критериям качества. И в некоторых случаях они могут совпадать с личными критериями удовольствия автора продукта. Но на такое совпадение нельзя надеяться в общем случае, в смысле того, что такая мотивация не является универсально достаточной.
>мы дружно утонем в одноразовом дерьме
Wait, oh shi~
Я программирую для удовольствия. И совершенно не вижу в этом ничего плохого. Работа отнимает большую часть жизни: как-то странно жить без отдачи для себя.
И нет, это не значит, что останется закрученным только половина гаек: грубо говоря, я плачу той частью работы, которая не слишком веселая за ту часть, от которой кайфую. Половина гаек для себя, половина - для дела.
Есть еще вариант - "жадный". Это когда по фану сделал на 95%, а потом хоть уже и не интересно, дотягиваешь. Блин, ну жалко мне потраченного времени :)
Жаль, я не из породы "бизнесменов", а то только на доведении отцовских 95%-ых идей заработал-бы 100500 :)
Когда ты работаешь ради практического результата предназначенного для потребителя
Ага, а потом начинается все это "а точно ли потребителям нужна эта функция? Должен ли я спрашивать пользователей о новых функциях? Или они попросят только лишь более быструю лошадь? А должен ли я рефакторить этот модуль, ведь после рефакторинга наверняка что-то сломается и юзер будет недоволен? А должен ли я вообще что-то делать, если юзер всегда (конечно, это всегда разный юзер, но) недоволен, и если я чтото сделаю, то он все равно останется недовольным? А не было бы лучше, если бы этого приложения вообще небыло (например, если это корпоративное приложение, и конечные пользователи не могут от него отказаться из-за начальства, даже при наличии доступных альтернатив)?" и т.п. Знаю-знаю, проходил
"Европейская" культура она акцентируется на связи трудовых достижений и ценности личности. Думаю, по этой причине большая часть психологических проблем у людей. Потому что собственная ценность для них выражается через труд и критика плодов труда это покушение на личность самого человека.
Программист - это интелектуальный садомазохист. Кто еще может выдержать себя чувствовать дураком ? Не понимаю почему не работает ? Хуже только случай, когда не понимаешь почему работает.
рутина - рутина -рутина - я идиот - я идиот - А нет вроде умница - рутина - рутина - не фига не понимаю - гуглю - не понимаю - гуглю - а я идиот - рутина -рутина
Не, не жиза. Я грустил от проблем типа "компилятор не компиляет" и "спринг не спрингует" только в самом начале карьеры. Сейчас такие ошибки наоборот подстегивают интерес и побуждают покопаться в кишках библиотек. А говнокод побуждает переписать его по уму или как минимум написать хороший юнит-тест.
Настоящие разочарования современного погромиста вообще в другой плоскости лежат. Шизанутый менеджмент, изменение требований от дуновения ветра, отмены проектов, бюрократия и т.п.
Настоящие разочарования современного погромиста вообще в другой плоскости лежат. Шизанутый менеджмент, изменение требований от дуновения ветра, отмены проектов, бюрократия и т.п.
Хотя я код не пишу, но как же знакомо...
Вот поэтому вы и остались в этой карьере, а большинство ломается на первом этапе. Они думали, что надо просто "научиться" и тогда всё будет понятно. Но нет, ошибки будут всегда, единственный путь это научиться относиться к ним по-другому.
Потому что индустриальное программирование это такой же рутинный бизнес как шиномонтаж. Хотите заниматься высокими материями - это вам в академическую среду
Так епт, надо же хоть раз доделать. Сделать так, чтобы разочарование вида "я не смогу" превратилось в "о, я смог".
И каждое такое (даже самое мелкое) событие учит тебя, как программиста, что решение бывает и оно бывает даже несложное. А со временем наберешься опыта и станешь относиться к этому проще и в техническом и моральном плане.
А статья в целом выглядит как реклама книг. Что наверняка и было в первоисточнике.
Программирование объективно сложно, но проявиться это может разным образом.
Может — разочарованием, как у автора оригинала этого перевода, может — срывом всех и всяких сроков, как у автора «Мифического человеко-месяца».
Чет мне кажется ты путаешь разочарование и банальное раздолбайство/лентяйство.
С одной стороны, как бы да, с другой - мне вот эти все фичи зачастую нахрен не нужны. Я люблю баги, да позаковыристее. Когда реально эта хрень не работает и ты её чинишь. Причем, чем глубже эта проблема в недрах системы, тем я счастливее. А вот приходят потом, говорят посреди "исследовательского" процесса: "давай фичу новую делать!". Вот это реально бывает расстраивает.
Для меня самая расстраивающая вещь в программировании, которую я так и не смог победить и которая меня угнетает каждый божий день, это каждодневное осознание глубины собственного незнания. Чем дальше - тем больше это незнание. И сколько бы лет я еще не занимался программированием, я уже никогда не почувствую себя умным человеком)
Большинство разработчиков до некоторой степени похожи на врачей: им привозят больного, те ставят его на ноги, больной уходит. И никто кроме другого врача не поймет, в чем была сложность: ну полежал, ну накормили таблетками — ну выздоровел… И у разработчиков (особенно в компаниях где жестко разделена архитектура и разработка/поддержка) — та же фигня. Прилетел баг — задебажил/разобрал логи, зафиксировал регрессией в тестах, зачинил, сунул в пайплайн CI/CD, закрыл, перешел к следующему. И завтра… И послезавтра…
Неудивительно, что программисты пилят свои пет-проекты на гитхабе — там есть шанс получить радость от полностью своей работающей системы! А не от бесконечного конвейера фиксов и фич…
В общем, программирование — это не профессия мечты. Учиться надо всю жизнь, свои мысли для компьютера формулировать однозначно и непротиворечиво, работать постоянно с тем, что сломалось… Но дьявольски интересно, если есть склонности к этому.
Всем желаю внедрять концепцию code ownership в командах, когда люди не только пилят код, но и видят как он работает в жизненном цикле системы. Резко снижает вероятность выгорания, как по мне…
Интересные мысли, спасибо!
В статье описана одна сторона медали, а как же другая? Когда фича получилась! Когда понимаешь, что ты написал хороший код. Именно тебе дали задание разобраться в очень сложной проблеме. Даже, если это "очередное исправление бага". Чтобы получать от этого кайф, наверное нужно качество - самодостаточность.
У программистов хоть не умирает никто (и всегда можно сбросить в git текущую ветку, вытащить предыдущий коммит и начать заново) — врачи бы душу дьяволу продали за возможность сбрасывать человека умершего на столе в предыдущее состояние…
Вот все произошло как написали. И если самодостаточности нет, то будет "горизонт завален" https://img.repetit.ru/blog/image_84704_06-06-2017_20-44-28_.jpg
Я не считаю, что в работе программиста фрустрация превалирует над остальным. В примере из статьи, я почти уверен, что человек просто не разобрался с понятием асинхронности и как оно реализовано в js. Я, в начале своей карьеры, когда писал простые программки на Turbo Pascal-е и ассемблере, где подобные проблемы решались в лоб тупым sleep(iRadomMs); тоже не смог бы сразу реализовать подобный пример, удивляясь, почему setTimeout(); не работает точно так же. На это понадобилось немало времени для обучения. Проблема - в кажущейся простоте. Почти любой выпускник полугодовых курсов по IT-специальности сможет выдавать много лапше-кода в индусском стиле. На отдельных примерах все даже будет работать. Но просто ли будет поддерживать, развивать и модифицировать систему, написанную в подобном стиле? Думаю, ответ очевиден. Для этого требуется намного больше времени, десятки книг и тысячи часов практики.
Насколько можно судить, искусство мыслить о вещах полно и непротиворечиво — не свойственно человеческой натуре в диком виде. Это требует природной склонности и тренировки. Поэтому, например, много программистов выходят с матфаков. Там нужно примерно то же самое. У некоторых индивидуумов — необходимость сформулировать свою мысль полно и непротиворечиво вызывает физическое недомогание.
Если же у человека нет адекватных мыслей, или он не может их привести в порядок — то на обычном языке другому человеку он все-равно может что-то сказать. И при определенном везении, тот другой — его даже как-то поймет. Благо есть общая биология, культурные нормы и прочие резрвные вещи. А с языком программирования и компьютером такие штучки не проходят. ЯП специально сконструирован так, что его бедными средствами сложно (но не невозможно — не обольщайтесь!) написать неоднозначный или противоречивый текст. Поэтому человек не являющийся разработчиком — обычно тупо сидит перед IDE и не знает с чего начать. Даже после прочтения книги. Даже если он смог повторить пример из нее… Ну или лепит конструкции программирования друг на друга — создавая некую бессмыслицу. Впрочем, даже бессмыслица на каких-то входных данных может работать, создавая иллюзию, что процесс идет в верном направлении…
Давайте проведём аналогию с играми, раз уж автор приводит пример с игрой из детства. Если подумать, игры здесь очень хорошо подходят в качестве модели. Думаю, любой человек с солидным игровым опытом, не раз сталкивался со сложными уровнями или миссиями в играх, для прохождения которых требовалось предпринимать десятки, а то и сотни попыток. Вспомните 3-й уровень в Battletoads, где нужно ездить на байке, миссию с вертолётиком в GTA Vice City или миссию с гонкой в первой Мафии. Признаюсь честно, иногда я бросал игры из-за таких миссий, например, я так и не прошёл первую Мафию.
Программирование напоминает именно такие игры. Посреди простых и умеренно сложных задач, периодически встречаются особенно сложные «миссии». Но ведь эта неравномерность объективно увеличивает общую сложность всей задачи, причём, вовсе не за счёт вклада в среднюю сложность, а гораздо сильнее. Легко обмануться, приняв среднюю сложность за общую, но чтобы достичь цели, надо пройти весь путь, а для этого вам должна быть по плечу не только средняя его сложность, но и пиковая. Следовательно, сложность всего пути не равна средней сложности всех его участков. Простое среднее — это лишь минимально возможная сложность, если считать что распределение сложности по участкам близко к равномерному. Неравномерность существенно влияет на общую сложность в сторону её увеличения, по сравнению со средней, и это не субъективное восприятие, а объективный факт.
Можно долго рассуждать о психологии, стойкости, упорстве, готовности терпеть неудачи, и т.д. Но глупо при этом отрицать, что всё это требуется, прежде всего, при решении объективно сложных задач. То что сложные задачи являются ещё и серьёзным психологическим испытанием, это лишь положительная обратная связь. Чем агрессивнее внешние условия, чем ближе режим работы к пределам возможностей, тем выше вероятность, что проявятся ещё и внутренние проблемы. В этом нет никакого откровения. Это просто очевидно.
Замечал, что иногда бывают проекты, где ты сидишь, пилишь какие-то новые фишки или правишь старые баги месяцами, все очень ровно, понятно, никаких неожиданностей и переработок. Местами от такого спокойствия даже деградируешь как специалист. А потом раз, и задача такая масштабная, неприятная и скучная, или баг какой-то очень специфичный, у 1% пользователей, что хоть увольняйся) Кто-то сталкивался с подобным?
Потрясающе простое и важное наблюдение о разочаровании.
Как преодолеть барьер в понимании чего-то нетривиального? И как разбить непонятную задачу на более простые, если сама по себе задача не понятна и как ее решать тоже не понятно.
И как перестать начинать решать всю задачу с нуля, потому что разобраться в том на чем остановился вчера уже нет никакого желания.
автор ты разочаровался в своей тупости а не в программировании, называй вещи своими именами
Первый раз слышу о разочаровании и сам не припоминаю что бы так со мной было. Чаще всего наоборот, когда что то придумываешь, пишешь весь такой на подъёме, а утром думаешь, а нафига?
Или проекты начинают надоедать когда главные задачи решил, идея уже работает на практике, челленж можно сказать окончен, остаётся полировка, доводка. Но чтоб разочарование от того что что то не получается - никогда!
«Программировать не сложно — сложно не разочароваться в процессе»