В детстве у меня была Mattel Auto Race — портативная игровая консоль со встроенным LED-экраном с красными светодиодами, элементами управления, одной игрой и динамиками. Почему-то я однажды о ней вспомнил и субботним вечером решил создать версию игры, используя p5.js. Сначала дела шли хорошо: я поработал над встречными автомобилями и логикой создания и удаления автомобилей. Затем я решил немного усложнить игру, добавив немного рандома в процесс появления автомобилей.
Вот тогда я столкнулся с проблемами. Что-то было не так с тем, как я управлял таймингом — я никак не мог заставить машины появляться в нужном мне порядке. Повозившись с разными вариантами, я так и не понял, что не так, и разочаровался. Прошло 2 дня, а я так и не могу вернуться к проекту, чтобы не сталкиваться с досадой и чувством разочарования.
Но оказалось, что так и должно быть.
Примечание и дисклеймер. Я не переводчик, поэтому перевод вольный, заранее извиняюсь.
Как я не закончил игру
В детстве у меня была Mattel Auto Race — портативная игровая консоль со встроенным LED-экраном с красными светодиодами, элементами управления, игрой и динамиками. Игровая приставка на одну игру.
В игре вы водите машинку — яркий светодиодный огонек — вверх по экрану, пытаясь избежать других машин. В конце 70-х это была вершина цифровых развлечений.
Почему-то я однажды вспомнил о ней на выходных, и субботним вечером решил создать его версию, используя p5.js — библиотеку Javascript для создания интерактивных безделушек.
Сначала дела шли хорошо: я потратил час на создание игрового полотна, класса для представления встречных автомобилей и логики для создания и удаления автомобилей. Затем я решил немного усложнить игру, заставив несколько автомобилей появляться в разное, слегка рандомизированное время.
Вот тогда я столкнулся с проблемами. Что-то было не так с тем, как я управлял таймингом — я никак не мог заставить машины появляться в нужном мне порядке. Повозившись с разными вариантами, я так и не понял, что не так, и разочаровался.
Прошло 2 дня, а я так и не вернулся к проекту, потому что меня одолевают сомнения. Я не профессиональный разработчик, а просто любитель, поэтому часто упираюсь в потолок своих возможностей. Всякий раз, когда во время работы над подобным проектом, у меня возникает смутное ощущение, что, «черт, я опять столкнулся с задачей, в которой никогда не разберусь»
Поэтому я избегаю этого проекта, чтобы не сталкиваться с досадой и чувством разочарования.
Время от времени, когда кто-то узнает, что я писатель и при это программирую, меня спрашивают:
— Программировать трудно?
И я обычно отвечаю тем же.
— «Трудно» — неправильное слово. Дело не в том, что программировать трудно. Дело в том, что этот процесс расстраивает.
Программирование — это ежедневное разочарование
Я осознал это, когда читал эссе «What Does Saying That 'Programming Is Hard' Really Say, and About Whom?», которое ставит под сомнение утверждение о том, что «программирование — это сложно».
Как отмечает автор, Бретт Беккер, вы часто слышите от преподавателей, из технических статей и самих разработчиков, что кодирование невероятно сложно. Но, как отмечает Беккер, нет убедительных доказательств того, что программирование сложнее, чем другие сложные действия. У нас нет достоверных данных, свидетельствующих о том, что быть хорошим программистом сложнее, чем быть хорошей медсестрой, адвокатом или шеф-поваром. Отчасти потому, что слово «тяжело» — двусмысленное слово.
Беккер подозревает, что репутация программирования скорее относится к области нарциссизма и культурных традиций.
Сложно ли программировать? Имеющихся данных не убедительны и недостаточно разнообразны, чтобы явно ответить вопрос. Почему же так часто говорят, что это тяжело? Потому что это утверждение трудно доказать. Может быть, это слишком удобно для мотивации и оправдания работы? Неужели многие хотят, чтобы программирование казалось трудным, сознательно или бессознательно? Зависят ли технологические компании и менеджеры по найму от имиджа программирования как тяжелого и элитного?
Я согласен. Я опросил больше 200 программистов, когда писал свою книгу «Coders» , и часто все они говорили мне одно и то же: программирование не было особенно сложным, но требовало дотошности и внимательности к деталям. Часто более жесткого, чем во многих других дисциплинах.
Больше всего они отметили, что для программирования требуется одна особая психологическая установка:
Очень высокая терпимость к ежедневному разочарованию (фрустрации).
Отчего возникает разочарование?
Причина в том, что в большинстве случаев программирование заключается не столько в создании кода, сколько в отладке.
Например:
Вы пишете функцию, тестируете, и часто она не работает.
Вы допустили какую-то ошибку, начиная от тривиальной (забытая точка с запятой) и заканчивая более существенной (ошибка на единицу).
Ваша функция взаимодействует со сторонней библиотекой, и вы не совсем понимаете, как на самом деле работает эта куча ПО.
Или, может быть, вы пытаетесь разобраться в спагетти-коде в огромной кодовой базе, которую легионы предыдущих разработчиков писали плохо и хреново в течение многих лет.
В любом случае, огромное количество времени программисты проводят, пытаясь разобраться как код работает, а не пишут его. Они смотрят на код, полный ошибок, хватаются за голову и пытаются придумать костыль, который, возможно, поможет.
Программисты боролись с разочарованием с тех пор, как существует программирование. Как я писал в своей книге «Coders» …
В июне 1949 года Морис Уилкс собирался подняться по лестнице, когда его внезапно озарило, что «значительная часть оставшейся части моей жизни будет потрачена на поиск ошибок в моих собственных программах»...
Что делает разочарование в коде особенно невыносимым, так это то, что вы не знаете, как долго оно продлится.
Может быть вы поймете ошибку через несколько минут.
Может быть это займет час или два.
А может быть пройдут недели и месяцы, а вы так и не не разберетесь с ошибкой, так что вы просто запишете ее в исключения и забудете.
Поэтому, когда меня спрашивают «Эй, могу я научиться программировать?», то я отвечаю: «Конечно. Почти каждый может».
Пока тебя устраивает непрекращающееся разочарование.
Ремарка от «переводчика»
Клайв Томпсон (Clive Thompson) — автор книг книг «Coders» и «Smarter Than You Think», пишет о технологиях, науке, культуре и программировании. Основная мысль его статьи :
Научиться терпеть разочарования — ключевая часть обучения программированию.
Я несколько раз пытался подобраться к программированию, если можно так сказать. Сначала это была верстка — я изучал HTML, CSS, пыхтел с JS, пробовал на PHP настраивать отправку данных с формы. Потом было много попыток изучать Python, Ruby, C++ или перебраться в тестирование. Про теорию можно не говорить — я и сейчас читаю десятки статей по разным темам, начиная с того, как кто-то настроил себе автоматическую систему полива помидоров на Raspberry Pi, и заканчивая тем, как работает гипервизор.
Но разработчиком я так и не стал и просто кручусь где-то около, как чайник Рассела на орбите.
Когда пишешь код (если я вообще мог писать что-то похожее на код), то классно: «Уууу, я пишу код, мама, я программист». Но потом обязательно что-то идёт не так. К проблемам-то я готов: вот ошибка, погуглил, что за зверь, решил. Но когда они не кончаются и я не понимаю, не столько, как их решать, а что я должен знать, чтобы вообще осознать ошибку, это угнетает.
Прочитав эту статью, перевод которой приложил, я осознал, что со мной не так и почему у меня не получилось и не получится стать разработчиком — я просто не способен быть настолько упрямым, чтобы каждый раз решать новые незнакомые задачи и не выгореть от этого.
Поэтому я просто сижу в сторонке и наблюдаю, как у людей получается и восхищаюсь их способностями.
Рекомендую другую статью-перевод Исследования о том, как мозг строит гипотезы об окружающем мире еще до того, как получит реальные данные. Если совместить статьи вместе, то получится, что при некотором количестве неудач мозг просто прогнозирует, что они будут постоянны и программировать дальше нет смысла.
Комментарии (47)
Moskus
25.07.2022 19:04+12Чем больше читаю о подобном, тем больше осознаю разницу между разными подходами к мотивации. Когда ты работаешь ради удовольствия, а удовольствие не наступает, соблазн всё бросить - велик. Когда ты работаешь ради практического результата предназначенного для потребителя, это видится иначе.
У автора совсем не случайно аналогия с игрой из детства упомянута. Похоже, что и для него, и для многих других, подобная работа - просто "взрослая игра" за которую ещё и деньги платят. Это объясняет также то, как некоторые разработчики реагируют на критику продукта, будто это не нормальная обратная связь, а намеренное оскорбление (когда критика выражена максимально нейтрально). Конечно, если ты "прошёл уровень", а кто-то говорит тебе, что с этим есть какие-то проблемы, в твоих глазах это выглядит, будто тебе хотят испортить удовольствие, потому что удовольствие остаётся главным критерием, а то, что результат труда вообще-то должны использовать третьи лица - это всё не так важно.
Этот антагонизм между for fun и for purpose ещё может выйти боком в будущем.
TryToImagine
25.07.2022 20:10+1Иногда и с целью for fun получались отличные продукты(Линукс) :).
Moskus
25.07.2022 21:54+4Во-первых, я не уверен, что можно обоснованно утверждать что-то столько категоричное о мотивах разработчиков Linux.
Во-вторых, столь сложная система, выполняющая довольно конкретные практические функции и т.п., просто не может быть спроектирована чисто for fun.
В-третьих, я не утверждал, что ничто не может быть создано ради удовольствия.
0xd34df00d
26.07.2022 01:43+3Зачем работать ради практического результата, кроме как ради нередко следующих за этим денег?
ReadOnlySadUser
26.07.2022 01:49-3Ну, как минимум потому, что кто-то должен)
0xd34df00d
26.07.2022 02:25+5Ну вот пусть этот кто-то и программирует.
ReadOnlySadUser
26.07.2022 03:47+1Тысячи нас)
С тем же успехом я могу спросить зачем работать ради теоретического результата?)
0xd34df00d
26.07.2022 04:22+2Ради теоретического — абсолютно с тем же успехом незачем. Вот ради фана уже можно.
Moskus
26.07.2022 05:31+3Скажем так, есть множество людей,которые понимают, что если каждый будет делать работу нормально только до момента, пока ему прикольно, мы дружно утонем в одноразовом дерьме. А любой критический продукт придётся обложить гос.стандартами качества с разного рода карами за их несоблюдение. Потому что, например, авиамеханик ради удовольствия от процесса закрутит только половину гаек.
В принципе, удовольствие от качественно (по критериям третьих лиц) сделанной работы - тоже удовольствие, только определенным образом отложенное. А иногда, если ты взялся что-то делать, приходится доводить до конца
0xd34df00d
26.07.2022 06:24+5Скажем так, есть множество людей, которые понимают, что если каждый будет делать работу нормально только до момента, пока ему прикольно, мы дружно утонем в одноразовом дерьме.
Я слышал, людям иногда платят зарплату, и можно как-то через это давить, например.
Moskus
26.07.2022 17:51Да, только если вы "давите" на того, кто делает всё for fun, для него это противоположность fun. Вы никогда не видели людей, которые получают большую зарплату, но их работа - дерьмо?
Что вообще случилось с "не за страх, а за совесть"?
0xd34df00d
26.07.2022 18:06+1Да, только если вы "давите" на того, кто делает всё for fun, для него это противоположность fun. Вы никогда не видели людей, которые получают большую зарплату, но их работа — дерьмо?
Не то чтобы «дерьмо», но «с 9 до 5 и исключительно в рамках должностных обязательств, а там хоть трава не расти» — это вообще норма в подавляющем большинстве профессий. Вот, да, так и представляю, как каждый кассир в Макдональдсе или в условной Евросети думает, как бы клиенту было повкуснее или поудобнее с мобильником, а каждый пацан, зарабатывающий на первую машину развозкой пиццы на велосипеде, думает о том, как бы побыстрее эту пиццу доставить, потому что люди же ждут. А бариста в Старбаксе не иначе как помогает людям стать здоровее, отговаривая их покупать напитки со слишком высоким содержанием сахара.
И в чуть более интеллектуальных вещах это тоже так же. Так и представляю, как чуваки, занимавшиеся хранением и обработкой логов кликов в одной крупной компании, где я работал, думали, как же оно там клиенту-то, и как ему сделать получше?
Что вообще случилось с "не за страх, а за совесть"?
Оно осталось в наивном и невинном детстве.
Да и совесть у всех разная.
speshuric
26.07.2022 16:52Скажем так, есть множество людей,которые понимают, что если каждый будет делать работу нормально только до момента, пока ему прикольно, мы дружно утонем в одноразовом дерьме.
Ну не совсем. Программировать это же не только (и не столько) нажимание кнопок, сколько умственная деятельность. То, что человек делает какую-то работу "пока прикольно" не значит, что у него должно выходить "одноразовое дерьмо". Если провести аналогию с художниками и музыкантами: они же нередко тоже делают "пока прикольно", но за счёт долгого делания похожих действий получается гораздо лучше, чем у тех, кто это не делает. И у музыкантов ТОЧНО не меньшая фрустрация от "не получается".
А ещё в "прикольно" может входить много аспектов: кому-то это поиск ошибок и граничных случаев - тогда продукт получается стабильнее, кому-то - спроектировать удобный API, кому-то выжать максимум по производительности.
"Не прикольно" часто относится к рутине и неоправданной сложности, но это не значит, что эти задачи необходимы.Moskus
26.07.2022 17:56Как я уже написал выше, речь идёт о том, что продукт, который потребляют другие люди, должен удовлетворять их критериям качества. И в некоторых случаях они могут совпадать с личными критериями удовольствия автора продукта. Но на такое совпадение нельзя надеяться в общем случае, в смысле того, что такая мотивация не является универсально достаточной.
Red_Nose
26.07.2022 03:17Есть еще вариант - "жадный". Это когда по фану сделал на 95%, а потом хоть уже и не интересно, дотягиваешь. Блин, ну жалко мне потраченного времени :)
Жаль, я не из породы "бизнесменов", а то только на доведении отцовских 95%-ых идей заработал-бы 100500 :)
svr_91
26.07.2022 08:36Когда ты работаешь ради практического результата предназначенного для потребителя
Ага, а потом начинается все это "а точно ли потребителям нужна эта функция? Должен ли я спрашивать пользователей о новых функциях? Или они попросят только лишь более быструю лошадь? А должен ли я рефакторить этот модуль, ведь после рефакторинга наверняка что-то сломается и юзер будет недоволен? А должен ли я вообще что-то делать, если юзер всегда (конечно, это всегда разный юзер, но) недоволен, и если я чтото сделаю, то он все равно останется недовольным? А не было бы лучше, если бы этого приложения вообще небыло (например, если это корпоративное приложение, и конечные пользователи не могут от него отказаться из-за начальства, даже при наличии доступных альтернатив)?" и т.п. Знаю-знаю, проходил
Moskus
26.07.2022 17:57Забудьте на секунду о программировании. Представьте что ремонтируете чьи-то тормоза на машине.
402d
25.07.2022 19:17+7Программист - это интелектуальный садомазохист. Кто еще может выдержать себя чувствовать дураком ? Не понимаю почему не работает ? Хуже только случай, когда не понимаешь почему работает.
рутина - рутина -рутина - я идиот - я идиот - А нет вроде умница - рутина - рутина - не фига не понимаю - гуглю - не понимаю - гуглю - а я идиот - рутина -рутина
snuk182
26.07.2022 22:34То ли дело столяр, никакой рутины. Зазевался - пальца нет. Зазевался - второго нет. И зп хватает как раз на две бутылки. Зато никаких сомнений.
panzerfaust
25.07.2022 19:37+17Не, не жиза. Я грустил от проблем типа "компилятор не компиляет" и "спринг не спрингует" только в самом начале карьеры. Сейчас такие ошибки наоборот подстегивают интерес и побуждают покопаться в кишках библиотек. А говнокод побуждает переписать его по уму или как минимум написать хороший юнит-тест.
Настоящие разочарования современного погромиста вообще в другой плоскости лежат. Шизанутый менеджмент, изменение требований от дуновения ветра, отмены проектов, бюрократия и т.п.
riskov Автор
25.07.2022 20:12+2Настоящие разочарования современного погромиста вообще в другой плоскости лежат. Шизанутый менеджмент, изменение требований от дуновения ветра, отмены проектов, бюрократия и т.п.
Хотя я код не пишу, но как же знакомо...
Kiri11squid
25.07.2022 20:51+3Вот поэтому вы и остались в этой карьере, а большинство ломается на первом этапе. Они думали, что надо просто "научиться" и тогда всё будет понятно. Но нет, ошибки будут всегда, единственный путь это научиться относиться к ним по-другому.
in_heb
25.07.2022 23:04+1Потому что индустриальное программирование это такой же рутинный бизнес как шиномонтаж. Хотите заниматься высокими материями - это вам в академическую среду
0xd34df00d
26.07.2022 01:46+5В академической среде у вас будет шизанутый грантодатель/завкаф/етц, а дальше все точно то же.
Только независимый ресерч, только хардкор.
MonkAlex
25.07.2022 19:49+3Так епт, надо же хоть раз доделать. Сделать так, чтобы разочарование вида "я не смогу" превратилось в "о, я смог".
И каждое такое (даже самое мелкое) событие учит тебя, как программиста, что решение бывает и оно бывает даже несложное. А со временем наберешься опыта и станешь относиться к этому проще и в техническом и моральном плане.
А статья в целом выглядит как реклама книг. Что наверняка и было в первоисточнике.
0xd34df00d
26.07.2022 01:48+1У меня есть чувство, что если я и закончу когда один текущий проект, то закончу его с мыслью «ппц я тупой, столько времени на это убить, не мое это, пойду в шпалоукладчики».
MonkAlex
26.07.2022 10:06Сужу по комментам на хабре - у вас это далеко не первый проект. И проблема, описанная в статье вас не касается именно в таком виде =)
mvv-rus
25.07.2022 22:51Разочарование — это субъективная реакция на сложность программирования.
Программирование объективно сложно, но проявиться это может разным образом.
Может — разочарованием, как у автора оригинала этого перевода, может — срывом всех и всяких сроков, как у автора «Мифического человеко-месяца».
Closius
26.07.2022 01:25Чет мне кажется ты путаешь разочарование и банальное раздолбайство/лентяйство.
ReadOnlySadUser
26.07.2022 01:54С одной стороны, как бы да, с другой - мне вот эти все фичи зачастую нахрен не нужны. Я люблю баги, да позаковыристее. Когда реально эта хрень не работает и ты её чинишь. Причем, чем глубже эта проблема в недрах системы, тем я счастливее. А вот приходят потом, говорят посреди "исследовательского" процесса: "давай фичу новую делать!". Вот это реально бывает расстраивает.
Для меня самая расстраивающая вещь в программировании, которую я так и не смог победить и которая меня угнетает каждый божий день, это каждодневное осознание глубины собственного незнания. Чем дальше - тем больше это незнание. И сколько бы лет я еще не занимался программированием, я уже никогда не почувствую себя умным человеком)riskov Автор
26.07.2022 08:28каждодневное осознание глубины собственного незнания. Чем дальше - тем больше это незнание. И сколько бы лет я еще не занимался программированием, я уже никогда не почувствую себя умным человеком)
Хорошо сказано, спасибо!)
ruomserg
26.07.2022 08:22+3Ну вот я вам наброшу еще одну связанную с этим особенность программирования. Разработчик обычно имеет дело со сломанными программами, и почти никогда не может похвастаться результатами своего труда кроме как в узком кругу таких же специалистов. Например, если архитектор спроектировал здание и его построили — он может пройти мимо него, и посмотреть на результат своего труда, который стоит тут сегодня и останется завтра — да детям похватсться в конце-концов! Инженер, спроектировавший какой-то агрегат — обычно потом видит как оно работает, и может быть, даже сам им пользуется.
Большинство разработчиков до некоторой степени похожи на врачей: им привозят больного, те ставят его на ноги, больной уходит. И никто кроме другого врача не поймет, в чем была сложность: ну полежал, ну накормили таблетками — ну выздоровел… И у разработчиков (особенно в компаниях где жестко разделена архитектура и разработка/поддержка) — та же фигня. Прилетел баг — задебажил/разобрал логи, зафиксировал регрессией в тестах, зачинил, сунул в пайплайн CI/CD, закрыл, перешел к следующему. И завтра… И послезавтра…
Неудивительно, что программисты пилят свои пет-проекты на гитхабе — там есть шанс получить радость от полностью своей работающей системы! А не от бесконечного конвейера фиксов и фич…
В общем, программирование — это не профессия мечты. Учиться надо всю жизнь, свои мысли для компьютера формулировать однозначно и непротиворечиво, работать постоянно с тем, что сломалось… Но дьявольски интересно, если есть склонности к этому.
Всем желаю внедрять концепцию code ownership в командах, когда люди не только пилят код, но и видят как он работает в жизненном цикле системы. Резко снижает вероятность выгорания, как по мне…
dimas846
26.07.2022 09:20+1В статье описана одна сторона медали, а как же другая? Когда фича получилась! Когда понимаешь, что ты написал хороший код. Именно тебе дали задание разобраться в очень сложной проблеме. Даже, если это "очередное исправление бага". Чтобы получать от этого кайф, наверное нужно качество - самодостаточность.
ruomserg
26.07.2022 09:25+2О, это работает — обычно в начале карьеры. Первых вылеченных больных врач помнит по именам. Умерших, правда, тоже. А потом и то и другое становится нормой.
У программистов хоть не умирает никто (и всегда можно сбросить в git текущую ветку, вытащить предыдущий коммит и начать заново) — врачи бы душу дьяволу продали за возможность сбрасывать человека умершего на столе в предыдущее состояние…dimas846
26.07.2022 21:30+1Согласен полностью! Может как раз поэтому и советуют раз в два, пять лет менять место работы. Тогда ты сбрасываешь с себя груз старых разочарований, рутины. На новом месте можно заняться тем, чем не мог на старом. И снова почувствовать себя в начале нового пути.
402d
26.07.2022 19:55Вот все произошло как написали. И если самодостаточности нет, то будет "горизонт завален" https://img.repetit.ru/blog/image_84704_06-06-2017_20-44-28_.jpg
s1im
26.07.2022 09:19+2Я не считаю, что в работе программиста фрустрация превалирует над остальным. В примере из статьи, я почти уверен, что человек просто не разобрался с понятием асинхронности и как оно реализовано в js. Я, в начале своей карьеры, когда писал простые программки на Turbo Pascal-е и ассемблере, где подобные проблемы решались в лоб тупым
sleep(iRadomMs);тоже не смог бы сразу реализовать подобный пример, удивляясь, почемуsetTimeout();не работает точно так же. На это понадобилось немало времени для обучения. Проблема - в кажущейся простоте. Почти любой выпускник полугодовых курсов по IT-специальности сможет выдавать много лапше-кода в индусском стиле. На отдельных примерах все даже будет работать. Но просто ли будет поддерживать, развивать и модифицировать систему, написанную в подобном стиле? Думаю, ответ очевиден. Для этого требуется намного больше времени, десятки книг и тысячи часов практики.ruomserg
26.07.2022 09:34+3Философски говоря, программирование это особый способ полного и непротиворечивого МЫШЛЕНИЯ о проблемах окружающего мира, а также выражения этих мыслей на специальных искусственных языках.
Насколько можно судить, искусство мыслить о вещах полно и непротиворечиво — не свойственно человеческой натуре в диком виде. Это требует природной склонности и тренировки. Поэтому, например, много программистов выходят с матфаков. Там нужно примерно то же самое. У некоторых индивидуумов — необходимость сформулировать свою мысль полно и непротиворечиво вызывает физическое недомогание.
Если же у человека нет адекватных мыслей, или он не может их привести в порядок — то на обычном языке другому человеку он все-равно может что-то сказать. И при определенном везении, тот другой — его даже как-то поймет. Благо есть общая биология, культурные нормы и прочие резрвные вещи. А с языком программирования и компьютером такие штучки не проходят. ЯП специально сконструирован так, что его бедными средствами сложно (но не невозможно — не обольщайтесь!) написать неоднозначный или противоречивый текст. Поэтому человек не являющийся разработчиком — обычно тупо сидит перед IDE и не знает с чего начать. Даже после прочтения книги. Даже если он смог повторить пример из нее… Ну или лепит конструкции программирования друг на друга — создавая некую бессмыслицу. Впрочем, даже бессмыслица на каких-то входных данных может работать, создавая иллюзию, что процесс идет в верном направлении…s1im
26.07.2022 09:39+5Согласен, при этом первые строят работающие абстрактные модели в голове, которые потом переносят в код без заметной фрустрации, а вторые сразу пишут код, который приходится запускать и отлаживать при каждой новой добавленной строчке и терпеть фрустрацию.
Cryvage
26.07.2022 09:55Автор сначала утверждает, что программировать не сложно, и тут же заявляет, что главная проблема — разочарование от неудач. Вижу здесь серьёзное противоречие. Чтобы разочарование было регулярным, неудачи тоже должны быть обычным делом. Откуда же берутся неудачи в таком количестве? Очевидно, они возникают из-за сложности. Чем сложнее задача, тем чаще человек терпит неудачу, и тем большее психологическое давление испытывает. С простой задачей такого бы не происходило.
Давайте проведём аналогию с играми, раз уж автор приводит пример с игрой из детства. Если подумать, игры здесь очень хорошо подходят в качестве модели. Думаю, любой человек с солидным игровым опытом, не раз сталкивался со сложными уровнями или миссиями в играх, для прохождения которых требовалось предпринимать десятки, а то и сотни попыток. Вспомните 3-й уровень в Battletoads, где нужно ездить на байке, миссию с вертолётиком в GTA Vice City или миссию с гонкой в первой Мафии. Признаюсь честно, иногда я бросал игры из-за таких миссий, например, я так и не прошёл первую Мафию.
Программирование напоминает именно такие игры. Посреди простых и умеренно сложных задач, периодически встречаются особенно сложные «миссии». Но ведь эта неравномерность объективно увеличивает общую сложность всей задачи, причём, вовсе не за счёт вклада в среднюю сложность, а гораздо сильнее. Легко обмануться, приняв среднюю сложность за общую, но чтобы достичь цели, надо пройти весь путь, а для этого вам должна быть по плечу не только средняя его сложность, но и пиковая. Следовательно, сложность всего пути не равна средней сложности всех его участков. Простое среднее — это лишь минимально возможная сложность, если считать что распределение сложности по участкам близко к равномерному. Неравномерность существенно влияет на общую сложность в сторону её увеличения, по сравнению со средней, и это не субъективное восприятие, а объективный факт.
Можно долго рассуждать о психологии, стойкости, упорстве, готовности терпеть неудачи, и т.д. Но глупо при этом отрицать, что всё это требуется, прежде всего, при решении объективно сложных задач. То что сложные задачи являются ещё и серьёзным психологическим испытанием, это лишь положительная обратная связь. Чем агрессивнее внешние условия, чем ближе режим работы к пределам возможностей, тем выше вероятность, что проявятся ещё и внутренние проблемы. В этом нет никакого откровения. Это просто очевидно.s1im
26.07.2022 10:27Замечал, что иногда бывают проекты, где ты сидишь, пилишь какие-то новые фишки или правишь старые баги месяцами, все очень ровно, понятно, никаких неожиданностей и переработок. Местами от такого спокойствия даже деградируешь как специалист. А потом раз, и задача такая масштабная, неприятная и скучная, или баг какой-то очень специфичный, у 1% пользователей, что хоть увольняйся) Кто-то сталкивался с подобным?
khe404
26.07.2022 17:02Потрясающе простое и важное наблюдение о разочаровании.
Как преодолеть барьер в понимании чего-то нетривиального? И как разбить непонятную задачу на более простые, если сама по себе задача не понятна и как ее решать тоже не понятно.
И как перестать начинать решать всю задачу с нуля, потому что разобраться в том на чем остановился вчера уже нет никакого желания.
RalphMirebs
Такое бывает, но не дольше чем до утра. Проснувшись, забываю про неудачи и снова в бой. И такая-же ситуация возникает и в спорте и в комп играх. Абсолютно нормальная ситуация.
riskov Автор
Везет) Моя фрустрация иногда не отпускает меня неделями. И это у меня работа попроще (не говорю, что нервная, проще)