Страдать на работе — не обязательно
Смотрел я тут на днях выступление Kate Gregory на конференции Pacific++ 2018.
Кейт — хороший программист и отличный спикер. Сам доклад поднимает много интересного о программировании на С++ и программировании вообще (стоит посмотреть). Но больше всего меня зацепила одна высказанная ею (буквально вскользь) мысль. Кейт удалось очень кратко и по делу обозначить мотивацию программистов. Звучала она так: «Программист во время работы стремится максимизировать своё счастье». Это звучит банально, но ведь так оно и есть.
Мы можем говорить, что болеем за проект, заказчика, компанию, человечество и мир во всём мире (и это даже может быть правдой). Но давайте будем честны. Мы люди и, как все люди, в первую очередь стремимся максимизировать своё счастье — глобально во всей жизни, стратегически в карьере, тактически в текущем проекте и мелочно здесь и сейчас, при написании вот этой функции, вот этой строки кода. Да, мы это делаем и было бы хорошо разобраться, что делает нас более счастливыми, а что — менее. Это позволит нам лучше понимать коллег, подчинённых да и самих себя.
Сразу хочу вынести за скобки вопросы оплаты труда, условий работы, начальства, коллектива и прочего. Если вы работаете там, где работаете — то всё это вас примерно устраивает. Давайте сфокусируемся на том, что делает нас счастливыми и несчастными при непосредственной работе над кодом.
Тесты
Все проекты с тестами счастливы одинаково, каждый проект без тестов несчастен по-своему. Я могу с уверенностью сказать, что программисты в проектах с хорошим тестовым покрытием в среднем более счастливы, чем в проектах без тестов вообще. Я даже видел, как программисты, которым начальство не согласовывало написание полноценных тестов, писали их втайне (иногда даже во внерабочее время). Почему это происходило? Написанный тест делает программиста счастливее. Само его существование — уже признак того, что хоть что-то в вашем проекте делается согласно лучшим практикам индустрии (даже если остальное нет). Успешно завершившийся тест показывает красивую зелёную галочку, хвалит программиста (а ведь его, может быть, никто больше и не похвалит). Успешное завершение 100% тестов даёт какую-то устойчивую почву под ногами, когда уже во что-то можно верить — это добавляет нам уверенности в сегодняшнем и завтрашнем дне, делает счастливее. И даже проваленный тест выполняет свою работу — сообщает нам, что мы не зря его написали, хвалит нас за предусмотрительность. Хотите сделать программиста счастливее — разрешите ему (или даже в принудительном порядке обяжите его) писать тесты (конечно, всё хорошо в меру).
Багфиксинг и разработка нового функционала
«Я вам не скажу за всю Одессу», но большинство встреченных мною в жизни программистов больше любили писать новый функционал, чем багфиксить legacу-код. А почему? А потому, что прикосновение к багу — это прикосновение к чужому несчастью. Что-то у кого-то пошло не так и это было настолько важно, что он не поленился донести своё горе аж до разработчика. Придётся входить в его положение, пытаться воспроизвести. А дальше ведь либо получится воспроизвести — и будет удар по самолюбию из-за допущенного бага, либо не получится и придётся (о боже, нет!) контактировать с живым человеком, обнаружившим проблему, и пытаться раздобыть больше информации. Всё это нельзя назвать приятным.
В то же время написание нового функционала — это потенциальное прикосновение к счастью. Мы пока ещё ничего не сломали, ни в чём не виноваты. Мы пишем новый код, чтобы решать новые задачи. Возможно, это удастся. Возможно, мы получим заслуженную похвалу (премию, повышение). Это уже ближе к верхним уровням пирамиды потребностей человека по Маслоу.
Какой отсюда вывод? Работа программиста должна быть сбалансирована, в ней не должно быть одного багфиксинга. Каждому программисту нужно время от времени поручать разработку новых фич. Да, от багфиксинга никуда не деться, но мы хотя бы можем попробовать достичь «примерно нулевого» баланса счастья и несчастья в этом вопросе.
Рефакторинг
Работать с хорошим кодом — приятно. К сожалению, хороший код не падает с неба. Его даже невозможно взять и написать с первого раза. Мы должны сделать хороший код из плохого, поскольку его больше не из чего сделать. Здесь программисты делают выбор: каждый день, приходя на работу, продолжать страдать и работать с плохим кодом или же всё-таки взять и постараться сделать из него хороший. Во втором случае часто приходится воевать с руководством, которое не понимает, на что можно было потратить вот эти N часов времени, если новых фич в продукте не добавилось и старых багов тоже исправлено не было. Да, приходится воевать. К счастью, в этой войне у нас есть аргументы: лаконичный и красивый код менее подвержен ошибкам, его поддержка занимает меньше времени (и стоит меньше денег), он лучше поддаётся изменениям при появлении новых бизнес-требований и т.д. Кроме того, эта война, как правило, не продолжительна: она заканчивается каким-то компромиссом вроде «нет, месяц на рефакторинг я не дам, но давайте будем выделять на него 2 часа в неделю по пятницам». Окей, уже хорошо. Мы только что добыли себе кусочек счастья. Да, его ещё нужно будет построить собственными руками, но это уже стало возможным.
Использование современных библиотек и инструментов
Многим, наверное, известна боль от необходимости работать в проекте, застрявшем по какой-то причине на компиляторе (фреймворке, библиотеке) многолетней давности. Нам объясняют, что вот по таким-то и таким-то причинам нельзя перейти на новую версию вот здесь и вот сейчас, но когда-нибудь, наверное, если получится… Что тут можно поделать? Ну, во-первых, нужно признаться самим себе в том, что обстоятельства сложились не в нашу пользу и ситуация делает нас несчастнее, чем мы могли бы быть. Во-вторых, эту же мысль можно озвучить и начальству (или заказчику). Вряд ли кто-то будет с этим спорить. И вот в этот момент можно попробовать себе что-то выторговать: например, время на те самые тесты, новый функционал и рефакторинг. (Можно и прибавку к зарплате, но в начале статьи я пообещал оставить это за скобками).
Кстати, потраченное на столь полезные задачи время на самом деле может не только сделать вас чуть счастливее здесь и сейчас, но и устранить те самые «страшные» причины, по которым невозможно было перейти на использование более новых инструментов. Реальная ситуация из моей жизни:
— Мы не уверены, что переход на новую библиотеку не принесёт нам новых проблем…
— А вот я написал 200 тестов на код, использующий эту библиотеку, давайте попробуем перейти и запустим их.
— Хм, ну давай.
Через 2 недели — новая библиотека в продакшене.
Можно, наверное, продолжать исследовать и другие аспекты. Но общая мысль одна: некоторые задачи и обстоятельства делают программиста счастливее, другие — несчастнее. Если вторых будет больше, чем первых — настроение и продуктивность программиста будет падать, рано или поздно это приведёт к проблемам в проекте или к его уходу из команды. Поэтому и сам программист, и его руководитель должны задумываться не только о «глобальном благе» проекта, компании или пользователя, но и том, как при этом оставаться относительно счастливым разработчику. А иначе в чём смысл?
