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

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

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

Вот пять уроков, которые я усвоил.

Знайте, что вы пытаетесь сделать

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

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

В кодировании это связано с концепцией, которую я называю «Мистер. Heckles scoping »по любимому герою сериала« Друзья ». Мистер Хеклз, сосед главных героев внизу, появлялся два или три раза за сезон, чтобы стучать в их дверь, после чего начинался разговор, который проходил примерно так:

Мистер Хеклз: Вы говорите громко. Мои кошки не могут спать.

Моника: У вас нет кошек.

Мистер Хеклз: Я мог бы завести кошек.

Я сам сталкивался и демонстрировал это отношение гораздо больше раз, чем мне хотелось бы вспомнить. Создаете серверную часть редактора изображений? Лучше убедитесь, что он поддерживает TIFF, PCX и все другие форматы, которые никто не использует! Делаете графический движок для моей игры? Давайте добавим еще два уровня абстракции на случай, если я передумаю и переключусь со спрайтов на 3D-модели! Конечно, не собираюсь. Я даже ничего не знаю об OpenGL. Но я мог.

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

Перестань волноваться и начни

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

Задача достаточно проста: нарисуйте три линии, соединяющие совпадающие буквы. Линии не могут пересекать друг друга, границу прямоугольника или какие-либо буквы, которые они не соединяют (хотя ни одна из них не должна иметь форму котенка). Не стесняйтесь немного поразмышлять, но просто для того, чтобы двигаться дальше, вот решение:

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

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

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

Не умничай ради ума

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

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

В качестве классического примера возьмем следующие два фрагмента кода:

// Snippet A
for (let i = 0; i < buffer.length; i++) {
    buffer[i] = 0;
}
// Snippet B
for (let i = 0, l = buffer.length; i < l; buffer[i++] = 0);

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

Постарайтесь время от времени останавливаться и смотреть на свою работу чужими глазами; желательно хотя бы после хорошего ночного сна. Рассказывает ли он достаточно ясную историю? Интуитивно ли понятны ваши подписи API? Насколько хорошо кто-то может использовать ваш код без вашего объяснения? Практика чистого, прямого письма может помочь вам развить инстинкт чистого и простого кодирования. Немного менее впечатляюще, намного проще для тех, кто подменяет вас на больничный.

Будь самим себе критиком

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

Опровержение - это краткий сегмент, в котором вы останавливаетесь, чтобы поразмыслить над собранными вами аргументами, и обращаетесь к моментам, с которыми, по вашему мнению, скептически настроенный читатель может не согласиться (например, «Можно беспокоиться, что мое предложение о героине, поставляемом компанией, может привести к падению представление."). В большинстве случаев вы будете предлагать контраргументы или уверять читателя, что их опасения необоснованны. Однако так бывает не всегда. Вы вполне можете пойти на компромисс или даже откровенно признать, что не знаете однозначного ответа. Смысл опровержения не в том, чтобы опровергнуть мнение оппонента; чтобы показать, что вы учли их при формировании своей собственной.

Мы, программисты, живем в мире шаблонов. Нашей работой руководят устоявшиеся правила и условности, основанные на миллиардах часов коллективного опыта. Тем не менее, мы часто обнаруживаем, что конкретная ситуация требует решения, которое просто не охватывается нашими шаблонами. Когда вы идете против течения, важно иметь возможность сделать шаг назад и обдумать свои решения. Какие опасения могут возникнуть у постороннего человека по поводу вашей работы и как бы вы их разрешили?

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

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

Научись отпускать

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

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

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

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

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