Летние каникулы здесь. Старшеклассники, составляющие большую часть моей группы друзей, радуются. Первые пару недель каждый любит просто бездельничать. Затем все снова начинают жаловаться.

Видите ли, вялость в конце концов одолевает большинство этих учеников. В течение учебного года все настолько скучно и напряженно, что всем это почти все время надоедает, и в результате возникает беспокойство. Но как только наступают праздники, и они думают, что дела идут на поправку, им быстро становится скучно. Я называю это явление «Отсутствие внутренней цели».

Сошествие моей сестры в пустое существование - классический пример этого феномена. После нескольких безрезультатных проектов она достигла дна: недельный период, наполненный уроками по макияжу на YouTube, мобильными играми и социальными сетями. В конце этого периода она стала более громко говорить о своих страданиях, и я был вынужден помочь. Вот где эта статья становится технической.

Ей хотелось сделать что-то механическое, не требующее постоянного творческого вклада. Ее предыдущий интеллектуальный путь, писательская литература, большую часть времени требовал сознательного умственного напряжения, отсюда и ее регулярное выгорание. После быстрого поиска «ценных навыков, которым стоит научиться в 2018 году», я предложил ей заняться программированием. Я предложил это, потому что можно с уверенностью сказать, что это ценный навык в будущем, и я тоже им пользуюсь, и могу помочь ей, если что-то пойдет не так. В первый день ее серии кодирования (на момент написания) все выглядит хорошо. Вовлеченность высока, и общая удовлетворенность жизнью кажется лучше.

Итак, вам может быть интересно: а что с названием?

По правде говоря, я не пишу много кода.

Я строю бизнес по разработке программного обеспечения на платформе управления идеями, но пишу мало кода. Тиан Оои - ведущий инженер. Когда я пишу код, это происходит из-за каких-то чрезвычайных обстоятельств (дедлайны, больничные и т. Д.). Даже тогда я ненавижу программирование примерно через два дня после этого.

Я ненавижу это, потому что большая часть выполняемого программирования кажется мне роботизированной. Ежедневная работа инженеров в моем бизнесе связана со многими популярными, всеми любимыми технологиями, такими как React Native, MongoDB и Ruby on Rails, поэтому мы не пишем какой-либо ассемблерный код или (не дай Бог) Java. Просто программирование - это не то, что мне хотелось бы сейчас.

Основная цель программирования - следовать хорошо известному рецепту, который был создан горсткой действительно умных людей.

Цель программирования обычно довольно ясна, как и процесс ее достижения. У вас есть набор вещей, которые нужно выполнить, и вы заставляете код делать это в удовлетворительной степени. Проблема в том, что без какого-либо предупреждения двадцать миллионов вещей пойдут не так, как надо, в процессе получения кода для этого. По моему опыту, не все, что может облажаться, будет. Но то, что должно работать, в конечном итоге приведет к ошибке вместо, вызывая даже больше проблем, чем ожидалось.

Программирование утомительно. Нет, это чертовски утомительно. Это делает невозможным творческий подход к коду, потому что даже обычное, обычное использование кода почти не работает. Кодирование еще не на той стадии, когда вы можете просто начать писать, не имея четкой цели. Вы не можете исследовать с помощью кода, вы можете только строить с его помощью. В масляной живописи это похоже на возможность нарисовать картину, которая уже ясно видна в вашей голове. Это похоже на то, как будто каждая капля цвета должна быть заранее спланирована и рассчитана, и каждый случайный штрих, сделанный на холсте, заставит весь холст загореться.

Потому что большая часть кода недостаточно полна, чтобы существовать без огромного, явного намерения.

Творчество вряд ли возможно в программировании, потому что в программировании вряд ли возможна случайность. Есть четко определенные способы работы, и на базовом уровне это нормально. Проблема в том, что большинство сред программирования предназначены для принятия только ограниченного подмножества предопределенных рабочих процессов. Следовательно, при программировании вы должны придерживаться этих нескольких способов, иначе ваше дерьмо не сработает. Это имеет несколько важных последствий для опыта программирования:

Во-первых, выходить за рамки возможностей этих установленных рабочих процессов почти невозможно или настолько неприятно, что вы можете даже не пытаться. Вот почему новые рабочие процессы постоянно создаются в форме новых языков или фреймворков. Да, все программирование, которое когда-либо выполнялось к этому моменту, могло быть написано в двоичном формате. Единственная причина, по которой этого не делают, состоит в том, что не хватает настолько безумных людей.

Во-вторых, когда действительно необходимо создать разные, продвинутые вещи, они также должны придерживаться этих нескольких установленных способов, и это делает процесс их программирования чрезвычайно трудным. Это звучит как повторение первого пункта, но я пытаюсь выделить здесь опыт. Программирование в такой ситуации может быть поистине, универсально, объективно адским.

Каждый читающий должен это понимать, и я чувствую, что некоторым читателям, незнакомым с техническим пулом, может быть трудно понять природу этого страдания. Я провел близкую аналогию: представьте, что вам нужно переместить пятьдесят арбузов из точки A в точку B, которая находится на расстоянии 30 миль, за шесть часов. У вас есть грузовик, который легко поместит в него все пятьдесят арбузов одновременно.

Звучит как простое решение, правда? Просто загрузите арбузы в грузовик и поезжайте в пункт Б. Шесть часов - достаточно времени, верно? Что ж, в зависимости от того, о каком типе программирования мы говорим, этот сценарий может разыграться для программиста несколькими разными способами.

Если вы разработчик на C, вы уже облажались, потому что забыли что-нибудь импортировать. Кроме того, ваш грузовик полон мусора, что делает его непригодным для использования. Если вы разработчик Javascript, вы сможете начать загружать арбузы в грузовик, но на полпути вы будете остановлены циклическими зависимостями 6 из ваших 79 пакетов npm. Если вы системный разработчик, у вас даже нет грузовика, поэтому вы вместо этого выбираете собрать семена с некоторых арбузов, пробежать 30 миль и посадить семена в точке B, надеясь, что вы вырастете. 30 арбузов в итоге получилось. Если вы разработчик Ruby on Rails, грузовик на самом деле самоуправляемый, поэтому все, что вам нужно сделать, это загрузить все арбузы. Но в процессе вы неправильно использовали метод ActiveRecord, и теперь все ваши арбузы на самом деле являются авокадо. Но с другой стороны, у вас есть 24 разных кулинарных книги о том, как готовить авокадо.

Видеть? Это так бесит. Шутки в сторону.

Программирование слишком неестественно и неинтуитивно, чтобы заниматься творчеством.

Я не говорю, что современные технологии программирования ужасны. Код отвечает за невероятный набор современных вещей, таких как реактивные самолеты, компьютеры, фондовый рынок и, в скором времени, возможно, даже разумный интеллект. Я просто прошу вас на минутку прекратить отладку этой ошибки градиента и представить, что было бы возможно, если бы мы могли кодировать так же легко, как рисовать рисунок ручкой на листе бумаги. Что, если бы мы могли сделать приложение так же просто, как описать его несколькими предложениями? Что, если бы мы могли создать логику для роботизированной руки, используя отношения, которые мы уже можем выразить физически? Что, если бы мы могли написать настолько безопасный код, что мы могли бы случайным образом экспериментировать с ним, чтобы открывать новые вещи?

Кодирование дает огромные возможности, которые были бы более доступными, предсказуемыми и мощными, если бы они были просто более приятными. Если вы мне не верите, попробуйте научиться программировать самостоятельно. Ваш первый месяц будет экстатическим пиком, когда вы почувствуете, что контролируете всю галактику. Но как только вы попробуете сделать что-нибудь в реальном мире с помощью кода, например, выпустить на рынок программный продукт, вы поймете, что я имею в виду. Есть причина, по которой жизнь технологических компаний Кремниевой долины настолько напряжена. Есть причина, по которой инженерам так хорошо платят в конкурирующих компаниях, которые полагаются на эту технологию.

Как нам снова сделать кодирование отличным?

В личном плане, если вы снимете все нагрузки с вашей деятельности по кодированию, такие как дедлайны или конкретные цели, и вместо этого сосредоточитесь только на опыте обучения, вы можете получать удовольствие от этого в течение долгого времени. Однако вы должны знать, что в отрасли преобладают люди, которые кодируют двенадцать часов подряд шесть дней в неделю. Бывают редкие случаи, когда двенадцатилетний ребенок придумывает самосознающий искусственный интеллект после двух месяцев написания кода на выходных, но поверьте мне, это не так просто.

В более широком смысле мы, программисты, должны взять на себя ответственность:

Единственная причина, по которой мы должны писать код, - это гарантировать, что мы будем писать меньше кода завтра.

Мы должны создавать инструменты, которые позволят людям что-то делать с кодом и просто заставить его работать. Или, по крайней мере, мы должны делать это даже удаленно возможным немного чаще, чем в 10% случаев. Нам следует придумывать творческие способы превращения простых требований и ограничений проекта в безопасный, масштабируемый код, а не изобретать все более и более абстрактные способы представления информации и взаимосвязей с кодом.

Мы должны сделать кодирование проще и мощнее. Когда мы это сделаем, мы раскроем творческий потенциал гораздо большего числа людей. Когда мы сделаем код более самофункциональным, мы сделаем так много работы гораздо более приятной. Что еще более важно, мы можем жить своей жизнью. Мы уже потратили достаточно времени.

Давай, люди. Кодирование - заноза в заднице. Слишком часто это заноза в заднице. Ты знаешь, что это правда. Пришло время отладить это дерьмо и сосредоточиться на влиянии того, что мы делаем, а не на том, как это сделать.