На днях я посмотрел выступление Кейт Грегори на конференции Pacific++ 2018. Видео выступления Кейт — хороший программист и отличный оратор.
Сам доклад поднимает много интересного о программировании на C++ и программировании в целом (стоит посмотреть).
Но больше всего меня зацепила одна мысль, высказанная ею (буквально вскользь).
Катя смогла очень кратко и по существу изложить мотивацию программистов.
Звучало это так: «Программист стремится максимизировать свое счастье во время работы».
Звучит банально, но это так.
Можно сказать, что мы болеем за проект, заказчика, компанию, человечество и мир во всем мире (и это может быть даже правдой).
Но давайте будем честными.
Мы люди и, как и все люди, мы в первую очередь стремимся максимизировать свое счастье – глобально на протяжении всей жизни, стратегически в карьере, тактически в текущем проекте, и ежеминутно здесь и сейчас, когда пишем эту функцию, эту строчку кода.
.
Да, мы делаем это, и было бы хорошо разобраться, что делает нас счастливее, а что менее счастливыми.
Это позволит нам лучше понимать наших коллег, подчиненных и самих себя.
Я бы хотел сразу оставить в стороне вопросы заработной платы, условий труда, руководства, кадров и прочего.
Если вы работаете там, где работаете, то все это вас примерно устраивает. Давайте сосредоточимся на том, что делает нас счастливыми и несчастными, когда мы работаем над кодом.
Тесты
Все проекты с тестами одинаково счастливы, каждый проект без тестов несчастлив по-своему.Могу с уверенностью сказать, что программисты в проектах с хорошим тестовым покрытием в среднем счастливее, чем в проектах вообще без тестов.
Я даже видел программистов, которым начальство не давало разрешения на написание полноценных тестов и писало их тайно (иногда даже в нерабочее время).
Почему это случилось? Письменный тест делает программиста счастливее.
Само его существование уже является признаком того, что хоть что-то в вашем проекте сделано в соответствии с лучшими практиками отрасли (даже если остальное — нет).
Успешно пройденный тест показывает красивую зеленую галочку и хвалит программиста (и, возможно, его больше никто не похвалит).
Успешное прохождение 100% испытаний дает нам некую устойчивую почву под ногами, когда мы уже можем во что-то верить – это добавляет нам уверенности в сегодняшнем и завтрашнем дне, делает нас счастливее.
И даже проваленный тест делает свое дело — говорит нам, что мы написали его не просто так, и хвалит нас за дальновидность.
Если вы хотите сделать программиста счастливее, разрешите ему (или даже заставьте) писать тесты (конечно, все хорошо в меру).
Исправление ошибок и разработка нового функционала
«За всю Одессу не скажу», но большинству программистов, которых я встречал в жизни, больше нравилось писать новый функционал, чем исправлять ошибку в устаревшем коде.И почему? А потому, что прикоснуться к жуку – это прикоснуться к чужой беде.
У кого-то что-то пошло не так и это было настолько важно, что он не поленился передать свое горе вплоть до разработчика.
Вам придется поставить себя на его место и попытаться воспроизвести это.
И тогда либо удастся воспроизвести - и будет удар по самолюбию из-за бага, либо не получится и придется (о боже, нет!) обращаться к живому человеку, обнаружившему проблему.
и постарайтесь получить больше информации.
Все это нельзя назвать приятным.
В то же время написание нового функционала — потенциальное счастье.
Мы пока ничего не нарушили, ни в чем не виноваты.
Мы пишем новый код для решения новых проблем.
Возможно, это удастся.
Возможно, мы получим заслуженную похвалу (премию, повышение по службе).
Это уже ближе к верхним уровням пирамиды потребностей человека.
Какой из этого вывод? Работа программиста должна быть сбалансированной; не должно быть только одного исправления ошибки.
Каждому программисту время от времени необходимо поручать разработку новых функций.
Да, от исправления ошибок никуда не деться, но можно хотя бы попытаться добиться в этом вопросе «примерно нулевого» баланса счастья и несчастья.
Рефакторинг
Работать с хорошим кодом одно удовольствие.К сожалению, хороший код не падает с неба.
Даже невозможно взять и написать с первого раза.
Нам приходится делать хороший код из плохого кода, потому что больше его делать не из чего.
Здесь программисты делают выбор: каждый день, приходя на работу, продолжать мучиться и работать с плохим кодом или взять его и попытаться сделать хорошим.
Во втором случае часто приходится бороться с руководством, которое не понимает, на что можно было бы потратить эти N часов времени, если бы в продукт не добавлялось новых функций и не были исправлены старые ошибки.
Да, нам придется сражаться.
К счастью, в этой войне у нас есть аргументы: лаконичный и красивый код менее подвержен ошибкам, его поддержка занимает меньше времени (и стоит меньше денег), он более поддается изменениям при возникновении новых требований бизнеса и т. д. Кроме того, это война, как правило, длится недолго: она заканчивается каким-то компромиссом типа «нет, я не дам вам месяц на рефакторинг, но давайте выделим на него 2 часа в неделю по пятницам».
Ладно это хорошо.
Мы только что получили себе кусочек счастья.
Да, его еще придется строить своими руками, но это уже стало возможным.
Использование современных библиотек и инструментов
Многие люди, вероятно, знают, как больно работать над проектом, который по какой-то причине зависает в компиляторе (фреймворке, библиотеке), которому уже много лет. Нам объясняют, что по таким-то причинам невозможно перейти на новую версию здесь и сейчас, но когда-нибудь, возможно, если получится.Что мы можем сделать? Ну, прежде всего, нам нужно признаться себе, что обстоятельства складываются не в нашу пользу и ситуация делает нас более несчастными, чем мы могли бы быть.
Во-вторых, ту же мысль можно озвучить и начальству (или заказчику).
Вряд ли кто-то с этим будет спорить.
И в этот момент можно попробовать что-нибудь выторговать: например, время на те самые тесты, новый функционал и рефакторинг.
(Возможно также повышение зарплаты, но в начале статьи я обещал не учитывать это).
Кстати, время, потраченное на такие полезные задачи, на самом деле может не только сделать вас немного счастливее здесь и сейчас, но и устранить те самые «страшные» причины, по которым невозможно было перейти на использование более новых инструментов.
Реальная ситуация из моей жизни:
— Мы не уверены, что переход на новую библиотеку не принесет нам новых проблем.Через 2 недели — новая библиотека в производстве.— Но я написал 200 тестов для кода с использованием этой библиотеки, попробуем их запустить.
- Хм, давай.
Вероятно, мы сможем продолжить изучение других аспектов.
Но общая идея одна: одни задачи и обстоятельства делают программиста счастливее, другие — несчастнее.
Если последних будет больше, чем первых, настроение и продуктивность программиста снизятся, рано или поздно это приведет к проблемам в проекте или к его уходу из команды.
Поэтому и сам программист, и его руководитель должны думать не только о «глобальном благе» проекта, компании или пользователя, но и о том, как разработчик может оставаться относительно счастливым.
Иначе какой в этом смысл? Теги: #программирование #Лайфхаки для гиков #управление персоналом #Идеальный код #счастье
-
Киевстар «Потерял» Абонентов
19 Oct, 24 -
Плагин Gizmo Call Для Звонков Из Браузера
19 Oct, 24 -
Китайский Мозг, Или В Защиту Яровой
19 Oct, 24 -
Camelcase Против Under_Score
19 Oct, 24 -
Feedburner Приобрел Сервис Аналитики Блогов
19 Oct, 24 -
Релиз Rubymine 1.1
19 Oct, 24
