"Противоположности не просто противостоят друг другу — они взаимно дополняют и переходят друг в друга, создавая движение." Гегель, из "Науки логики" (упрощенно)

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

Предисловие

Это третья статья в цикле, где мы пробуем натянуть сову на глобус применить метафоры магического мышления на процесс разработки. В первой статье мы рассмотрели определение стихий, во второй сравнили воздух и землю как два паттерна в мышлении - BFS и DFS поиск. Сегодня рассмотрим проблему мотивации и состояния потока, используя подход Гегеля о единстве и борьбе противоположностей.

Противостояние Воды и Огня

Огонь мотивации

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

- Создание нового: Удовольствие от процесса построения чего-то нового, от наблюдения за тем, как код превращается в работающий продукт, особенно если это не 1001 сайт по продаже пилок для ногтей, а какой-нибудь стартап, ощущение первооткрывателя может очень мотивировать.

- Создание "произведения искусства": Стремление писать красивый, чистый, хорошо структурированный и поддерживаемый код, воспринимая его как объект эстетического удовольствия. Работает исключительно с эстетами =)

- Преодоление трудностей: Интерес и азарт, возникающие при решении сложных задач, разработке непростых алгоритмов или исправлении запутанных багов. Я бы вообще назвал это "Эффект дарк-соулса".

- Завершение задач: Получение "дозы дофамина" и чувства удовлетворения от выполнения задач, особенно сложных, и видимого прогресса в работе. Тут важно не перегибать, и берясь за сложные задачи, всё равно дробить на маленькие, чтобы порционно давать себе дофамин за их выполнение, а то и "перегореть" не долго, если "без успехов" сидеть над одной задачей долго.

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

- Деньги: Финансовое вознаграждение как основной или значимый стимул для работы. Отдельно про это замечу позже.

- Уважение коллег: Стремление заслужить уважение и признание со стороны команды и руководства ( а может сообщества других разрабов? ) за свои навыки и достижения.

Главный вопрос - как не перегорать?

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

Вода и поток

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

Состояние потока (flow state) — это психологическое состояние, описанное Миалем Чиксентмихайи, где человек полностью погружён в задачу, и время кажется искажённым, часто пролетает незаметно. Анализ статьи How To Reach Flow State While Coding: Benefits и дополнительного материала из A guide to Flow states for programmers предоставляет глубокое понимание этого феномена в контексте программирования.

Условия для достижения состояния потока: Обе статьи выделяют несколько ключевых условий:

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

- Чёткие цели и обратная связь: Задачи должны иметь чёткие цели, а прогресс должен быть измеримым. В программировании это может быть написание определённого модуля или прохождение тестов. Автоматизированные тесты обеспечивают мгновенную обратную связь (красный/зелёный свет), что, по словам Чиксентмихайи, "заставляет продолжать, так как обратная связь постоянна".

- Баланс между сложностью и навыками: Задача должна быть достаточно сложной, чтобы избежать скуки, но не настолько, чтобы вызвать тревогу.

Дополню это своим личным опытом. Секрет потока не в том чтобы получить спокойствие. А в том, чтобы попасть в "свою волну" (которая может быть спокойствием, а может быть и чем-то иным). Наблюдая за коллегами видел, как один мой коллега не мог войти в состояние потока без музыки на фоне, при чём обязательно чтобы не было русского текста, иначе мозг отвлекается на смыслы песен, а нужен ритм. Другой мой знакомый не мог войти в состояние потока без колы. Только заправляясь огромным количеством сахара, он включал какое-то наркоманское сахарное состояние и улетал в код с разбега. Нужно найти своё привычное состояние потока, и необходимые критерии могут быть необычными, но "вставляющими" лично вас.

Главный вопрос - Как нырять, и как не тонуть?

Состояние потока подобно мистическому трансу, а по сути это состояние изменённого сознания, если брать термин из психологии. Это уникальное состояние, с которым не каждый знаком, и многие не могут понять, так что "братья и сестры в разработке", мы повязаны этим таинством =) Подводя итог по тому как попасть в поток могу сказать следующее "Нужно попасть в ощущение, которое было бы привычным и комфортно-энергичным лично для вас". Но у состояния потока есть свои минусы. Мы теряем счёт времени. Порой, при разработке, когда этот процесс захватывает, мы вскрываем архитектурные косяки, или старый тех долг, и продолжаем править и править, и править... Проходят дедлайны, и, если не суметь остановиться, то можно потерять всё. Я был свидетелем как подобное погубило хороший стартап, где инвестор разочаровался в команде разработчиков, которые постоянно что-то пилили (Каюсь был одним из команды). Делали новые фичи, исправляли баги, а продукт... месяцами оставался до конца не работающим, не было выпущено ни одной стабильной версии, и все презентации для инвестора так или иначе проходили с косяками. Нужно уметь остановиться, смириться с тех долгом, уметь сделать "плохо" архитектурно, но так чтобы оно выглядело рабочим, нужно уметь выпусктаь регулярно рабочие версии продукта. Иначе смерть проекту. А как? Тут поможет только смирение, как ни странно. Смириться с тем что код плохой, что баги будут, что нужно жертвовать красотой архитектуры во имя результативности. Нужно ставить перед собой рамки, и дисциплинированно следовать им. Вопрос дисциплины будет поднят в отдельной статье, где мы будем говорить о том "как не расплываться по коду и срокам". Наверное так её и назову.

Итоги

Баланс — это когда страсть (огонь) задаёт направление, а поток (вода) помогает обойти преграды и неустанно следовать намеченной цели. В той или иной пропорции каждый работает и со своей мотивацией, и своим процессом разработки, и в этом, собственно - диалектичность. Ровно как и очень редко встречается чистый BFS / DFS стиль мышления (в прошлой статье воздух и земля, как мышление в ширину и в глубину). Описанные концепции несут в себе цель быть инструментами для балансировки. Обыграв концепции мотивации и процесса разработки через метафоры стихий и магии, лично мне стало легче даваться работа над ними. Быть может кому-то ещё это окажется полезным.

P.S. Статьи, которые я пишу находят своего читателя, появляются подписчики и комментарии, но, что логично, есть и негативная обратная связь, у меня падает карма. Основным минусом у статей согласно оценкам является низкий технический уровень материала. И я задался вопросом, что есть технический уровень, и как его повысить. Я почитал статьи других авторов, пообщался с нейронками, куда же без них, чтобы понять чего не хватает статьям. Я пришёл к выводу что нужно больше конкретных примеров и ситуаций где метафоры, описанные в статьях будут применимы, либо раскрытие конкретных проблем с которыми сталкиваются разработчики, чтобы повысить применимость статей. Я попробовал это сделать на примере работы с мотивацией, описав проблему сложности признания своих мотивов. А также публикую не в хабе "программирование" а в хабе "ненормальное программирование". Опытные хабровчане, прошу, дайте знать, что не так, и что можно улучшить, я раньше никогда не писал статей и буду рад любой обратной связи и продолжу работать над улучшением статей.

До встречи! Cridendo Vides!