Как программисту бороться со стрессами. Часть 2. Написание кода.

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

Стрессы от взаимодействия с чужим кодом

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

Помогает правильное отношение к коду:

• До тех пор, пока код - ваша идея, и не выслан в удаленный репозиторий проекта - он ваш. После - он собственность компании, со всеми вытекающими.
• Поймите, что абсолютно правильно написанного кода не существует. Есть лишь метрика "работоспособности кода при множестве входных данных". Метрики "правильного" codestyle, оформления решения - не существует. Все попытки сделать какой-то codestyle - в своей основе предполагают легкость чтения и модификации людьми. А эта характеристика - субъективна, и формируется общими вкусами команды!
• Примите для себя, что даже очевидный overengineering, либо наоборот непроработанное с вашей (и не только) точки зрения решение - тоже может принести пользу. Развитие проекта и действия пользователя - это те вещи, которые нельзя прогнозировать со 100% точностью. Решение задачи, которое вы видите - может быть бесконечно плохим с точки зрения инженера. Но особенности развития проекта могут дать ему возможность хорошо и мирно жить годами на миллионах пользователей - а затем быть заменённым на новую технологию, или вообще выпиленным. Тоже самое с overengineering - он может начать спасать вас, когда вы даже не подозреваете.

Выбор между несколькими равнозначными решениями задачи

Та самая, знаменитая проблема "выбора имени переменной", когда вы отдали мыслительный ресурс на решение,

• Помните: если выбор между равнозначными вариантами - как правило, большой ошибки не будет при любом из них. Другое дело, когда по неопытности вы не знаете какие-то вещи, от которых выбор бы на 100% склонился к одному из вариантов. Тут см. следующий пункт:
• Если проблема более важная и глобальная, и вы младший разработчик - старайтесь выносить вопрос тимлиду. Если вы старший разработчик, и есть опытные коллеги - выносите вопросы на обсуждение.
• В целом, перфекционизм - это нормальная черта развития вас, как разработчика. Но помните, что "ошибочность" и "хорошесть" решения именно в промышленной разработке - вещь крайне относительная. Ваша общая "ресурсность" и "мотивированность" может быть нужнее и вам, и компании. Поэтому если чувствуете перегруз и загнанность - старайтесь прийти к законченному решению.

Сложность задачи

Тут могут быть и стрессы от алгоритмической сложности задачи, и стрессы от предметной области, и стрессы от обилия технологий и их интеграции. Разработка - всё же, технически сложная область. И несмотря на множество курсов, стандартов и методологий, способных упростить задачу - в повседневной работе мы периодически сталкиваемся с кипящей от сложности задач головой.

Что делать?

• Пробуйте выкладывать и записывать варианты решения и основные вопросы во внешний мир. О пользе записи мыслей говорят множество психологов и статей в сети. Но про пользу в технически сложных задачах - подробно описывает вот эта статья. От себя отмечу, что можно не только выкладывать мысли на бумагу - но и обсуждать/делиться ими с кем-то. Как минимум, это будет похоже на запись на бумагу, как максимум - вы ещё и получите видение или решение проблемы.
• "Не можешь решить задачу - отойди в сторону". Отвлечься от задачи - хороший способ прийти к её решению. Тут играют два фактора: возможность отдыха мозга, и приступить к задаче "с нуля", посмотрев на неё немного под другим углом.
• Микроменеджмент своих задач. Говорят, микроменеджмент - это зло. Но забывают упомянуть: лишь когда он идёт извне. Разбиение задач для себя на небольшие части и промежутки для решения - помогает сильно упростить процесс работы мозга над ними.
• Симбиоз пунктов 1 и 2: разделите периоды сильной работы над конкретными задачами, и отдыха.

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

Мне помог довольно известный метод помидора - в совмещении с разделением задач. Важно выбрать именно тот интервал нагрузки, с которым вы будете способны работать много промежутков, и при этом мало уставать. Для меня таким оказался стандартный: 25 минут. Моей проблемой оказалось то, что я любил жёстко выкладываться в мозговых штурмах - теряясь в задаче, и думая о ней в перерывах, и совершенно не балансировал нагрузку. В итоге уставал весьма быстро. 25 минутные интервалы с перерывами в 5 минут - помогли мне работать гораздо дольше, и даже не особо уставать после обычного рабочего дня! Использовал программу Focus To-Do (доступна ниже по ссылке) - совмещающую в себе все вышеописанные возможности: и разбиение задач, и выполнение "помидоров" с разными вариантами.

Большая и плохо декомпозированная задача

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

Решение:

• В таких задачах есть ловушки слишком усиленной работы и отдыха. Это когда вы либо много работаете, и из-за неконкретности задачи часть вашей работы в итоге бесполезна. Либо из-за плавающего срока и обилия research вы делаете слишком мало, но в конце на вас падает большой участок работы.
• Опять же, микроменеджмент своих задач. Конкретизируйте и разбивайте на небольшие промежутки - чтобы было понятно прежде всего вам. Порекомендую всё тот же метод помидора: даже для плохо декомпозированной задачи вы сможете разбить её "для себя" на удобные промежутки - и уделять им фиксированные моменты времени.

Тяжело сесть за код после отдыха

Внезапно, это очень частая проблема множества разработчиков - и даже "фанатов" программирования.

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

Но это было лирическое отступление - а теперь давайте вернёмся к решению проблемы.

• Старайтесь заниматься тем, что вам хоть немного интересно. Работа перестаёт быть работой, когда она интересна вам без каких-то условностей: наград, денег и т.д. Если такого нету - старайтесь искать внутри работы. К примеру, у меня работа программиста всегда ассоциировалась со смесью работы журналиста и детектива. От журналиста тут возможность писать свои мысли на языке кода (замечу, что порой с весьма более сильной "свободой изложения", нежели в СМИ), от детектива - поиски причин багов, моделирование неоднозначных ситуаций, узких мест, и частая потребность "найти лазейку" в чём-либо. Учитывая, что айти сейчас является ещё и автоматизацией какой-то предметной области - думаю, многие могут найти там интересную часть для себя.
• Если вам попалась неинтересная, или малоинтересная задача - не забывайте, что профессия программиста на редкость творческая! Попробуйте внести в задачу некие новые условия "для себя": решить её с использованием нового фреймворка, другой технологии или методики. Добавляйте в решение задачи спонтанный "рефакторинг" там, где это возможно. Думайте: как сделать лучше, и рассматривайте самые ухищрённые технические случаи. Задача заиграет для вас новыми красками - но самое лучшее, что эта практика очень полезна для вашего развития!
• Никогда не воспринимайте внутри себя код, как что-то сложное! Старайтесь найти понятную, "входную" часть задачи, зацепитесь за неё - и садитесь писать.
• Часто бывает, что решение где-то есть, а кода - нету. Поймите, что код - это способ выразить ваше решение и мысли во внешнюю среду. Представьте, на секунду, внешний мир без

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

• Причина может быть зарыта в прошлых пунктах: и большая задача, и сложность - но может быть и банально потеря интереса к задаче и проекту, или лень. Затем делите то, что "болит" на маленькие части - и ставьте самую простую из них первой. Очень важно, чтобы микроменеджмент тут не был способом "убежать" от того, что вас ограждает от кода.
  Поэтому, если у вас именно страх сложности - начинайте с той части, которая самая сложная.
  Если же ваше корневое чувство - отсутствие интереса (лень, скука, ощущение рутины и т.д.) - то берите ту подзадачу, что вас больше всего увлекает и интересна.
• Помните: лень - это скорее помощник программиста, нежели его бич. Автоматизация - это по своей сути, инструмент реализации возможности быть ленивым. И если причины вашей лени в сложности и проблемности задачи - возможно, это подсказка к тому, что нужно намного проще смотреть на решения и вещи в вашей голове.

.... а как, блин, не заскучать, если со всем этим справиться, и мыслить всегда логично, и рационально?!

Может показаться, что если выполнять все эти пункты - работа программиста ужасно скучна, автоматизирована, лишена эмоций и впечатлений! И в этом будет самый сложный пункт: не возводите борьбу с эмоциями и стрессами в абсолют! Ваша задача - не превратиться в бездушную машинку, печатающую код - а лишь помочь избавиться от вещей, которые отрицательно влияют на ваше внутреннее состояние! Поэтому вышестоящие советы стоит:

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

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