Как бороться со скукой на работе – над этим вопросом много размышлял CTO стартапа Enki Бруно Марнет. Пока он работал программистом, решал вопрос со скукой очередной сменой работы, но когда основал собственную компанию, задумался над тем, как сделать так, чтобы его подчиненным не хотелось уходить с работы, чтобы работа не становилась занудной рутиной. Свои размышления он изложил в колонке, предлагаем вам ее перевод.
Как программисту, мне никогда не удавалось задержаться на одной работе дольше двух лет.
Каждая следующая работа была хорошим шагом вперед по карьерной лестнице, да и текучка – это нормальное явление в нашей отрасли. Но мои предыдущие работодатели не особо радовались тому, что я ушел. Кто-то пытался меня удержать, но мне было настолько скучно, что я просто не мог оставаться.
(Поправка: мне посчастливилось жить в местах, где вакансий для программистов больше, чем самих программистов! Я понимаю, что такая смена работы не всегда доступна).
Сейчас я сооснователь и CTO Enki. В этой роли я отвечаю за рабочую среду программистов. Часть моей работы – сделать так, чтобы программистам никогда не было настолько скучно, как бывало мне в прошлом.
Я и команда разработали стратегию борьбы со скукой и применили ее у себя. Пока что она работает неплохо, так что я решил поделиться ею.
В нашей работе часто встречаются интересные продукты, которые нужно написать, занятные задачи, которые нужно решить. Так что, казалось бы, скука не должна быть для нас первостатейной проблемой. Но вначале всегда так. Вместо этого скука вползает в команду постепенно, и обрушится на вас в наименее подходящий момент.
Поэтому мы стараемся заранее сражаться с нею, строя культуру, которая никогда не позволит нам заскучать на работе.
TL;DL* (слишком длинно; ничему не научился)
Самая распространенная и очевидная причина скуки для программистов – проект, который длится слишком долго.
Я на своей шкуре это почувствовал, еще на первой работе. Команда тогда работала над тем, чтобы готовить и отдавать финансовые данные через удобный API. Сначала это было захватывающим заданием, из-за сложности и масштаба данных. Я учился методам высокоэффективного анализа данных и дизайну API. Но спустя год мы все еще работали над тем же самым набором данных, по тем же технологиям. Я становился профи в очень узкой отрасли. Не оставалось чему учиться.
Я не мог сменить команду или проект, поскольку компании было выгодно держать меня там, где я уже работал. Я слишком хорошо разбирался в данных и технологиях, чтобы меня меняли на кого-то другого. Я не смог бы добиться смены технологии просто для того, чтобы я мог учиться чему-то новому. Я жаловался о своей скуке и разочаровании, ни к кому особо не обращаясь, так что со временем я просто ушел с работы.
Как избежать появления таких чувств?
Мы стараемся делать так, чтобы никто не работал с одним кодом, продуктом или набором данных дольше, чем три месяца подряд. О точном периоде можно спорить, возможно, такого периода не хватит для более крупных компаний. Но в общем мы верим в “быстрое вращение”.
Чтобы добиться этого, мы продвигаем fullstack-культуру, это значит, что каждый из наших программистов может работать над любым куском нашего кода (либо же способен быстро обучиться этому).
Другой способ предотвращения: постоянно обсуждать такие вещи. Мы проводим прямые дискуссии лицом к лицу каждую неделю. Если программист чувствует себя слишком расслабленно или же начинает специализироваться в узких темах, время перемешивать кадры.
Поддерживать старый код – скучно
Сразу видно, когда проект уже в стадии поддержки – официально или нет — когда разработчики 90% времени тратят на то, чтобы фиксить баги, вместо того, чтобы разрабатывать новые фичи.
Кто-то заметит, что без поддержки никак нельзя. Старый код нуждается в ней. Создание софта – как возведение дома. Древние дома нужно чинить и подновлять время от времени. Верно?
И да, и нет.
Общая проблема здесь в отношении.
Когда-то у меня был наставник, который к этому подходил цинично. Он сразу принимал как данность, что поделать ничего нельзя. Так работает разработка софта, говорил он. Жизнь – отстой, привыкай.
Но как смягчить этот эффект?
Режим поддержки иногда является результатом неудачных технических решений и недостатка мужества.
Огромный монолитный код со сложными зависимостями нуждается в дополнительном техническом обслуживании. Микросервисы с хорошо спроектированной инфраструктурой намного гибче. Если микросервис начал лажать, его можно заменить. Можно переписать его с нуля, используя другой язык или технологию. Так вы будете учиться чему-то новому, вместо того, чтобы ставить патчи на старый код. И если ваша архитектура пока этого не позволяет, можно ее улучшить и заодно приобрести некоторые DevOps-навыки.
Стратегия с использованием микросервисов – это один из множества путей решения проблемы скуки, возникающей при поддержке кода. В некоторых компаниях разрабатывают специальные инструменты, которые превращают поддержку в более интересное и эффективное занятие. Один из примеров доведения до крайности такого подхода – то, что Facebook когда-то сделал со своей массивной кодовой базой на PHP. Они создали собственный компилятор и свой типизированный язык Hack поверх PHP, чтобы одновременно базу легче стало обслуживать, а разработчикам жилось бы веселей. Подозреваю, это не решило проблему полностью, но работу разработчикам точно разнообразило.
Копипастить – скучно
Есть программирование и программирование.
На некоторых предыдущих работах я создавал тонны не особо крутого кода. Как-то я писал скрипты на Groovy и Python для интеграции данных. Данные были сложными, со множеством непоследовательных схем, что не позволяло автоматизировать процесс. Так что мне приходилось писать много кода, а коллеги думали, что я многому учусь.
Но это было не так. Почему?
50% моего кода (преувеличиваю специально!) было прямой копипастой со Stack Overflow. А другие 40% из других скриптов – коллег или моих собственных. Работа стала повторяться. И в ней не осталось места творчеству или обучению.
Как смягчить этот эффект?
В команде мы обращаем внимание на тип кода, который пишут наши программисты – во время обзоров кода, встреч и совещаний. Если кто-то провел неделю за написанием не совсем творческого кода, мы пытаемся понять, как так вышло.
Иногда проблема коренится в технологии. Возможно, мы тратим на скрипты или настройки больше времени, чем нужно. В таком случае мы пытаемся автоматизировать процессы. Если же без копипасты не обойтись, стараемся разделить ношу занудной работы между всеми.
Внутренние инструменты, как правило, скучны
Программистам нравится создавать кастомизированные внутренние инструменты для решения специфических проблем. Ведь создавать что-то новое – так увлекательно. Часто создание специально настроенных решений кажется более аккуратным, чем адаптация уже существующих. Но изучение проприетарного инструмента в десять раз скучнее, чем популярной opensource-технологии.
Почему?
Потому что их не обсудишь с друзьями, нельзя хвастаться тем, что ты с ними знаком, ты не читаешь о них на Hacker News; их нельзя использовать на хакатонах, как и в своих секретных проектах в свободное от работы время.
Но многие компании попадают в ловушку, создавая вещи, не стоящие той скуки, которую они вызывают. Другими словами: они помогают справиться с кратковременной тоской, вызывая в будущем все больше тоски своим существованием.
Я своими глазами видел, как это работает. Для масштабной интеграции данных мне разрешено было использовать только созданный в компании DSL. Все, чему я учился – еще один SQL-подобный жаргон (специально преувеличиваю). Я бы с большим удовольствием использовал и изучал низкоуровневую открытую технологию вроде Spark. Я был бы в десять раз более вовлеченным в работу, и даже если бы мой код был бы вдвое многословнее, я работал бы в пять раз продуктивнее (арифметика работает не так, но вы поняли, что я хотел сказать).
Какая культура в компании может это предотвратить?
Мы стараемся лелеять сильную привязанность к opensource-технологиям. Мы не избегаем современных технологий, и если можем повторно использовать что-то подходящее и интересное, так и делаем. Мы вышвыриваем собственный код, как только opensource-технология становится достаточно развитой, чтобы заменить его. А когда наш собственный код становится достаточно универсальным, мы тут же переводим его в opensource.
Иногда мы совершаем ошибки. К примеру, мы использовали библиотеку agenda.js, чтобы планировать задачи по бэкенду, поскольку она казалась современной и интересной. Но вышло так, что это усложнило все задачи, так что мы вернулись к старой, более надежной технологии (старый-добрый cron!). Мы не жалеем об эксперименте, это был ценный урок.
Быть “быдлокодером” – скучно
Еще одна популярная причина программистской тоски – плохое управление персоналом. А точнее: однонаправленное диктаторское управление разработчиками.
Топ-менеджеры иногда пользуются таким стилем, даже не осознавая этого, с самыми благородными намерениями. Особенно, когда проект идет ни шатко, ни валко, или же когда подступает дедлайн. Под таким давлением безусловный рефлекс – это принимать решения самому, минимизировать мозговые штурмы и просто указывать людям прямо, что им делать, без обсуждений или объяснений. Просто, чтобы сэкономить время и добиться результатов.
Понимающий подчиненный необязательно расстроится по этому поводу. На самом деле, некоторые люди (время от времени) ценят подобную простоту работы: просто делать, что им велено.
Но здесь скрыт некоторый риск.
Знание о том, что именно нужно написать, еще до начала работы над кодом превращает интеллектуальный и творческий процесс в механический. Разработчики превращаются в “быдлокодеров”.
Что еще важнее, увлеченные работой программисты любят понимать, зачем они делают все так, а не иначе. Программист, которому наплевать на причины принятия решений, – это программист, которому пора менять работу.
Как этого избежать?
В первую очередь, нужна внутренняя культура, которая поощряет открытые обсуждения. Чтобы был обновляемый форум для дискуссий по стратегии и планированию того, что должна сделать команда. И все в команде должны быть бдительными и активными.
Когда приближаются тяжелые времена (или дедлайн), именно подчиненные должны говорить громче, а начальники – внимательно слушать.
Рутина = скучно
Последний в списке, но не по важности пункт: рутина в закрытой среде – это универсальный убийца интереса к работе.
Это не относится только к технокомпаниям или к программистам. Это характеризует любую работу в офисе. День за днем, в одной комнате, в окружении одних и тех же лиц, выполнять одну и ту же роль… Даже в быстрорастущей среде, и даже если все эти составляющие объективно хороши, люди быстро привыкают к хорошему, и расстраиваются из-за недостаточно хороших элементов рабочей атмосферы.
Как мы с этим сражаемся?
Ключевой ингредиент: разнообразие. Можно нанимать людей с очень разным бекграундом и происхождением (сейчас у нас в команде есть британец, француз, русский и грек). Видеться с одними и теми же людьми каждый день будет намного интересней, если каждый из них может привносить в культуру что-то особенное.
Мы также стараемся часто вырываться из рутины.
Ходим вместе на хакатоны и тусовки. У нас всех есть свои сторонние проекты, мы стараемся участвовать в развитии любимых opensource-инструментов. Даже помогаем остальной команде с нетехнической работой (найм, маркетинг, дистрибуция). Не потому, что мы в этом профи, а чтобы менять обстановку.
Мы организовываем внерабочие встречи (например, “секретное кино”), еженедельные “энкитоны” без заданного наперед плана. Иногда обмозговываем какие-то идеи. Иногда просто шпилим вместе в League of Legends. Или идем в паб. Красота в том, что мы до последнего не знаем, чем будем заниматься, а потом решаем вместе.
Немножко хаоса – вот последний ингредиент в нашем рецепте против скуки. Как и любой рецепт, он никогда не станет совершенным. Меняйте дозы, ингредиенты и пытайтесь снова.
*отсылка к популярному мему too long; didn’t read, аналогу русскоязычного “многобукв, не осилил”.
