В детстве у меня была 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, и заканчивая тем, как работает гипервизор.
Но разработчиком я так и не стал и просто кручусь где-то около, как чайник Рассела на орбите.
Когда пишешь код (если я вообще мог писать что-то похожее на код), то классно: «Уууу, я пишу код, мама, я программист». Но потом обязательно что-то идёт не так. К проблемам-то я готов: вот ошибка, погуглил, что за зверь, решил. Но когда они не кончаются и я не понимаю, не столько, как их решать, а что я должен знать, чтобы вообще осознать ошибку, это угнетает.
Прочитав эту статью, перевод которой приложил, я осознал, что со мной не так и почему у меня не получилось и не получится стать разработчиком — я просто не способен быть настолько упрямым, чтобы каждый раз решать новые незнакомые задачи и не выгореть от этого.
Поэтому я просто сижу в сторонке и наблюдаю, как у людей получается и восхищаюсь их способностями.
Рекомендую другую статью-перевод Исследования о том, как мозг строит гипотезы об окружающем мире еще до того, как получит реальные данные. Если совместить статьи вместе, то получится, что при некотором количестве неудач мозг просто прогнозирует, что они будут постоянны и программировать дальше нет смысла.
