Привет, Хаброжители!

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

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

Подборка. Инструментарий художника

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

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

Обучение через искусство

В попытке воссоздать прогрессивный вариант непрерывного обучения, не преследуя при этом вездесущих экономических целей, исследователь истории культуры Йерун Луттерс (Jeroen Lutters) ввел понятие «обучение через искусство» (Art-Based Learning). Эта методика позволяет зрителю вступить в диалог с произведением искусства. Цель обучения через искусство — ответить на на сущные жизненные вопросы. Рассматриваемый объект может увлечь нас в приключения внутри нас самих и, как можно надеяться, привести к ответу на наш вопрос. Главную роль в этом подходе играет ассоциативное свободное мышление. Луттерс сравнивает данный метод с художественным самовыражением: «[Обучение через искусство] сродни художественному мимезису — неповторимому новому личному творению в результате внутреннего исследования».

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


Рис. 8.2. Четыре этапа обучения через искусство: (1) задайте вопрос и выберите произведение искусства; (2) дайте произведению искусства высказаться; (3) поймите возможности; (4) преобразуйте их в ответ

Прежде всего нужно задать (себе) актуальный вопрос. В своей диссертации Луттерс приводит такие примеры: «Почему я боюсь умереть?» и «Как мне получить больше удовольствия от жизни в данный момент?» После того как вы определитесь с вопросом, нужно выбрать произведение искусства — или же, возможно, оно выберет вас. Это может быть обычная книга, плакат или картина, которая привлекла ваше внимание в тот момент, сложный механизм или посещение концерта. По словам Луттерса, выбор объекта происходит в основном подсознательно, когда мы о чем-то мечтаем: «Мы не вольны использовать объекты только таким образом, иногда они выбирают нас». Таким образом, выбор требует не только способности приобретать что-либо, но также, и прежде всего, способности позволять этому быть приобретенным.

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

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

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

Очевидно, что обучение через искусство призвано помочь справиться с большими философскими вопросами в жизни, а не с прагматическими, на которые мы пытаемся ответить, например: «Почему не срабатывает моя точка останова?» или «Как можно сделать это асинхронным?». Как мы, программисты, можем интегрировать обучение через искусство в наше творческое решение проблем?

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

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

Собеседник 1. Думаю, что если я восхищаюсь творчеством, то это в основном относится к тому, как все складывается воедино. Простота и, знаете ли, сложность, представшая простой в существующем решении проблемы. Если отвлечься от ПО и IT, то это, например, хорошо сделанная транспортная развязка. Вот это действительно классно!

Собеседник 2. Раз уж вы об этом заговорили, та новая развязка, как мне кажется, прекрасно решена — пробок больше нет.

Собеседник 1. Точно!

Собеседник 2. И это было радикальным преобразованием.

Известный философ Ален де Боттон (Alain de Botton) и историк искусства Джон Армстронг (John Armstrong) в своей неоднозначной книге «Art as Therapy» предлагают новый взгляд на искусство, полагая, что оно может быть полезным, актуальным и терапевтическим. «Великие произведения дают нам подсказки, как справиться с напряжением и растерянностью в повседневной жизни», — утверждает де Боттон. Очень похоже на обучение через искусство! Пусть «Молочница» Яна Вермеера или новая транспортная развязка вряд ли дадут ответ на вопрос с кэшированием, над которым вы бьетесь, но внимательное изучение поможет нам лучше понять и искусство, и самих себя, находя тем самым подсказки, необходимые для успешной инвалидации кэша.


Рис. 8.3. Автомобильная развязка в Люммене (Бельгия), реконструированная в 2008–2012 годах. Было построено и перемещено 12 новых мостов (некоторые весили до 8000 тонн). Это элегантное инженерное решение вдохновило наших собеседников и может быть воспринято как нечто прекрасное, подобно произведению искусства. Фото любезно предоставлено Дэйви Говэртом (Davy Govaert)

Крадите как художник

«Крадите как художник» — название провокационного манифеста Остина Клеона (Austin Kleon), посвященного творчеству в цифровую эпоху, — не может не привлечь внимания. В этой книге Клеон перечисляет 10 вещей, которые он сам хотел бы услышать, когда начинал свою творческую карьеру:

1. Крадите как художник.
2. Не ждите, пока разберетесь в себе. Приступайте к делу!
3. Пишите книгу, которую сами хотели бы прочесть. [Готово!]
4. Старайтесь все делать руками.
5. Осознайте важность хобби и побочных проектов.
6. Хорошо делайте свою работу и делитесь ею с людьми.
7. Забудьте о географии — она больше не властна над нами.
8. Будьте хорошими (весь мир — большая деревня).
9. Будьте скучными (лишь так можно выполнить свою работу).
10. Воспринимайте творчество как умение вычитать.

Этот список лег в основу выступления в одном из колледжей Нью-Йорка, которое быстро стало вирусным в интернете. Можете ли вы найти сходство с семью областями решения творческих задач в этой книге (см. главу 1)? «Вычитание» — работа в условиях ограничений. «Быть скучным» означает быть настойчивым, находиться в потоке и проявлять твердость характера. Одна из иллюстраций в этой книге гласит: «Вам понадобятся: любознательность, доброта, выдержка, готовность выглядеть глупо». Совместная работа является главной темой главы 4.

Даже первый пункт, «крадите как художник», встречается во вступлении к главе 2, в котором мы увидели, что Kotlin был сознательно построен на плечах существующих гигантов, а Сенека нередко подглядывал в труды Эпикура, своего соперника в философии, и учился на них. В каком-то смысле эта книга появилась на свет таким же образом.

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

К сожалению, в мире разработки ПО плохое воровство — обычное дело. Например, недавний проект Microsoft GitHub Copilot под названием «Your AI pair programmer» («Ваш ИИ-партнер по парному программированию») на первый взгляд кажется весьма умной идеей, и скорее всего, так оно и есть. Однако «партнер» на основе искусственного интеллекта, предлагающий код и целые функции в режиме реального времени, обучается на миллионах строк кода, почерпнутых непосредственно из проектов на GitHub без учета лицензионных соображений. Никаких упоминаний об авторах сделано не было. Copilot, закрытый коммерческий продукт, стал возможен благодаря неэтичному присвоению тысяч часов программирования разработчиков продуктов с открытым исходным кодом и неприкрытому игнорированию их лицензий, большинство из которых на самом деле требуют надлежащего указания авторства. В конце концов организация Software Freedom Conservancy выступила с призывом «Give Up GitHub!» («Откажитесь от GitHub!»). Многие разработчики ПО с открытым исходным кодом переходят на другие решения, такие как Codeberg, Source Hut или экземпляры Gitea на локальном сервере. Вот и еще одна крупная технологическая компания, погнавшаяся за «бесплатными» данными.

Это случается слишком часто. Мне довелось работать в нескольких компаниях, где зависимости проекта радостно добавлялись (командой yarn add) безо всякой оглядки на файл LICENSING.md. У одного работодателя наблюдательного разработчика просто подняли на смех за замечание о том, что они используют программы по лицензии GPL, но при этом продают продукт с закрытым исходным кодом. Плохое воровство, говорит Остин Клеон. «Да кому какое дело?» — отвечают в компании.

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

Что получится, если скрестить жанр пинбола с жанром шутер? Получится Nitro Ball, аркадная диковинка 1992 года производства компании Data East, которая, вопреки всему, неплохо продавалась. А если смешать жанр двумерной исследовательской метроидвании с летающим пинболом? Получится Yoku’s Island Express (рис. 8.4), «платформенный приключенческий пинбол» 2018 года производства Villa Gorilla, в котором вы играете от лица навозного жука.


Рис. 8.4. Villa Gorilla каким-то образом умудрились использовать лучшие механики жанров метроидвания и пинбол, получив веселое приключение Yoku’s Island Express

УПРАЖНЕНИЕ Когда вы в последний раз «крали как художник»? Было это хорошее воровство или плохое воровство? Изучали ли вы материал или лишь поверхностно взглянули, как любят делать мои студенты? (Чего уж там, признаюсь, я и сам так делал!) Возможно, сейчас самое время быстро просмотреть зависимости вашего проекта и прописать их правильно. Плагины для доступа к этой информации есть во многих экосистемах программирования, например в Node.js (license-checker), Go (go-licenses), Gradle (gradle-license-plugin) и Elixir (licensir). Помните только, что не все лицензии совместимы между собой.

Сила свободного времени

Каждые семь лет графический дизайнер Штефан Загмайстер (Stefan Sagmeister) покидает свою студию и уходит в отпуск длиною в год. Во время этого длительного отдыха Загмайстер как губка впитывает все, что повстречает. Примечательные культуры, умиротворяющие леса, разрастающиеся города — все впечатления формируют основу его будущих творческих работ. Некоторые места, в которых он побывал, «спонтанно вызывали удивительное вдохновение».

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

Один год отпуска каждые семь лет означает, что вы посвящаете 12,5% времени тому, чему хотите. Много ли это? По сравнению с прежним правилом 20% у Google или правилом 15% у 3M это вообще-то меньше! Конечно, это «свободное» время на самом деле никакое не свободное, и дается оно с расчетом на то, что бизнес тоже получит свою выгоду. С 2011 года по мере своего экспоненциального роста Google начала урезать «свободное время» — предположительно для того, чтобы сосредоточиться на операционной стороне бизнеса и принять стратегию «большее количество ресурсов — меньшему числу продуктов».

Быть в творческом отпуске не значит не работать — это значит работать над тем, над чем хочется. Почти всегда это служит триггером для вдохновения на основной работе. Многие писатели, например психолог Дэниел Гилберт (Daniel Gilbert), пишут книги именно в отпуске. Гилберту повезло быть штатным профессором, что, очевидно, делает отпуск гораздо более осуществимым. Загмайстер в отпуске продолжал создавать и продавать произведения искусства. Насколько мне известно, некоторые психологи закрывают свою практику на четыре месяца, чтобы думать, писать, организовывать выездные семинары и ощущать вдохновение. Сбросить темп, чтобы дать место вдохновению, — одно из главных преимуществ длительного отдыха. Как свидетельствует Загмайстер, этого может быть достаточно для того, чтобы подпитывать творчество на протяжении многих лет: «Все, что мы спроектировали за семь лет, прошедших после первого отпуска, зародилось в том году».

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

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

Психологические исследования уже несколько десятилетий говорят о том, что эмоции и настроение оказывают глубокое влияние на наши когнитивные способности, включая креативность и аналитическое решение проблем. Эти выводы не находили подтверждения в исследованиях разработки ПО вплоть до недавнего времени, когда Даниэль Грациотин (Daniel Graziotin) и его исследовательская команда обнаружили, что на самом деле довольные жизнью разработчики решают проблемы более эффективно и более творчески.

Участниками исследования стали 42 студента факультета computer science, которые, очевидно, не могут рассматриваться в качестве настоящих разработчиков ПО. В последовавшем затем исследовании команда Грациотина опросила 317 опытных программистов о последствиях недовольства (или довольства)жизнью для их продуктивности и качества ПО. Программисты, чувствовавшие себя довольными, сообщили о положительных результатах, касавшихся как внешних процессов, так и собственного самоощущения.

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

Справедливо и обратное утверждение: сниженные творческие способности отмечаются как последствия неудовлетворенности.

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

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

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

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

Подборка. Инструментарий писателя

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

Быстрый поиск в интернете по запросу «методики творческого написания» (creative writing techniques) дает более двух миллиардов результатов, начиная с метафор, риторических вопросов, аллитераций, олицетворений, письма в свободной форме, диктовки и переписывания, а также структурирования действий — и заканчивая развитием сюжета и даже серьезными методами анализа данных для извлечения специфических языковых конструкций среди различных групп пользователей.

Эти бесконечные списки писательских методик менее убедительны, чем советы, сформулированные великими авторами. В последующих разделах вашему вниманию предлагается подборка таких советов, которые могут помочь улучшить написание кода в творческом плане. Многие инструменты уже знакомы вам по предшествующим главам.

Инструментарий Владимира Набокова

Набоков и сам всегда был готов дать совет в ходе различных интервью и лекций. В книге «Conversations With Vladimir Nabokov» под редакцией Роберта Голла эти интервью собраны воедино, чтобы составить обзор жизни и творчества этого русско-американского мастера литературы. Ниже приведены советы, которые показались мне уместными в контексте программирования.

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

Вдохновляйтесь миром вокруг. «Искусство писать — очень бесполезное занятие, если оно не подразумевает прежде всего видеть мир как потенциальную возможность для вымысла». Конечно, между написанием художественной литературы и реализацией требований бизнеса в ПО существует большая разница, но это не значит, что мы не можем вдохновляться тем, что видим вне мира IT. Например, почтовую службу, доставляющую нашу корреспонденцию, можно рассматривать как асинхронный брокер сообщений наподобие популярной программы RabbirMQ или платформы распределенной потоковой передачи событий Apache Kafka.

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

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


Рис. 8.5. Карточка с фрагментом сюжета, созданная по образцу порой беспорядочного набоковского метода написания романов. Сюжет меняется в зависимости от расположения карточек. Последняя книга Набокова, «Лаура и ее оригинал», опубликованная после его смерти, снабжена подзаголовком «Роман во фрагментах». В ней читателю предлагается менять сюжет повествования, вырезав репродукции настоящих карточек Набокова!

Стиль необходимо развивать. «Стиль не инструмент, не метод и не выбор слов. Стиль — нечто большее, чем все это. Он является неотъемлемым компонентом или характеристикой личности автора. Таким образом, когда мы говорим о стиле, мы имеем в виду своеобразную природу отдельного художника и то, как она выражается в его творчестве». Набоков продолжает: «Нередко в процессе литературной деятельности стиль писателя становится все более точным и впечатляющим». Программирование — это совместная деятельность в большей степени, чем писательство, но именно поэтому я думаю, что Набоков в чем-то прав. Наш (коллективный) стиль программирования не менее важен, чем выбор алгоритмов или фреймворков.

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

Инструментарий Джеффа Дайера

Английский писатель Джефф Дайер (Geoff Dyer), автор романов и публицистических произведений, получил множество наград за свои работы. Его советы писателям, которые он дает в многочисленных статьях в газете The Guardian, гораздо прагматичнее, чем рекомендации более эрудированного Набокова.

Не пишите в общественных местах. «Это нужно делать в уединении, как и все, что связано с личной гигиеной». Чувствуется кивок в сторону книги «В работу с головой» Кэла Ньюпорта: пишите (или программируйте!), закрыв дверь; перерабатывайте, открыв ее. Программирование требует сосредоточения. Идеализированная картина работы в кофейне не способствует сосредоточению. Если верить Дайеру, такое только активно мешает.

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

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

Если что-то оказывается слишком трудным, бросьте это и займитесь чем-нибудь другим. «Написание — это настойчивость, — поясняет Дайер. — Не опускайте руки». Как мы видели в главе 7, временно занимаясь чем-то другим, вы получаете дополнительное преимущество в виде подсознательной обработки трудностей.

Выработайте привычку. Пишите каждый день. Помните о настойчивости. «Постепенно это станет инстинктом». График работы некоторых писателей действительно впечатляет. Стивен Кинг, например, ежедневно пишет по десять тысяч слов. Неудивительно, что он является одним из самых плодовитых американских писателей нашего времени. Другие авторы довольствуются глубокой переработкой нескольких предложений. Пусть дело здесь не в количестве, но ежедневные привычки и вправду облегчают путь к творческому успеху.

Инструментарий Энн Ламотт

Книга Энн Ламотт (Anne Lamott) «Bird by Bird» — классический труд, раскрывающий боль, сострадание, любовь и страх писателя. По сравнению с советами Набокова и Дайера, советы Ламотт более личные и эмоционально насыщенные, но ничуть не менее важные. Ниже приводится подборка ее советов, которые показались мне особенно провокационными.

Напишите свою уникальную историю. «Все, что с вами случилось, принадлежит вам. Расскажите свои истории», — пишет Ламотт. Не бойтесь раскрыть свои питонические навыки как бывший программист на Python, ныне мыкающийся во вселенной Java. Речь не о синтаксисе — например, верблюжийРегистр (camelCasing) или змеиный_регистр (snake_casing), — а об изобретательных способах применения личного опыта для решения текущих задач в программировании. Сделать это можете только вы.

Просто сядьте. Вторя совету Дайера о выработке привычки, Ламотт пишет: «Старайтесь садиться каждый день в одно и то же время. Так вы приучите свое бессознательное к творческой активности». Вдохновение может прийти не сразу. Не нервничайте. Будьте терпеливы: «Вы смотрите на потолок, потом на часы, зеваете, потом снова смотрите на бумагу. Затем, возложив пальцы на клавиатуру, вы коситесь в сторону образа, формирующегося в вашем сознании, — сцена, местность, персонаж, да что угодно — и пытаетесь успокоить свой разум, чтобы услышать, что хочет сказать этот пейзаж или персонаж, говоря громче, чем другие голоса». Во время наших опросов, посвященных творчеству, некоторые программисты говорили, что они «просто садятся и начинают писать». Они не утруждают себя соблюдением синтаксиса и обычно набирают глобальные идеи в псевдокоде, чтобы просто «все это выложить». Затем они обращаются за помощью к другим и постепенно преобразуют это в работоспособное решение.

Не притворяйтесь. Ваши конечные пользователи сразу заметят это: «Вы должны исходить из того, что мы, ваши читатели, умны и внимательны, даже если за последние несколько лет мы и сдали позиции. Поэтому если вы попытаетесь притвориться, мы вас поймаем». Ламотт пишет о том, что ваши читатели умны и внимательны. В программировании это не ограничивается конечными пользователями! Ваших нынешних и будущих коллег, которые, скорее всего, будут читать ваш код большее число раз, нежели вы, также не стоит дурачить пустой болтовней. Креативные программисты учитывают интересы конечного пользователя, будь ПО игрой, административным веб-приложением или мобильным приложением для парковки. При возможности встретьтесь с ними, узнайте их и мир, в котором они живут, и тщательно проанализируйте их бизнес-потребности. Критически отнеситесь к сыроватыму профилю клиента и такой же бизнес-логике. Только потом пишите код с учетом потребностей клиентов.

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

Пишите шаг за шагом («птицу за птицей»). Иногда не знать, куда направляешься, совершенно нормально. Упрямо сосредоточиваться на цели означает закрывать глаза на все, что встречается на пути. Ламотт цитирует романиста и профессора Э. Л. Доктороу: «Писать роман — все равно что вести машину ночью. Ты видишь только то, что освещают фары, но так можно проехать всю дорогу». Достаточно просто смотреть немного вперед.

Перестаньте гнаться за совершенством. По словам Ламотт, «перфекционизм — это голос угнетателя, врага народа. Он всю жизнь будет сковывать вас и сводить с ума, и он является главным препятствием, стоящим между вами и дерьмовым первым наброском». Она продолжает:

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

УПРАЖНЕНИЕ Представьте себе, что новый коллега спрашивает у вас совета, касающегося написания кода. Что вы ответите? Сошлетесь на руководство по стилю программирования, принятое в команде? Сядете и расскажете историю личного успеха? Передадите ему свой экземпляр книги Роберта Мартина «Чистый код»? Или вместо того, чтобы отвечать сразу, предложите попрограммировать в паре на этой неделе?

Наше догматичное «я» нет-нет да затеет переделку и рефакторинг какого-нибудь фрагмента кода до тех пор, пока это не превратится в бесполезное занятие.

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

Подборка. Инструментарий программиста

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

Разработчикам ПО известно больше творческих методик, чем они готовы признать. Каждые две недели я вижу, как они применяются в ретроспективах, основанных на превосходной книге «Agile Retrospectives» Эстер Дерби (Esther Derby) и Дианы Ларсен (Diana Larsen) или веб-сайтах наподобие https:// funretrospectives.com. И все же я задаюсь вопросом: почему мы не обращаемся к этим методикам вне переговорки? Чем плохи вариации животворящих ретроспектив, например Triple Nickels, в процессе разработки? Подход Triple Nickels заключается в следующем. Вначале малые группы проводят мозговой штурм — каждый участник записывает свою идею на листе бумаги. Через пять минут каждый передает свой лист бумаги соседу справа, который за следующие пять минут развивает доставшуюся ему идею, и так до тех пор, пока лист не вернется к тому, кто написал на нем первым. Это отличный способ быстро выявить ограничения для своей идеи и придать ей силу, не рискуя сразу отбросить менее традиционные идеи. Такие небольшие, но забавные упражнения можно организовывать по случаю, когда программирование заходит в тупик. Преодолевать препятствия нужно на спринтах, а не между ними.

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

Инструментарий Анны Бобковска

В 2019 году исследователь в области разработки ПО Анна Бобковска (Anna E. Bobkowska) изучила потенциал креативных методик разработки ПО с использованием особого цикла «обучение — применение — обратная связь» (training — application — feedback). Участники завершили эксперимент с более высокой оценкой креативных методик и отметили, что в сочетании друг с другом эти методики могут принести пользу на практике. Бобковска подробно описала следующие семь методик:

• Задавать наивные вопросы, что позволит обнаружить скрытые предположения и неявные знания («Представьте, что на этой странице понадобится только одна форма!»).
• Задаваться вопросом «Что, если...» или искать скрытые последствия («Что, если я нажму кнопку Submit двадцать раз подряд?»).
• Завершать предложения «Я мог бы быть более креативным, если бы...», чтобы понять, какие препятствия стоят перед вами лично («Я мог бы быть более креативным, если бы на прогулки с мыслями наедине не смотрели косо»).
• Использовать методику Lunette: рассматривать проблему на разных уровнях абстракции (переключаясь между обобщением и специализацией; тщательно разбирая код и окидывая взглядом общую картину).
• Использовать реверсивный мозговой штурм: вначале высказать критику, а затем мотивировать к улучшению («Что вам не нравится в структуре базы данных?»).
• Использовать то, что Бобковска называет Китайским словарем (данная технология выросла из сопоставления старинной таксономии животных и современных таксономий), методику для создания нетипичных классификаций (создание необычных таксономий проблем, связанных с проектом).
• Применять методику «Давайте их пригласим»: использовать паттерны креативности (воображаемых) экспертов в области творчества («Допустим, мы пригласим Линуса Торвальдса. Что бы он сказал об этом?»).

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

Собеседник 1.… или вот о нестандартном мышлении. Мы недавно применили кое-что в ретроспективе — методику, с помощью которой можно выяснить, какими способами мы можем сломать систему. Найти, где и что может пойти не так, взглянув на это дело под другим углом, так сказать.

Собеседник 2. Да, я постоянно делаю это в неявном виде при моделировании. Например, если это решение, то что произойдет в таком-то случае, сломается ли оно? Если сломается, то как мы это обработаем? Если нет, то переходим к следующему решению, которое с этим справится.

Часто затрагивалась и тема «очистки луковицы» повторяющимся вопросом «Почему?» — как в диалогах, так и в монологах. Доказано, что размышления вслух, которые ученые называют самонаправленной речью, помогают мозгу работать эффективнее при визуальной обработке информации. Если объяснить проблему кому-либо — или чему-либо, — будь то отладка методом резиновой уточки, подходящий рисунок на стене (как в обучении через искусство), ваш кот или коллега, часто решение чудесным образом приходит само собой. Объяснение или даже преподавание заставляет нас сбавить темп и рассмотреть проблему с разных сторон, после чего обычно приходит более глубокое понимание.

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

Мозговой штурм: отрицательные стороны

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

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

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

Инструментарий прагматичного программиста

Культовая книга «The Pragmatic Programmer» рекомендует каждый год изучать новый язык программирования. У каждого языка есть руководство, стиль, преданные последователи и уникальный подход к решению проблем. Чем больше вы знаете языков программирования, тем более вероятно, что вы сможете творчески комбинировать и преобразовывать наработки на одном языке в другой, хотя, как было упомянуто в главе 4, нужно остерегаться межъязыковых коллизий.

Брюсу Тейту (Bruce Tate) не понравились рекомендации Энди Ханта и Дэйва Томаса. Всего один язык в год? Почему не семь за семь недель? В книге «Seven Languages in Seven Weeks» Тейт дает практические советы о том, как быстро изучить новый язык программирования, основываясь на своем опыте изучения семи языков за два месяца. Успех книги через четыре года вылился в неизбежное продолжение — «Seven More Languages in Seven Weeks». Книги Тейта охватывают технические аспекты языка и дают читателю представление о том, как сложные задачи решают другие программисты из самых разных сообществ.

Умение мыслить в терминах нескольких языков — эффективный способ решения сложных проблем в коде. Представьте, что вы застряли с какой-либо проблемой и не представляете, как двигаться дальше, используя все ту же технологию. Но что, если вы умели бы писать код на JavaScript? Или на Elixir? Или на Kotlin? Легко ли было бы решить проблему, воспользовавшись указателями языка C? Или рефлексивной расширяемостью Ruby? А если бы вы могли выразить ее на функциональном языке? Стало бы проще или сложнее? Как насчет конвейеризации filter() и map()? А что там у нас с обнуляемыми типами из других языков? Следует ли выражать бизнес-логику на языке Prolog? Принесут ли пользу преимущества скриптового языка, например Squirrel? Может быть, для выражения логики использовать собственный язык, специфичный для конкретной области?

Если что-то не может быть сделано средствами одного языка, попробуйте другой. И еще один. И еще один. Что, уже седьмой? Возможно, хорошим вариантом будет обратное портирование идеи. Возможно, ваша виртуальная машина способна интерпретировать язык: Ruby и Python работают на JVM и CLR, Clojure — диалект Lisp на JVM, а код на JS в наше время выполняется на чем угодно.

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

Что не является творческим, так это когда вы, ну, находитесь в этом режиме синтаксических ошибок — вот это экстрим! Вы все набрали, а теперь надо это запустить (смех), а вам еще нужно исправить три или четыре запятые, в зависимости от языка, которые не там стоят, и это займет больше времени. А еще механические ошибки в модульных тестах. И что еще я записал, так это новые технологии, если вы читаете документацию к чему-то новому, как оно работает, как работает этот протокол...

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

Вдобавок к рекомендации каждый год изучать новый язык книга «The Pragmatic Programmer» ввела в мир разработки ПО понятие «ката» из области боевых искусств. Упражнение ката обычно представляет собой фрагмент кода, который переписывается раз за разом для развития мышечной памяти и наработки практических навыков, подобно хореографии в боевых искусствах.

Самым популярным упражнением ката с кодом, которое я знаю, является, пожалуй, игра в боулинг. Когда все вспоминают правила игры, программисты пытаются реализовать их с использованием подхода «сначала тест» (test-first). С чего начать? Создать класс Game? Или Player, или ScoreCalculator? Стоит ли использовать наследование, чтобы повторно использовать логику подсчета очков для спэров и страйков? Такое простое на первый взгляд задание может привести к полной неразберихе в коде. Если так случится, пора все бросить и попробовать заново.

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

УПРАЖНЕНИЕ Разбейтесь на пары и постарайтесь реализовать функцию или ее небольшое подмножество. Теперь пусть ваш напарник вернет все обратно — как обидно, не правда ли? Работая в одиночку, откатывайте изменения сами и представьте, что это код, который написал ваш коллега. Сможете ли вы сделать лучше него? Не все потеряно: возможности изучены и варианты рассмотрены. Изучены новые способы мышления. Следующая итерация точно будет лучше.

Инструментарий Эмили Морхауз

В 2015 году Эмили Морхауз (Emily Morehouse) впервые посетила конференцию PyCon в Монреале (Канада). На ней Гвидо ван Россум (Guido van Rossum) — создатель языка Python — объявил о поиске женщин-разработчиков Python Core (Python Core Developer), поскольку на тот момент таковых не существовало. Прошел еще год, прежде чем Эмили решилась ответить на это предложение, только она по-прежнему не имела ни малейшего представления о том, с чего начать и чем на самом деле занимается разработчик ядра. К счастью, ее наставником выступил сам Гвидо.

Как видно из рис. 8.6, исходный код CPython огромен: в нем содержится свыше 500 000 строк кода на C и 629 000 строк кода на Python. С чего же начать работу в таком громадном и долгосрочном проекте? Исправлять мелкие ошибки, о которых сообщается на GitHub, смысла нет: самые простые, разумеется, уже исправлены. Поэтому Эмили под руководством наставника начала изучать исходный код. В результате она поняла, как работают другие разработчики ядра, какие паттерны применяются многократно, как принимаются решения и, возможно даже, где требуется что-то улучшить.

Изучая чужой исходный код, можно извлечь ценные уроки, которые пригодятся и в нашей работе, совсем как в манифесте Остина Клеона «Крадите как художник». Спросите совета у любого писателя. Первое, что он скажет: «Больше читайте». Чтобы стать хорошим писателем, вначале нужно стать хорошим читателем.

Меня озадачивает, как мало мы, программисты, сознательно читаем и учимся на чужом коде, особенно за пределами нашего уютного кода проекта. В прежних группах чтения были книги о программировании, но кода свободного и открытого ПО (free and open source software, FOSS) не было никогда. Чтобы стать хорошим программистом, вначале нужно стать хорошим читателем. И возможно, писать тоже нужно. Известный хакер и поборник ПО с открытым исходным кодом Эрик Реймонд (Eric S. Raymond) в своей статье «How to Become a Hacker» советует именно писать, а не кодить (см. главу 1, в которой описан пример рабочего процесса написания).


Рис. 8.6. График истории развития кодовой базы CPython с разбивкой по годам. Он дает представление о том, как развивался и разрастался код на протяжении более чем 28 лет. Основан на данных, собранных Пабло-Галиндо Сальгадо (Pablo Galindo Salgado). Сгенерирован с помощью инструмента git-of-theseus, доступного на GitHub, созданного Эриком Бернардссоном (Erik Bernhardsson)

Социальные платформы программирования, такие как GitHub и GitLab, являются хорошим подспорьем в чтении и понимании кода FOSS. Многие из тамошних крупных проектов активно ищут участников. Пусть продираться через неиссякаемый поток проблем и строк кода может быть страшновато, но участие в FOSS — это прекрасный способ отточить свои инструменты креативного программиста.

Если ваши амбиции столь же серьезны, как намерение Эмили Морхауз стать Python Core Developer, то наличие наставника, который будет проверять, как у вас идут дела, вовсе не является роскошью. Эмили призналась, что без помощи ментора она не справилась бы. Наставник может воссоздать столь необходимый контекст, который в противном случае остался бы вне поля зрения. Отдельные фрагменты кода становятся реликтами, которые никто больше не осмеливается трогать. Почему в этом файле собраны эти странные функции C? Почему не использовать x или y? Без надлежащего документирования эти коллективные знания быстро затеряются во времени.

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


Более подробно с книгой можно ознакомиться на сайте издательства:

» Оглавление
» Отрывок

По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
Для Хаброжителей скидка 25% по купону — Программист