Между кодом и романами: как две профессии уживаются в одной голове
Я программист.
Да, девочка. Да, программист. Одиннадцать лет уже, полёт нормальный.
А ещё десять лет я пишу книги. Хотя истории в моей жизни появились даже раньше: где-то с 2012 года я сидела на форумных ролевых играх, придумывала персонажей и писала километры текста вместо того, чтобы заниматься чем-нибудь общественно полезным.
Поэтому красивой истории «я бросила скучный мир IT и ушла вслед за мечтой» здесь не будет. Я всё ещё работаю программистом, люблю свою профессию и увольняться не собираюсь. Просто почти всю взрослую жизнь параллельно пишу код и романы.
Долгое время мне казалось, что эти занятия вообще никак не связаны.
В одном есть требования, архитектура, базы данных, код, тестирование и баги. В другом — персонажи, сюжетные линии, конфликты и несколько сотен тысяч знаков художественного текста.
А потом я начала замечать, что смотрю на роман примерно теми же глазами, которыми каждый день смотрю на код.
Профдеформация? Давайте разберемся.
Если оно не работает, я хочу знать почему
Потому что, собственно, это половина моей работы.
Программист постоянно получает задачи примерно следующего уровня информативности:
— Не работает.
Спасибо.
Что именно не работает? Что должно было произойти? Что произошло вместо этого? Ошибка воспроизводится всегда или только по вторникам у одного конкретного пользователя из Саратова? Что приходит на вход? Что получается на выходе? Где в цепочке ожидаемое поведение превращается в неожиданное?
Если программист на любую такую задачу просто переписывает кусок кода, пока проблема случайно не исчезнет, — это очень плохой программист.
Сначала нужно локализовать ошибку. Потом понять причину, и только потом исправлять.
Поэтому фраза «мне не нравится эта сцена» вызывает у меня примерно те же чувства, что «у нас сайт сломался».
Прекрасно.
А конкретнее?
Герой ведёт себя как идиот? Хорошо. Он должен сейчас вести себя как идиот — или мне просто понадобилось временно отключить ему мозг ради следующего сюжетного поворота?
Диалог скучный?
Конфликт закончился?
Сцена ничего не меняет?
Герои говорят не потому, что им есть что сказать друг другу, а потому что мне нужно сообщить читателю информацию?
А может, со сценой вообще всё нормально и проблема появилась пять глав назад?
Последний вариант особенно прекрасен, потому что ты два часа переписываешь диалог, а потом находишь место за сто тысяч знаков до него, где герой узнал что-то слишком рано. Теперь его нынешняя реакция не имеет смысла.
На работе это называется обычный вторник:
Ошибка проявилась здесь. Причина находится совсем в другом месте. Ищи.
У писателей тоже есть технический долг
В разработке технический долг появляется, когда ты сознательно выбираешь неидеальное или временное решение (костыль) сейчас, понимая, что когда-нибудь за него придётся заплатить.
Ключевое слово — когда-нибудь.
Обычно оно наступает в максимально неудобный момент.
У писателей есть ровно то же самое. Просто мы называем его:
«Потом придумаю».
Почему герой это умеет? — Потом придумаю.
Чего на самом деле хочет антагонист? — Потом.
Как работает эта важная штука в мире? — Да господи, у меня сцена пишется, разберёмся!
Проблема технического долга и там, и там одна: пока проект маленький, решение кажется дешёвым.
А потом вокруг него начинает расти всё остальное.
У романа уже 400 тысяч знаков, и выясняется, что маленькое «потом» из пятой главы успело дать детей, взять ипотеку и пустить корни в половину сюжета.
Просто удалить нельзя — на него опирается другая сцена, из которой уже вырос конфликт. Конфликт заставил героя принять решение, а решение привело нас в финал.
Поздравляю.
Legacy.
И теперь тебе нужно разбираться в коде, который написала ты сама три месяца назад.
То есть в романе.
Хотя иногда разница уже не чувствуется.
«Я тут совсем маленькую правку внесла»
У этой фразы в разработке плохая репутация.
Потому что системы состоят из зависимостей. Меняешь одно — и иногда совершенно неожиданно обнаруживаешь последствия в другом месте.
Казалось бы, поменяли одну мелочь. Почему теперь лежит половина проекта?
Хороший вопрос.
В романе работает абсолютно так же.
— Я только возраст героя поменяю.
На два года. Маленькая правка.
Возраст поменяли, но...
Теперь не сходится образование.
Если меняем образование — он не мог в нужный момент работать там, где работал.
Если он там не работал — не познакомился с другим персонажем.
Если они не познакомились — не произошло событие, которое через восемь глав запускает основной конфликт.
Через два часа я переписываю половину сюжетной линии и пытаюсь вспомнить, с чего всё началось.
С возраста.
На два года.
Всё потому, что роман тоже состоит из зависимостей.
Персонаж получает информацию — информация влияет на решение. Решение меняет отношения. Изменившиеся отношения влияют на следующий выбор. Один выбор закрывает возможность другого.
В программировании часть таких зависимостей можно найти инструментами.
В романе Word почему-то отказывается подчеркнуть красным место, где герой в двенадцатой главе знает то, чего ему никто не рассказывал.
Считаю это серьёзным недостатком продукта. Microsoft, обратите внимание.
Хорошая архитектура тоже экономит нервы
В программировании архитектура нужна не для того, чтобы нарисовать красивую схему и почувствовать себя серьёзным человеком.
Она нужна, чтобы большой проект не превратился в клубок, где изменение одной функции требует переписать всё приложение.
С романами я отношусь к структуре примерно так же.
Я не обязана заранее знать каждую реплику каждого персонажа. Но чем больше история, тем важнее понимать её основные узлы: кто чего хочет, какие линии куда идут, какие события обязательны и что из чего вытекает.
Потому что на двадцати тысячах знаков можно позволить себе сказать: «Разберусь по дороге».
На четырёхстах тысячах это уже угроза. Особенно когда персонажей много, у каждого свои интересы, а несколько сюжетных линий должны сойтись в одной точке.
Тогда внезапно выясняется, что свобода импровизации прекрасно работает до тех пор, пока у проекта есть каркас.
Это, пожалуй, один из самых очевидных подарков программирования моему писательству:
Большая система не перестаёт быть творческой только потому, что у неё есть архитектура. Она просто реже падает.
Но персонажи отказываются компилироваться
А вот здесь аналогия ломается.
Потому что программа при одинаковых условиях должна вести себя предсказуемо.
Люди — нет. Даже вымышленные.
Герой может прекрасно понимать, как правильно, и сделать наоборот. Может второй раз наступить на те же грабли, простить человека, которого собирался ненавидеть до конца жизни. А может испугаться там, где объективной опасности почти нет, и полезть напролом там, где любой разумный человек развернулся бы и ушёл.
И это не обязательно ошибка.
Потому что задача автора — не написать идеально рационального человека.
Задача — написать человека, которому читатель поверит.
Можно построить безупречную причинно-следственную цепочку и получить совершенно мёртвую книгу. Всё логично. Всё правильно. Всё работает.
Но читать почему-то не хочется.
Это довольно полезный опыт для человека, привыкшего искать систему.
Не всё, что логично, — правдоподобно.
И не всё, что выглядит нелогичным, — ошибка.
Иногда героиня прекрасно знает, что мужчина перед ней — ходячая катастрофа.
А потом всё равно его целует.
Если коротко, if (man == disaster) return false; не работает.
Я проверяла.
Старый код и старые книги лучше открывать осторожно
Здесь мои профессии снова удивительно похожи.
Открываешь то, что написала несколько лет назад.
Первая мысль:
Кто это сделал?
Вторая:
Зачем он это сделал?
Третья:
Почему оно вообще работает?
А потом смотришь автора.
Ты. Это была ты.
Со старыми книгами ровно то же самое.
Здесь я бы сейчас сократила.
Здесь не стала объяснять очевидное.
Здесь закончила бы сцену на полстраницы раньше.
Здесь вообще непонятно, почему я решила, что это хорошая идея.
Но и в программировании, и в писательстве это скорее хороший знак.
Если старые решения кажутся тебе плохими, значит, нынешняя ты уже умеет лучше.
Главное — не бросаться рефакторить всё написанное за последние десять лет.
У меня ещё новые книги вообще-то есть.
А потом книга выходит из Word
И здесь две мои профессии наконец сталкиваются уже не метафорически.
Потому что я пишу электронные книги, и современная электронная книга — это не просто текстовый файл, который однажды появился в интернете.
У неё есть площадка.
Карточка.
Обложка.
Аннотация.
Алгоритмы.
Показы.
Переходы.
Реклама.
Социальные сети.
Креативы.
Видео.
А теперь ещё и генеративные модели, которые сильно изменили то, сколько контента один автор вообще способен произвести самостоятельно.
И, конечно, данные.
Почему на один рекламный креатив кликают, а на другой нет?
Почему здесь переход дешевле, но читатели хуже остаются?
Что произошло после смены обложки?
На каком этапе человек увидел книгу — и решил, что она ему не нужна?
В этот момент роман становится для меня сразу двумя вещами.
Историей — и digital-продуктом.
Первую я десять лет учусь рассказывать. Со вторым мне неожиданно помогает профессия, которой я занимаюсь одиннадцать.
Собственно, поэтому я здесь
Когда я впервые увидела на PixelVibe раздел «Литература», первая мысль была:
О. Моё.
Потом я прочитала, что сама площадка вообще-то про digital.
Упс.
А потом подумала ещё раз.
Одиннадцать лет я пишу код. Десять — романы. Я публикую их в электронном самиздате, занимаюсь продвижением, рекламой, визуалами, смотрю аналитику и всё активнее использую технологии в работе с книгами.
Кажется, я как раз по адресу.
Поэтому здесь мне хочется говорить не только о том, как пишутся книги.
Гораздо интереснее посмотреть, что происходит вокруг современной электронной книги: как технологии меняют работу автора, как книга живёт на цифровой площадке, как мы ищем читателей, что можно узнать из аналитики, где помогают нейросети и где никакой digital не способен заменить хорошую историю.
Ну и периодически рассказывать о профессиональной деформации человека, который утром ищет баги в коде, а вечером — в собственном романе.
В конце концов, и там и там иногда всё сводится к одному вопросу:
кто это написал и почему теперь чинить мне?

Комментарии