[Перевод] Что делать, если программировать становится скучно
Случалось ли c вами, долго работая в одной компании над одним и тем же проектом, начинаешь задумываться о смене обстановки, используемых технологий и самого проекта. Раньше я был уверен, что из этой ситуации один выход — найти новую работу. Эта статья, перевод которой мы публикуем, поменяла мое мнение. В ней описывается подход, благодаря которому можно сделать работу программиста нескучной и помогающей ему расти и развиваться. Мы, сервис для организации приема платежей PayOnline, предлагаем вам ознакомиться с этой методикой и поделиться ею со своим работодателем, в случае, если вы испытываете подобные, описанные автором проблемы. Ниже идет, непосредственно, перевод.
В мою бытность разработчиком я никогда не задерживался на одной и той же работе более двух лет. В моем случае каждая новая работа была для меня хорошим ходом с точки зрения карьерного роста. И даже несмотря на то, что высокая «текучка» — обычное дело в нашей профессиональной сфере, я не могу сказать, что мои предыдущие работодатели спокойно относились к моему уходу. Некоторые из них упорно пытались сделать так чтобы я остался, но работа становилась для меня настолько скучной, что оставаться я уже не мог. Сразу поясню: мне посчастливилось жить в таких местах, где работы для программистов было больше чем самих программистов. Я понимаю, что вариант со сменой работы доступен не всем.
Сейчас, будучи одним из основателей и техническим директором Enki, я отвечаю за инженерную культуру, и поэтому в мои обязанности входит контроль за тем, чтобы наши разработчики никогда не теряли интерес к своей работе, как это происходило со мной раньше. Мы вместе с нашей командой изобрели стратегию борьбы с этой проблемой. Эту стратегию мы применяем ежедневно, и поскольку за все это время она хорошо себя показала, я хочу поделиться ей здесь.
Нам в Enki очень повезло ведь мы работаем над трудными, но интересными проблемами. Нам приходится много кодить и заниматься решением увлекательных задач, поэтому вопрос с потерей интереса в нашем коллективе не стоит. Впрочем, в начале работы над проектом это вполне естественно, но со временем все меняется, ведь скука имеет обыкновение подбираться незаметно и нападать в самый неудобный момент. Вот почему мы стараемся заранее создать культуру, которая, как мы надеемся, поможет нам всегда быть увлеченными своей работой.
Меняемся быстро, узнаем что-то новое
Самая характерная и очевидная причина, по которой разработчики начинают скучать, — это затянувшийся проект.
В этом я убедился лично на своей первой работе. Моя команда работала над созданием удобного API для подготовки и представления финансовых данных. Поначалу, из-за их сложности и масштабов проекта, работа была увлекательной. Я многое узнал о методах высокопроизводительного анализа данных и проектировании API. Однако, спустя год, мы по-прежнему работали над тем же самым набором данных и использовали те же технологий, что и вначале. Я стал постепенно превращаться в слишком узкого специалиста. Не осталось ничего нового, чему я мог бы научиться.
Я не мог поменять команду или проект, потому что это было бы слишком неразумно с точки зрения целей моей компании. Я был нужен ей на том же самом месте. Заменить меня было нельзя, ведь я слишком хорошо разбирался в данных и технологии. В то же время изменять технологию «под себя» из-за одного только желания научиться чем-то новому я не мог. Я рассказал работодателю, в каком безвыходном положении я нахожусь и как я устал, но он не принял никаких мер, поэтому мне пора была двигаться дальше.
Как же уберечь себя от таких ситуаций?
Наш коллектив старается сделать так, чтобы никому не пришлось работать над одним и тем же продуктом, набором данных в течение более чем трех месяцев. Конечно, такой промежуток времени выбран на основе наших собственных предпочтений и, возможно, окажется слишком коротким для более крупных компаний, однако, в целом мы верим в быстрые замены.
Чтобы все это удавалось, мы культивируем комплексный подход. Каждый из наших разработчиков способен работать над любой частью базы исходного кода или может быстро научиться этому.
Еще одна важная часть профилактики — постоянный диалог со всеми членами команды. Каждую неделю у нас проходят индивидуальные сессии с возможностью откровенно обсудить все что беспокоит того или иного разработчика. Если он начинает чувствовать себя слишком удобно или не в меру глубоко уходит в какую-то часть проекта, значит, пришло время ему поменять обстановку.
Как поддержка кода делает работу скучной
Вы всегда можете с легкостью определить, что проект, официально или нет, находится в режиме поддержки, потому что в этом случае разработчики тратят 90% своего времени, исправляя баги, вместо того, чтобы разрабатывать новые фичи. Возможно, кто-то возразит, что доработки и обновления неизбежны, а старый код нуждается в сопровождении. Создание ПО похоже на строительство домов: вам необходимо содержать в хорошем состоянии старые дома и время от времени их обновлять. Или это неправильная логика?
И да, и нет. Проблема кроется в вашем образе мышления.
Один мой наставник, например, весьма цинично относился к ситуации с поддержкой кода. Для него это было чем-то само собой разумеющемся, мол, ничего не поделаешь, так уж устроен мира разработки ПО, жизнь штука сложная, надо к этому привыкать.
Как же можно упростить эту ситуацию?
Иногда застревание в режиме сопровождения кода происходит в результате применения плохих технических решений вкупе с недостатком смелости. Крупная монолитная база исходного кода со сложными зависимостями требует дополнительной работы с точки зрения сопровождения. В противовес ей, хорошо спроектированная инфраструктура, построенная на основе микрослужб, оказывается более гибкой. Неисправную микрослужбу можно легко заменить. Ее можно переписать с нуля, используя другой язык или технологию. Таким образом, вместо того чтобы латать унаследованный код, у вас появляется возможность изучить что-то новое. А если ваша архитектура все еще не позволяет использовать микрослужбы, вы можете улучшать ее поэтапно, одновременно поднимая свой уровень знаний в DevOps.
Стратегия применения микрослужб — только один из подходов к решению проблемы «скучного» сопровождения кода. Некоторые компании даже создают умные инструменты для того, чтобы сделать процесс сопровождения более эффективным и увлекательным. В качестве яркого примера можно привести Facebook и его подход к оптимизации огромной базы PHP исходников. Разработчики компании создали собственные компилятор и язык Hack, использующий статическую типизацию и работающий поверх PHP. Это помогло им упростить процесс сопровождения и оптимизировать рабочий процесс. Подозреваю, что всех проблем с унаследованным кодом эта мера не решила, но благодаря ей жить разработчикам наверняка стало веселее.
Как регулярная «копипаста» делает работу скучной
Есть кодинг, а есть кодинг.
Если посмотреть на мою более раннюю деятельность, то становится понятно, что я создал много никому не нужного кода. К примеру, однажды я писал скрипты на Groovy и Python для интеграции данных. Структура была сложной, содержала десятки непостоянных схем, которые не позволяли добиться сколько-нибудь значимой автоматизации. Поэтому мне пришлось писать много кода. Мои коллеги, работавшие над этой задачей вместе со мной, тогда полагали, что я получил много новой и полезной информации в процессе работы.
Но на самом деле это не так, и я объясню почему.
Все дело в том, что 50% моего кода были прямой копипастой со Stack Overflow, остальные 40% — копипастой других скриптов, авторами которых были либо коллеги, либо я сам. Процесс оказался очень однообразным и творчества или обучения новому в нем было немного.
Как относиться к этой проблеме наша команда?
Будучи одной командой, мы внимательно анализируем типы кода, который каждый из нас пишет. Мы делаем это вместе во время совместных разборов кода и ретроспектив, и если кто-то потратил неделю, работая над совершенно бесполезным кодом, мы пытаемся понять, почему так получилось.
Иногда проблема носит технический характер. Мы можем слишком много времени уделять скриптингу или конфигурированию. Это значит, что нам нужно добиться большей автоматизации. Если у нас возникают реальные основания для использования копипасты, мы стараемся делить ее встраивание в проект поровну между всеми участниками.
Внутренние инструменты обычно делают работу скучной
Нам как разработчикам нравится создавать собственные внутренние инструменты для решения специфических задач, потому что для нас создание чего-то нового — захватывающий процесс. К тому же создание адаптированных к конкретным потребностям решений часто означает более чистый подход, нежели попытки подстроиться под эти потребности уже существующих инструментов. Однако изучение чужих закрытых решений видится нам в 10 раз менее увлекательным, нежели изучение популярных технологий с открытым исходным кодом.
Почему?
Потому что вы не сможете обсудить проприетарные инструменты с друзьями. Не сможете похвастаться, что знаете их. О них не напишут в блогах, а кроме того, ими нельзя воспользоваться на хакатонах или для работы над своим секретным сторонним проектом.
Тем не менее многие компаний попадают в ловушку создания чего-то, что впоследствии только добавляет уныния и потому совершенно не стоит потраченных усилий. Я говорю о таких разработка, которые избавляют вас от краткосрочного беспокойства только для того, чтобы в дальнейшем принести еще больше беспокойства.
Я на собственном опыте убедился в этом на предыдущем месте работы, где мне пришлось использовать разработанный внутри компании предметно ориентированный язык для широкомасштабной интеграции данных. То, что мне на самом деле пришлось изучать, можно, пусть и с небольшим преувеличением, назвать очередным SQL-ным жаргоном. С гораздо большим желанием я предпочел бы изучать и использовать какую-нибудь низкоуровневую открытую технологию вроде Spark, потому что в этом случае я был бы в 10 раз более вовлечен, и даже если бы мой код при этом был в 2 раза избыточнее, это все равно сделало бы меня в 5 раз продуктивнее.
Какой же должна быть культура в компании чтобы предотвратить такие ситуации?
Мы стараемся сохранять сильный уклон в сторону технологий с открытым исходным кодом. Если нам выпадает возможность использовать нечто интересное, имеющее прямое отношение к проблеме и придуманное ранее, мы так и делаем. Мы не избегаем новейших решений, а собственный код заменяем на аналогичные открытые технологии, как только те становится достаточно зрелыми, чтобы заменить его. Мы также сами открываем наши исходники, как только они теряют свою уникальность.
Время от времени случаются ошибки. К примеру, мы какое-то время использовали библиотеку agenda.js для планирования заданий по серверной части, потому что считали ее современной и интересной. Однако в нашем случае оказалось, что она все усложняет, поэтому было принято решение вернуться к старой, но более надежной технологии — старому доброму cron. И тем не менее мы не жалеем об этом эксперименте, потому что для нас это был ценный опыт.
Как monkey-coding делает вас скучным
Другая распространенная причина потери интереса к работе — плохое управление людьми. Я имею в виду структуру управления «сверху вниз», которая применяется в среде разработчиков и нередко приводит к диктатуре вышестоящих.
Иногда руководители, сами того не понимая, используют именно такой подход, делая это из благих побуждений. Особенно часто это происходит, когда дела в проекте идут не очень хорошо, или во время приближения дедлайна. Это естественная реакция человека, находящегося под давлением, — стараться прервать обсуждения, свести до минимума «мозговые штурмы», вместо этого выдавая подчиненным прямые указания о том, что надо сделать, без каких-либо споров или объяснений. Конечно же, все это делается ради экономии времени и получения необходимого результат.
Совсем необязательно подчиненный, который с пониманием относится к ситуации, будет недоволен происходящим. На самом деле некоторые будут даже рады время от времени получать конкретные указания относительно того, что надо делать, ведь это упрощает рабочий процесс. Все это, конечно, при условии, что такие указания даются подобающим образом.
Тем не менее у такого подхода есть свои скрытые издержки. Знание того, какой именно код надо писать, еще до начала самой работы превращает программирование из интеллектуального и творческого процесса в чисто механический. Иными словами, «девелопер» превращается в «манки кодера».
В то же время, активный, вовлеченный в процесс разработчик, напротив, старается вникнуть в суть того, почему делать надо так, а не иначе, если, конечно, речь идет не о таких очевидных вещах, как временный патч или хак для обхода пограничного случая. Но если он начинает понимать, что ему безразличны те или иные важные решения и причины, которые за ними стоят, значит, ему пора менять свою работу.
Как предотвратить возникновение такой ситуации?
Главное что для этого нужно — культура, которая поощряет открытые дискуссии. Создайте площадку для регулярных обсуждений, где вы будете вместе как одна команда вырабатывать стратегии и строить планы. Следить за тем, чтобы эта культура сохранялась — дело каждого члена команды. Именно в самые непростые времена подопечные должны говорить громче, а их руководители слушать внимательно.
Повседневность всегда становится скучной
И последний, но не менее важный момент. Нет лучше способа убить интерес и увлечение, чем поместить себя в замкнутое пространство и заняться какой-нибудь рутинной деятельностью.
Это проблема встречается не только в разработке ПО или технической сфере: она характерна для любой офисной работы. Каждый день вы находитесь в одном и том же помещении, с теми же людьми, выполняя те же рабочие обязанности, и все это — в обстановке, которая почти не меняется… И даже если рабочее пространство быстро расширяется, а его внутренняя стабильность объективно полезна, люди все равно начинают принимать все хорошее как должное и раздражаться из-за того, что им не нравится.
Как мы с этим боремся?
Ключевой компонент профилактики — многообразие. Мы нанимаем людей с разными опытом и происхождением. Наша текущая команда состоит из 6 человек, среди которых есть представители Британии, Франции, России и Греции. Видеть одних и тех же людей каждый день определенно гораздо интереснее, если каждый из них может привнести что-то новое в общую культуру.
Мы также стараемся разнообразить повседневную активность и выйти за рамки обычной рабочей схемы.
К примеру, мы вместе ходим на публичные митапы и хакатоны. У нас есть сторонние проекты и, кроме того, мы вносим вклад в развитие наших любимых «опенсорсных» инструментов. Время от времени мы даже помогаем остальной части команды по непрофильной для нас работе, такой как наем персонала, маркетинг, распространение продукции. Конечно, нельзя сказать, что мы во всем этом разбираемся, но мы делаем это просто для разнообразия.
Кроме того, мы выбираемся куда-нибудь всей командой (в Secret Cinema, например), а также проводим еженедельный «энкитон»(Enki + hackaton) без какой-либо заранее оговоренной программы. Иногда во время таких встреч мы что-нибудь вместе разбираем, или «штурмуем» новую идею. Иногда мы просто играем в Лигу Легенд или идем в паб. Все прелесть в том, что мы до самого последнего момента не знаем, что будем делать, пока вместе не решим.
Немного хаоса — последний ингредиент в нашем рецепте против скуки. И как и любой другой рецепт, его можно совершенствовать бесконечно. Если что-то не так просто меняем ингредиенты, или их пропорции и пробуем снова.
Как видите, рецепт «нескучного кодинга» открыт и прост. Будь вы руководителем своей команды или рядовым сотрудником, вы в силах сделать вашу работу эффективнее и интереснее. Развивайтесь, стремитесь к новым целям, не зацикливайтесь на одной задаче, особенно, если работа над ней не приносит должного результата. Время от времени переключайте внимание на другие проекты. Анализируйте свою работу, лучше коллективно, так вы быстрее найдете «проблемные места». Не бойтесь высказать новые идеи, проявляйте творческий подход, иначе программирование превратиться в механический процесс, а это просто-напросто скучно. Ну и конечно сложно быть сплоченной командой, не имея других точек соприкосновения, кроме того, что вы работаете в одной компании. Меняйте обстановку, выбирайтесь с коллегами на отдых, вместе осваивайте новые горизонты, и вам вряд ли захочется уйти.
Материал к публикации подготовлен компанией PayOnline, международной системой для приема электронных платежей. Если вам нужно организовать прием платежей на сайте, смело обращайтесь. Также подписывайтесь на наш корпоративный блог, впереди еще много интересных постов.
