Программировать скучно, но…09.08.2016 11:33

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

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

(Оговорка: мне везло, что я жил в местах, где работы для программистов было больше, чем программистов! Я понимаю, что возможность сменить работу доступна не всем).

Сейчас я соучредитель и технический директор компании Enki. Так что я несу ответственность за инженерную культуру. Часть моей работы — быть уверенным в том, что наши разработчики не сходят с ума от скуки, как это иногда случалось со мной в прошлом.

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

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

Вот почему мы заранее предлагаем решение, создавая культуру, которая спасет нас (постучим по дереву!) и сделает так, чтобы никогда не становилось скучно.

Наиболее распространенная и очевидная причина скуки у разработчиков — проект, который длится слишком долго.

Я испытал это лично на своей первой работе. Моя команда работала над подготовкой и обслуживанием финансовых данных через удобный API. Сначала всё было интересно из-за сложности и объёма данных. Я узнал об эффективных способах анализа данных и дизайне API. Но спустя год мы по-прежнему работали над тем же набором данных, с теми же технологиями. Я становился специалистом в какой-то узкой области. Я не узнавал ничего нового.

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

Как предотвратить подобное чувство?

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

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

Еще один фактор для профилактики — это постоянное обсуждение подобных проблем. У нас есть прямые, открытые дискуссии каждую неделю. Если разработчик начинает чувствовать себя слишком специализированным или ощущает избыточный комфорт, то пришло время менять место.

Понять, что ваш проект в режиме поддержки — официально или нет — можно, когда разработчики тратят 90% своего времени на исправление багов вместо разработки новых компонентов.

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

И да и нет. Типичная проблема — это сложившиеся установки.

Когда-то у меня был ментор, который к этому вопросу относился цинично. Он воспринимал как данность то, что ничего нельзя больше сделать. Так устроена разработка софта, говорил он. Жизнь отстой — привыкай.

Как справляться с такой проблемой?

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

Большая, монолитная кодовая база со сложными зависимостями требует дополнительного технического обслуживания. Хорошо спроектированная инфраструктура микро-сервисов, напротив, немного податливей. Когда микро-сервис перестает работать, его можно заменить. Можно переписать его с нуля, используя другой язык или технологию. Таким образом вы узнаете что-то новое, вместо исправления унаследованного кода. А если ваша архитектура пока этого не позволяет, то вы можете предпринять какие-то шаги, чтобы её улучшить и получить навыки DevOps в процессе.

Стратегия микро-сервисов — это только один из возможных способов подойти к проблеме «скучного» технического обслуживания. Некоторые создают продвинутые инструменты, чтобы сделать поддержку более эффективной и увлекательной. Отличный пример это то, что Facebook сделал со своей массивной базой кода на PHP. Они построили свой собственный компилятор и написали собственный типизированный язык (Hack) поверх PHP, чтобы одновременно облегчить обслуживание и улучшить опыт разработчиков. Я подозреваю, что это не «решило» проблемы легаси-кода, но, безусловно, сделало работу более интересной.

Есть программирование, и есть программирование.

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

Но это было не так. Почему?

Потому что 50% моего кода (специально преувеличиваю!) были прямым копированием из Stack Overflow. А другие 40% были копированием из других скриптов. Либо моих коллег, либо моих собственных. Работа стала однообразной. Креативности или приобретения знаний тут было мало.

Как мы пытаемся справиться с этим?

Как команда, мы обращаем внимание на тип кода, написанного другими. Мы делаем это во время код-ревью, созвонов и встреч. Если кто-то провел неделю над не слишком творческим кодом, мы стараемся понять, почему.

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

Нам, разработчикам, нравится создавать собственные внутренние инструменты для решения специфических проблем, потому что создавать новые вещи — это круто. И ещё, проектирование специальных решений ощущается «чище», чем адаптирование и повторное использование уже существующих. Но изучение проприетарного инструмента примерно в 10 раз менее интересно, чем изучение популярных технологий с открытым кодом.

Почему?

Потому что вы не можете о нем поговорить с друзьями, похвастаться им, не можете прочитать о нём на Hacker News, использовать его во время хакатонов или в закрытом стороннем проекте.

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

Я видел это сам на предыдущей работе. Я был вынужден использовать внутренний DSL для масштабной интеграции данных. Всё, что я узнал нового — это ещё один подобный SQL жаргон (специально преувеличиваю). Лучше бы я пользовался и изучал открытую низкоуровневую технологию, вроде Spark. Я был бы в 10 раз сильнее вовлечён, и даже если бы мой код был бы в два раза более многословным, это всё ещё делало бы меня в 5 раз более продуктивным. (не совсем математически обосновано, но вы понимаете).

Какая культура и окружение может это предотвратить?

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

Иногда мы делаем ошибки. Например, некоторое время мы использовали библиотеку agenda.js чтобы планировать бэкенд задачи, потому что это казалось современным и заманчивым. Но оказалось, что это всё усложняет, поэтому мы переключились на старую, более надежную технологию (старый добрый cron!). Мы не жалеем, что экспериментировали, потому что это был ценный опыт.

Еще один распространенная причина скуки — это непрофессиональное управление персоналом. Если говорить точнее: диктаторское управление разработчиками, по принципу «сверху вниз».

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

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

Но здесь есть некоторые скрытые издержки.

Точное знание, как писать код ещё до начала работы, превращает интеллектуальный и творческий процесс в механический. Другими словами, это превращает разработчиков в манки-кодеров.

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

Как это предотвратить?

Главное, что нужно, — это обстановка, которая поощряет открытые дискуссии. С регулярным форумом для обсуждения, разработок стратегии и планирования того, что должно быть сделано в команде. И чтобы сохранить такую атмосферу, все в команде должны быть бдительными.

Именно в тяжёлые времена (или когда близок дедлайн) подопечным нужно говорить громче, а наставникам внимательно слушать.

Последнее, но не менее важное: рутина в замкнутой атмосфере — абсолютный убийца удовольствия.

И это касается не только разработчиков и индустрии IT. Это можно применить почти к любым сотрудникам, не работающими напрямую с клиентами. Каждый день та же комната, те же самые люди, та же атмосфера, та же должность… Даже в быстро растущем коллективе, и даже тогда, когда все эти вещи объективно «хороши», люди начинают принимать все хорошее как должное, а плохое их сильно расстраивает.

Как мы боремся с этим?

Ключевой ингредиент тут — разнообразие: нанимать людей с разным видом опыта и разного происхождения (например, наша команда состоит из 6 человек родом из Британии, Франции, России и Греции). Ежедневно встречаться с теми же людьми, безусловно, интереснее, если каждый из них может внести что-то особенное в культуру.

Кроме того, мы стараемся, чтобы чаще была возможность выйти из повседневной рутины.

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

Мы также организуем сторонние вылазки для команды (например, Secret Cinema) и у нас есть еженедельный «еnkiтон» без четкой цели и плана. Во время него мы иногда пишем вместе бесполезные программы. Иногда обмозговываем новую идею. Иногда просто играем в League of Legends. Или идем в паб. Приятное тут в том, что мы не знаем, что будем делать до последней минуты, пока не решим вместе.

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

Комментарии (0)