Перевод статьи «How to overcome your fear of writing by writing like you code».
Как часто вам случается испытывать страх? Что я имею в виду под словом «страх»? Например, когда перед прыжком с парашютом внутри все сжимается. Несмотря на то, что мозг предусмотрел все необходимые предосторожности, ваше тело чувствует опасность.
Когда вы работаете в IT, внезапные серьезные опасности маловероятны. Но способность испытывать страх сохраняется. И она проявляет себя во всей красе, когда нас просят выполнить некоторые задачи.
На своей первой работе я переживал приступы страха, когда меня спрашивали, закончил ли я писать документацию.
На второй — когда напоминали о необходимости написать электронное письмо клиенту.
Позже аналогичные ощущения вызывали вопросы «Ну, как там дела с презентацией?»
В чем же тут проблема? Все эти задачи связаны с необходимостью писать. А хуже этого и нет ничего. Очень немногие разработчики любят писать (если только это не треп в Slack). И чем больше аудитория и важнее адресат, тем страшнее браться за письмо.
Но вернемся к программированию. Когда в последний раз ваш код заработал с первой попытки? Так, чтобы вы написали пару сотен строк кода, и все они были столь безупречны, что код сразу скомпилировался и заработал точно так, как ожидалось?
Мы, разработчики, никогда и не ожидаем, что код будет совершенным изначально, а ведь написание кода — наша основная деятельность. Но при этом, когда нас просят написать какую-нибудь документацию, важное письмо клиенту или презентацию, мы впадаем в ступор. На столе накапливаются пустые чашки из-под кофе и банки от колы, а мы все пялимся в пустую страницу и ждем, пока в голове сложится идеальный текст.
Но это же бессмыслица какая-то! Почему наши ожидания относительно побочной задачи, которой мы не любим заниматься, значительно выше наших ожиданий от работы, которую мы любим и которой занимаемся все время?
Написание текста и написание кода имеют гораздо больше общего, чем вы думаете. И, что удивительно, вы вполне можете применить свои навыки написания кода для улучшения своей письменной речи.
Разработчики всегда стремятся как можно быстрее приступить к написанию кода. Никто не сидит, пытаясь сначала сложить идеальный код у себя в голове. Мы хотим пробовать и экспериментировать. Мы хотим получить результат. Набросав основу, мы расширяем и улучшаем нашу программу. Да мы даже специальную терминологию и методологию для этого придумали — вспомните о Scrum и рефакторинге.
Суть Scrum как раз в том и состоит, чтобы сделать что-нибудь, а затем улучшить. Этот подход разрабатывался для того, чтобы обуздать нереалистичные ожидания в работе по методологии waterfall, где вы как раз и должны продумать все полностью, прежде чем приступить к написанию кода.
В Scrum идея проверяется и адаптируется. Совершенство никогда не является целью первого спринта. Сначала мы стараемся сделать самые важные части программы, чтобы потом совершенствовать их и добавлять детали.
В общем, когда речь идет о коде, никто не ожидает, что первый вариант будет идеальным. Мы стремимся получить начальную версию, а уж после работать над повышением читаемости и упрощением кода.
Можно ли редактировать пустую страницу?
Но что происходит, когда вы переключаетесь со своей любимой IDE на почтовый клиент или PowerPoint? Я бессчетное число раз видел, как разработчики замирают в страхе, глядя в пустой экран. Мы не знаем точно, что писать, и боимся, что результат нас не порадует. И поэтому не пишем ничего. Вы буквально можете почувствовать страх коллеги, который занимается документацией: его выдают постоянные тяжелые вздохи и нервное нажатие клавиш.
Но если здраво рассудить, этот подход — «совершенство или ничто» — прямо противоположен тому, который мы ежедневно применяем в отношении кода. Если бы речь шла о коде, мы бы попробовали какие-нибудь простые случаи и попытались запустить хоть какой-то вариант. Но когда речь идет о текстах, мы так не поступаем. Возможно, потому что слишком переживаем насчет ясности этого текста, его структуры и стиля. И это еще до того, как напишем хоть слово!
Но если просто сидеть и ждать, пока в голове сложатся идеальные словесные конструкции, чтобы мы могли их записать, ни к чему хорошему это не приведет. Это не работает с кодом, так почему же должно работать с текстом?
Это легко продемонстрировать, изменив контекст. Вы когда-нибудь пытались сделать рефакторинг программы, в которой не было бы ни строчки кода? А ведь именно это вы пытаетесь сделать с вашим электронным письмом, документацией или презентацией. Мне нравится цитата Джоди Пиколт:
«Плохую страницу всегда можно отредактировать. А вот пустую — нельзя».
Чтобы иметь возможность улучшить текст, нужно сначала хоть что-то написать. Этот первый черновик не должен быть красивым и правильным, но это обязательный первый шаг.
Сбросьте груз с плеч и позвольте себе написать первое, что приходит в голову, не оглядываясь на качество. Когда речь идет о коде, вам нужно, чтобы первая версия программы просто работала. Что касается текста, нужно стремиться написать хоть несколько слов. Любых. Тут же нет компилятора, который возмутится тем, что вы употребили неправильное слово, так чего переживать-то?
Итоги
Немного бояться приступить к написанию текста это нормально. Это происходит и с профессиональными писателями, так что нет ничего удивительного, что это случается и с разработчиками, когда они пытаются писать тексты.
Я советую:
- Написать на странице хоть что-нибудь. Все равно, что именно. Первое, что придет в голову.
- Применять правила agile/Scrum: повторять и адаптировать.
- Применять правила рефакторинга: постепенно уменьшать сложность и улучшать читаемость.
В следующий раз, когда босс спросит вас, послали ли вы email клиенту, помните, что вам не предлагается прыгнуть с парашютом. Вам нужно только подавить свой страх, набросать черновик, а потом улучшить текст.
Нужные навыки у вас уже есть, вы отточили их при написании кода. Теперь просто примените их к написанию текстов.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]