Писать код и создавать литературное произведение — схожие занятия. Эта мысль давно зрела у меня в голове. Оба ментальных процесса используют языковые конструкции, рассчитаны на определенную аудиторию и требуют значительной концентрации внимания, чтобы быть эффективными. На протяжении более двух десятилетий я писал код, создавал бесчисленные технические документы и статьи, а недавно решил овладеть искусством беллетристики. В чем же схожесть этих занятий?
Язык
И код, и проза пишутся на определенном языке. Мои художественные тексты написаны на английском, а код я писал на C, Java и Perl, хотя досконально освоил Python.
Точно определить словарный запас английского языка не так-то просто. По приблизительным подсчетам в него входит примерно 470 000 слов. Типичный носитель английского языка знает от 20 000 до 35 000 слов в зависимости от уровня образования.
Python, как и большинство языков программирования, содержит очень небольшой набор ключевых слов и конструкций. Его истинная ценность заключается в общих библиотеках, называемых pip’ами (pip — package installer for Python, установщик пакетов для Python). PyPi (Python Package Index, каталог пакетов Python) — хранилище этих библиотек — насчитывает 498 650 проектов, или pip’ов (по состоянию на 5 декабря 2023 года). В небольшом проекте, над которым я недавно работал, было 68 таких проектов.
Возможно, нелепо сравнивать количество слов в английском языке с количеством пакетов в PyPi. Но нельзя не согласиться с тем, что и английский, и Python — очень богатые языки, недоступные человеческому разуму в полном объеме.
Компиляторы
Концепция компилятора довольно проста: перевести человекочитаемый код в машиночитаемые инструкции. В приведенном ниже примере код на языке Python должен десять раз напечатать “Hello World!”, а справа показан сгенерированный код на языке ассемблера. Я не умею читать код на языке ассемблера, который является совершенно непонятным для меня языком. Но это неважно, потому что компьютер может его прочитать и выполнить.
При чтении литературного произведения мозг читателя становится компилятором, переводящим слова с экрана или бумаги в осязаемые мысли и образы, даже если эти слова не совсем привычные. Великий автор может описать сцену так ярко, что вы увидите ее в своем воображении, хотя слова, использованные в произведении, — всего лишь пиксели или чернила.
Моим любимым местом в абсурдистском романе Стивена Ликока “Гувернантка Гертруда” являются строки: “Он стремительно выскочил из комнаты, столь же стремительно вскочил на коня и, как безумный, готов был скакать во все стороны”. Здесь, казалось бы, нарушена всякая логика, поскольку последняя часть предложения, строго говоря, нонсенс. Однако наш разум способен уловить игру слов и вызвать в воображении яркий захватывающий образ растерянного человека, мысли которого разбегаются в разные стороны, как взбудораженные кони. Компилятор выдал бы ошибку типа:
HorseError: Конь может скакать только в одну сторону.
ChatGPT также пытается осмыслить приведенные строки, и это лучшее, что он может сделать.
Аудитория
У каждого писателя есть своя аудитория, даже если он не осознает или не хочет этого.
Прозаик может писать дневник, который никто никогда не увидит, и тогда его аудитория — это он сам. Или же он пишет книгу, которая должна попасться на глаза издателю. Или создает техническую документацию, которая, как и многое из того, что я написал за свою профессиональную деятельность, адресована коллегам, стремящимся понять, почему что-то устроено так, а не иначе.
У разработчиков программного обеспечения есть две аудитории. Первая — это компилятор и среда выполнения, ведь ПО, которое не компилируется или не запускается, или, что еще хуже, работает при запуске некорректно, бесполезно. Но гораздо более важная аудитория — это другие разработчики, которым придется читать или редактировать код.
Написать нечитабельный код довольно просто. Куда сложнее написать код, который другой разработчик сможет легко понять. Берегитесь: этим следующим разработчиком можете оказаться вы. Бесчисленное количество раз я задавался вопросом: “Кто написал эту чушь?”, и однажды команда “git blame” (позволяющая узнать, кем редактировался код в последний раз) показала, что несколько лет назад автором был я.
Чтобы увидеть впечатляющие примеры функционального, но совершенно нечитаемого кода, просмотрите материалы конкурса “Самый запутанный код на языке C”. Помните: после того, как вы написали код, кто-то должен его поддерживать, и этот будущий разработчик — ваша аудитория.
Генеративный ИИ в качестве помощника
Недавно я начал писать беллетристику, которая по качеству напоминает стихотворчество вогонов и никогда не должна увидеть свет (Прим переводчика: вогоны — вымышленная инопланетная раса из романа Дугласа Адамса “Автостопом по галактике”; поэзия вогонов была настолько ужасна, что воспринималась как форма пытки). Однако я обнаружил, что ChatGPT может стать отличным помощником в писательских исследованиях. Действие моей истории происходит в Ирландии во время Великого голода 1840-х годов. Я был готов потратить несколько месяцев на исследование прошлого Ирландии, но в конце концов удовлетворился ответами ChatGPT на ключевые вопросы:
- Какие ирландские имена были в обиходе в 1840-х годах?
- Сколько зарабатывал рабочий на ферме?
- Сколько стоил билет на поезд?
- Как назывался корабль, следовавший из Дублина в Квебек в 1847 году?
ChatGPT охотно отвечал на мои вопросы. Возможно, неправильно, но достаточно быстро, чтобы я мог писать без перерывов и дорогостоящих заграничных поездок, прекрасно понимая: если вогоны когда-нибудь решат опубликовать написанное мной, им придется провести серьезную проверку фактов.
Что касается кода, то я подписался на GitHub Copilot и очень им доволен. Временами он галлюцинирует, а иногда и вовсе ошибается. Но самая лучшая его особенность заключается в том, что он понимает контекст работы. Однажды, подзабыв, как создать многострочную строку в Python, я спросил его: “Как сделать строку 43 многострочной, чтобы ее длина не превышала 120 символов?”, и он переписал строку за меня.
Я также попросил его создать шаблон AWS CloudFormation со специфическими функциями. Сделал это отчасти из-за лени, отчасти для проверки GitHub Copilot. И хотя в шаблоне было несколько ошибок, на 95% он оказался правильными. GitHub Copilot — это инструмент на базе ИИ, напоминающий опытного разработчика, который сидит рядом с вами и к которому всегда можно обратиться с вопросами.
Вокруг генеративного ИИ сегодня слишком много шумихи. К тому же он может допускать серьезные ошибки. И все же для писательского арсенала это дополнительный инструмент, на изучение которого стоит потратить немного времени.
Обстановка и инструменты
Для создания бестселлера, как и для написания эффективного кода, необходимо полное погружение автора в рабочий процесс, о чем пишет Кэл Ньюпорт в своей книге “Deep Work” (“В работу с головой”). Сосредоточенный труд требует спокойной атмосферы без помех. Чтобы войти в такой режим, нужна практика. К сожалению, большинство компаний, занимающихся разработкой ПО, не осознают этого, создавая множество отвлекающих от работы факторов — в виде уведомлений из Slack, Teams и Email, а также совещаний. В результате страдает качество программного обеспечения.
Рабочие инструменты писателей и разработчиков многочисленны и разнообразны. Для писателей это может быть ручка и бумага, Microsoft Word, Google Docs или что-то другое. Я использовал при написании этой статьи Google Docs, потому что данный текстовый редактор отличается безотказным функционалом, позволяя сосредоточиться на работе. Инструментарием для разработчиков программного обеспечения является, как правило, IDE, например IntelliJ или VSCode. Я твердо убежден, что не следует навязывать автору какой-то определенный инструмент: это мешает погружению в работу. Руководитель, нанимающий создателей текстов или кода, должен относиться к ним как к самому дорогому активу и понимать: несколько дополнительных долларов, потраченных на инструменты, выбранные этими сотрудниками, сделают их работу намного продуктивнее.
Писательство — это искусство
Создание прозы — это определенно искусство, хотя даже сухая техническая документация может быть написана искусно. Большинство разработчиков, включая вас, будут утверждать, что написание кода — это тоже искусство. Есть много плохого искусства, настолько непотребного, что существует даже Музей плохого искусства (рекомендую посетить). Писательство также породило несколько потрясающе уродливых прозаических произведений.
Если написание кода — это искусство, то можно сказать, что и оно не без урода, поскольку в нем можно найти ужасающе плохой код. Код, представленный на конкурсе “Самый запутанный код на языке C”, намеренно ужасен, хотя большинство разработчиков программного обеспечения сталкивались в своей практике с настолько плохим кодом, что лучше “выкинуть” его и переписать, чем пытаться исправить. Думаю, какая-то часть моего программистского творчества тоже попадает в эту категорию.
А иногда вы натыкаетесь на код, который можно назвать шедевром искусства: его легко читать и понимать, он эффективен, хорошо документирован и мастерски выполнен во всех отношениях. Если же вам приходится вносить изменения в такой код, вы как художник, реставрирующий знаменитую картину, отчаянно пытаетесь не испортить ее.
Неудачи
В книге “25 советов начинающим разработчикам” сказано: “Привыкайте к неудачам”. Этот совет относится как к коду, так и к прозе. Писать код сложно, освоение среды выполнения требует долгого обучения. Писать тексты, особенно художественные, не менее трудно. Как я убедился на примере своей истории в духе вогонов, придумывать диалоги и создавать персонажей с нуля чрезвычайно сложно. Неудачи на этом пути неизбежны. Я удалял целые блоки кода и целые главы своих беллетристических опусов, в обоих случаях начиная заново и используя знания, полученные в результате неудач, что в итоге помогло мне улучшить свои навыки.
Будем учиться друг у друга
На Medium немало информации о том, как стать успешным разработчиком. Если написание кода и прозы — одно и то же, то многие советы, адресованные писателям, должны быть применимы и к разработчикам программного обеспечения. Эту статью о методике работы Стивена Кинга можно легко перенести на написание программного кода. Конечно, создать такую же обстановку для штатного разработчика ПО сложнее, но это возможно. На ранних этапах работы над проектом Arctic Wolf мы много говорили о том, как сформировать подходящую рабочую среду без отвлекающих факторов, с большими блоками времени (а иногда и целыми днями) без совещаний. В то время у меня были одни из самых продуктивных периодов работы.
Если в статье “25 советов начинающим разработчикам” заменить слово “код” словом “проза”, то большая часть рекомендаций будет применима и к начинающим писателям. Такие советы, как “Ищите сообщество”, “Определите свою нишу”, “Сначала сосредоточьтесь на основных принципах” и “Создавайте проекты, которые вам нравятся”, можно применить к написанию текстов любого типа.
Теперь идите и пишите!
Вернер Фогельс, технический директор AWS, всегда заканчивает свои программные выступления словами: “Теперь идите и создавайте!” Неважно, код или прозу… Теперь идите и пишите!
Читайте также:
- Как сделать чистый код еще чище
- Принцип открытости/закрытости: расширение кода без модификации
- Плохого кода не существует!
Читайте нас в Telegram, VK и Дзен
Перевод статьи Michael Hart: Writing Code is the Same Thing as Writing Prose
