Привет всем! Сначала я хотел отразить в заголовке что-то про личную эффективность, но потом решительно отверг эту идею. Заранее хочу отметить, что речь здесь пойдет не столько о достигаторстве и правильной постановке цели (хотя это немаловажно), а скорее о личном опыте и о событиях, которые привели меня прямиком в объятия этого вопроса (причем случилось это довольно спонтанно). Также я отмечу базовые способы упрощения работы, они настолько просты, насколько и эффективны.

Предыстория

Большую часть своей девелоперской карьеры (как фронтенд, так и фулстэк), я задумывался о немаловажной задаче: о производительности кода. Однако личная эффективность как-то выпадала из зоны моих интересов… Ну не то, чтобы прямо совсем, но надолго там не задерживалась, поэтому познания в данной области до сих пор у меня были весьма и весьма ограничены и отрывисты.

Минуя долгие пояснения, перейду сразу к… Кульминации моей истории, которая произошла этим летом. Так получилось, что сошлись абсолютно все звезды, которые только могли это сделать. Тут было все: мне активно не нравился мой проект, причем меня перевели еще и на новый, который мне нравился (на тот момент) еще меньше, “добавлял” счастья и близкий дедлайн, подливали масла в огонь регулярные происшествия с локальным окружением, довольно большие проблемы в личной жизни, отмена рейса, благодаря которой я застрял в другом городе, если добавить сюда эпидемию, то получится довольно полная и понятная картина. Все это привело к тому, что я начал гореть: мне было трудно работать, тяжело выполнять мало мальски сложные задачи, все время хотелось куда-то сбежать: чай, ютуб, книга и тд. В какой-то момент я понял, что работать больше не могу (ну вот прямо совсем). Оно и понятно, ведь вся моя работа последние месяцы строилась на самопринуждении: я заставлял себя работать. Довольно логичный результат.

Очевидные способы выйти из этой ситуации: попытаться изменить проект или уйти в отпуск. Но, во-первых, это не происходит моментально, а, во-вторых, я не знал, насколько меня хватит после отпуска или на новом проекте. Тогда сам себе задал вопрос: а чего я, собственно говоря, хочу? Оказалось, что чего угодно, но не программировать (удивительно). Например, пить чай (интересно, как отвечают на этот вопрос другие люди, оказавшись в схожей ситуации, но, возможно, мы этого никогда не узнаем). И я сказал себе, “окей пойду пить чай, но сначала сделаю хотя бы что-то”. И это очень важный момент, пытаясь понять, что же в таком состоянии могу сделать, начал делить задачу на микрозадачи и отсекать лишнее. Звучит просто и логично, более того — это азы проектирования. Однако, на самом деле, не все так радужно. В процессе выполнения задачи, мы все равно смотрим на задачу как на некий монолит, хотя, возможно, до этого она была разбита на составляющие. Более того, мы постоянно задаемся сотней разных вопросов, а что будет, если произойдет вот это (скажем, от сервера прилетит ответ с ошибкой).

До какой степени упрощать задачу

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

1. Создать компоненту заглушку с базовым интерфейсом
2. Подключить ее
3. Добавить разметку
4. Передать реальные данные
5. Добавить стили
6. Написать тесты

Если и это будет сложно, тогда эти шаги можно или уточнить, или разрабатывать компоненту по частям. (А как это делаете вы?)
Далее я хочу обратить внимание на три важных принципа:

Разделение задачи на элементарные

В моем случае, начальный этап выглядел примерно так:

1. Создать заглушку компоненты с “рыбным” текстом
2. Добавить для нее роут
3. Проверить, что она подключилась
4. Выяснить по каким адресам надо получать данные с сервера

Результат такого решения:

• Задачи элементарны, даже в таком состоянии я смотрю на них с некоторым облегчением, а не с отвращением
• На таких задачах легче концентрироваться
• Также снижен уровень стресса (я себя не принуждаю, а задачи не такие пугающе большие)

Фокусировка внимания на узком спектре подзадач

• Затрачивается меньше времени на выполнение подзадач
• Затрачивается меньше мозговых ресурсов
• Как следствие, сама задача выполняется быстрее

Ограниченность одной итерации по времени

• Я легко могу договориться с собой о том, что сейчас я минут 15 поработаю, а потом сделаю приятный перерыв на 5 минут. В то время как убедить себя (заставить) отработать целый день будет сложнее и неприятнее

Подведем итоги

Чтобы не тратить свое и чужое время постараюсь сделать это максимально коротко:

• Работа перестала быть для меня стрессом
• Я стал меньше уставать к концу дня
• Выросла производительность в сравнении с нестрессовым значением: раньше задача на 3 стори поинта + написание тестов занимала у меня 2 дня, теперь же получалось не больше полутора
• Более профессиональным подходом является использование таймера. О моих успехах (и неудачах, куда ж без них) внедрения техники помидора я бы хотел поговорить в другой раз.