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

Черпаю мотивацию из внешних источников

Я всегда про себя знал, что внешняя мотивация для меня работает лучше, чем внутренняя, поэтому выстроил кое-какие системы для периодической подпитки желания работать извне. Например, Money Bots, которые выдают оповещение о каждом новом подписчике.



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

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

Наконец, у меня есть канал #pump-up, где фиксируются наши достижения: регулярный ежемесячный доход в столько-то долларов, 2000 пользователей в Discord, коэффициент оттока меньше 6% — в общем, всё, что побуждает продолжать.

Оставляю задачи незавершенными

Словами не передать, до какой степени мне помогает этот способ. Я всегда стараюсь, чтобы к концу рабочей сессии у меня оставалась задача, выполненная на 90%. Это не так приятно, как довести дело до конца, зато садиться за работу на следующий день становится в десять раз легче. Если, принимаясь за написание кода, я буквально сразу же получаю результат, это придает энергии и быстро вводит в состояние потока. Впрочем, нельзя слишком уж упрощать себе задачу – если с прошлой сессии мне остается только запустить git commit, то этого маловато. В идеале должно быть так: я в точности знаю, что нужно сделать, и это займет пять-десять минут.

Использую свой продукт по максимуму

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

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

Устраняю, а не терплю неудобства

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

Фокус здесь заключается в том, что практически всегда можно как-то облегчить себе жизнь.
Например, недавно мне попалась задача, за которую я усаживал себя через силу, так как для нее требовалось более четырех новых эндпоинтов, а значит, и много шаблонного кода. Нужно было прописать типы в бэкенде, потом прописать те же типы во фронтенде, проверить, чтобы не было ошибок с полезной нагрузкой, проверить, чтобы не было ошибок в путях к файлам. Да еще и проверки типов нигде не было, так что вряд ли всё заработало бы с первого раза. В свете этого, прежде чем браться за дело, я нашел RPC-библиотеку под названием RSPC, которая сама сгенерировала мне типы. Благодаря этому прописать и вызвать новую бэкенд-функцию из фронтенда стало немногим более сложно, чем вызвать другую асинхронную фронтенд-функцию, и так же надежно с точки зрения типобезопасности.

Это не просто устранило неудобство – я с охотой и интересом разбирался в новой системе. То, что раньше было препятствием, превратилось в источник дополнительной мотивации.

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

Ничего не делаю

Меня то и дело засасывает в высокотехнологичные ящики Скиннера — Reddit, Twitter, YouTube и тому подобное. Я выяснил, что самый действенный способ выбраться оттуда состоит из двух этапов. Сначала я перехожу от Reddit к безделью, затем я перехожу от безделья к работе.

Если я попытаюсь оторваться от Reddit и сразу же сосредоточиться на работе, то мне придется очень нелегко. А вот ничего не делать гораздо проще, да и мозг скоро придет в состояние покоя, и тогда взяться за код уже не будет выглядеть таким неподъемным делом.

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

Держу пользователей в курсе

Тут я убиваю двух зайцев: и пользователи видят, как продвигается работа, и сам я могу посмотреть на прогресс и вдохновиться. Часто случается, что в конце месяца ловишь себя на мысли: «Я вообще хоть что-нибудь сделал?» А потом начинаешь писать месячную сводку новостей и осознаешь, что сделано-то немало.



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

Завожу напарников

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

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

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

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

Исключаю «пустые» дни (и чувство вины от них)

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

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

Не упускаю то, что идет в руки

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

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

Вы спросите: «У тебя СДВГ, что ли? Усадить себя за работу не настолько сложно». Да, так и есть. :)