Многие инженеры должны работать меньше и медленнее. Не то чтобы producтить меньше кода — речь о буквально меньшем количестве часов в день. Автор рекомендует держать загрузку на уровне 80%: 20% рабочего дня проводить вдали от компьютера.
Почему? Производительность в tech-компаниях определяют не рутина, а редкие события с высоким откликом. Самые impactful изменения часто требуют ничтожно мало работы. В разработке нет баллов за старания — важно решить правильную проблему в правильное время.
В больших инженерных организациях почти всегда есть тривиальные доработки, которые стоят компании десятки или сотни миллионов долларов. Первое: фича или багфикс, который закрывает крупную enterprise-сделку. Необязательно хорошая фича — иногда достаточно показать готовность что-то сделать. Второе: предотвращение или смягчение инцидента на ранней стадии — даже просто знание, какой feature flag выключить, экономит огромные деньги. Третье: тривиальное, но узкое изменение — например, добавить новое поле в настройках или починить древний export данных, от которого зависит запуск важного продукта. Знакомство с системой решает, займёт это часы или неделю.
Общее у этих примеров одно: они привязаны к моменту. Нельзя просто прийти утром и решить разблокировать крупную сделку. Для этого нужно ещё не быть занятым.
Если вы загружены на 100% потоком низкоприоритетных задач, вы упустите шанс. Во-первых, будете слишком заняты, чтобы заметить возможность. Вы не будете болтать с коллегами, читать апдейты команд, следить за инцидентами. А лучший способ — предложить свою экспертизу, когда она нужна. Во-вторых, если вы вечно заняты, менеджер не подумает вас предложить. А это второй по эффективности способ попасть в важную работу — менеджеры видят общую картину лучше вас.
Что же делать в обычные минуты? Ничего. И это нормально. Разработка — стрессовая работа, но стресс приходит всплесками. Если жечь ресурс в спокойные дни, к настоящему ЧП вы уже будете вымотаны. Даже во время инцидентов полезно не спешить — сделать паузу, думать в замедленном режиме. Большинство инцидентов решаются сами. Панические «а давай попробуем это» обычно только ухудшают ситуацию.
Пустота — это пространство, где могут появиться идеи. Если дать мозгу отдых, вы будете лучше придумывать. Если приходит важная задача, вы возьмётесь за неё со всей концентрацией, а не жонглируя тремя другими.
Многие инженеры не выносят видеть задачу и не делать её. Автор называет это «зависимостью от полезности» — распространённая черта, которая делает хорошего инженера, но мешает держать паузу. Поэтому приходится сознательно себя сдерживать. Например, не заниматься «glue work»: сводить людей, обновлять чужие документы, волонтёрить в техдолг. Если организация это не приоритезирует, значит, либо это нормально (и не стоит тратить время), либо это большая ошибка (и всё равно не стоит: вы изолируете компанию от последствий за счёт своей карьеры и нервов). Плохая сделка для вас и плохой пример для джуниоров.
Также не стоит быть слишком отзывчивым к неформальным просьбам. В tech-компаниях полно людей, которые хотят получить работу бесплатно — через back-каналы, без формальной записи под вашим именем. Просить набросать статистику или «попейрить» код — нормально, но нужно уметь применять обратное давление: говорить «нет» или просто задерживать ответ на часы или дни.
Ещё совет: не вкладываться в работу, которая скорее всего исчезнет. Если дизайнер меняет макет каждый час — не переписывайте страницу каждый раз. Сходите на прогулку, перепишите один раз к вечеру по последней версии. Та же логика с «великой идеей менеджера без политического веса» — часто можно просто переждать, пока проект отменят.
Вывод: много советов и инструментов нацелено на масштабирование усилий — делать больше, брать на себя больше, писать больше кода. Но успех определяет способность делать правильные вещи в правильное время. Для этого нужно сознательно держать резерв. На 80% усилий быть «высокоэффективным» не только можно, но и легче: меньше глупых ошибок от стресса, и вы готовы прыгнуть на задачи с огромной отдачей.
Это не значит, что никогда не нужно выкладываться на 100%. Два-три раза в год автор работает на полную — долгие часы, глубокая фокусировка, мысль о проблеме с утра до ночи. Но это режим для моментов, когда награда действительно высока. В остальное время — относительно спокойно.
Пост получил обсуждение на Hacker News: комментаторы говорят, как не влипнуть с менеджером из-за slack time, и стоит ли у инженеров вообще такой контроль над загрузкой.