Страдать на работе — не обязательно

    Смотрел я тут на днях выступление Kate Gregory на конференции Pacific++ 2018.

    Видео выступления


    Кейт — хороший программист и отличный спикер. Сам доклад поднимает много интересного о программировании на С++ и программировании вообще (стоит посмотреть). Но больше всего меня зацепила одна высказанная ею (буквально вскользь) мысль. Кейт удалось очень кратко и по делу обозначить мотивацию программистов. Звучала она так: «Программист во время работы стремится максимизировать своё счастье». Это звучит банально, но ведь так оно и есть.

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

    Сразу хочу вынести за скобки вопросы оплаты труда, условий работы, начальства, коллектива и прочего. Если вы работаете там, где работаете — то всё это вас примерно устраивает. Давайте сфокусируемся на том, что делает нас счастливыми и несчастными при непосредственной работе над кодом.

    Тесты


    Все проекты с тестами счастливы одинаково, каждый проект без тестов несчастен по-своему. Я могу с уверенностью сказать, что программисты в проектах с хорошим тестовым покрытием в среднем более счастливы, чем в проектах без тестов вообще. Я даже видел, как программисты, которым начальство не согласовывало написание полноценных тестов, писали их втайне (иногда даже во внерабочее время). Почему это происходило? Написанный тест делает программиста счастливее. Само его существование — уже признак того, что хоть что-то в вашем проекте делается согласно лучшим практикам индустрии (даже если остальное нет). Успешно завершившийся тест показывает красивую зелёную галочку, хвалит программиста (а ведь его, может быть, никто больше и не похвалит). Успешное завершение 100% тестов даёт какую-то устойчивую почву под ногами, когда уже во что-то можно верить — это добавляет нам уверенности в сегодняшнем и завтрашнем дне, делает счастливее. И даже проваленный тест выполняет свою работу — сообщает нам, что мы не зря его написали, хвалит нас за предусмотрительность. Хотите сделать программиста счастливее — разрешите ему (или даже в принудительном порядке обяжите его) писать тесты (конечно, всё хорошо в меру).

    Багфиксинг и разработка нового функционала


    «Я вам не скажу за всю Одессу», но большинство встреченных мною в жизни программистов больше любили писать новый функционал, чем багфиксить legacу-код. А почему? А потому, что прикосновение к багу — это прикосновение к чужому несчастью. Что-то у кого-то пошло не так и это было настолько важно, что он не поленился донести своё горе аж до разработчика. Придётся входить в его положение, пытаться воспроизвести. А дальше ведь либо получится воспроизвести — и будет удар по самолюбию из-за допущенного бага, либо не получится и придётся (о боже, нет!) контактировать с живым человеком, обнаружившим проблему, и пытаться раздобыть больше информации. Всё это нельзя назвать приятным.

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

    Какой отсюда вывод? Работа программиста должна быть сбалансирована, в ней не должно быть одного багфиксинга. Каждому программисту нужно время от времени поручать разработку новых фич. Да, от багфиксинга никуда не деться, но мы хотя бы можем попробовать достичь «примерно нулевого» баланса счастья и несчастья в этом вопросе.

    Рефакторинг


    Работать с хорошим кодом — приятно. К сожалению, хороший код не падает с неба. Его даже невозможно взять и написать с первого раза. Мы должны сделать хороший код из плохого, поскольку его больше не из чего сделать. Здесь программисты делают выбор: каждый день, приходя на работу, продолжать страдать и работать с плохим кодом или же всё-таки взять и постараться сделать из него хороший. Во втором случае часто приходится воевать с руководством, которое не понимает, на что можно было потратить вот эти N часов времени, если новых фич в продукте не добавилось и старых багов тоже исправлено не было. Да, приходится воевать. К счастью, в этой войне у нас есть аргументы: лаконичный и красивый код менее подвержен ошибкам, его поддержка занимает меньше времени (и стоит меньше денег), он лучше поддаётся изменениям при появлении новых бизнес-требований и т.д. Кроме того, эта война, как правило, не продолжительна: она заканчивается каким-то компромиссом вроде «нет, месяц на рефакторинг я не дам, но давайте будем выделять на него 2 часа в неделю по пятницам». Окей, уже хорошо. Мы только что добыли себе кусочек счастья. Да, его ещё нужно будет построить собственными руками, но это уже стало возможным.

    Использование современных библиотек и инструментов


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

    Кстати, потраченное на столь полезные задачи время на самом деле может не только сделать вас чуть счастливее здесь и сейчас, но и устранить те самые «страшные» причины, по которым невозможно было перейти на использование более новых инструментов. Реальная ситуация из моей жизни:
    — Мы не уверены, что переход на новую библиотеку не принесёт нам новых проблем…
    — А вот я написал 200 тестов на код, использующий эту библиотеку, давайте попробуем перейти и запустим их.
    — Хм, ну давай.
    Через 2 недели — новая библиотека в продакшене.

    Можно, наверное, продолжать исследовать и другие аспекты. Но общая мысль одна: некоторые задачи и обстоятельства делают программиста счастливее, другие — несчастнее. Если вторых будет больше, чем первых — настроение и продуктивность программиста будет падать, рано или поздно это приведёт к проблемам в проекте или к его уходу из команды. Поэтому и сам программист, и его руководитель должны задумываться не только о «глобальном благе» проекта, компании или пользователя, но и том, как при этом оставаться относительно счастливым разработчику. А иначе в чём смысл?
    Инфопульс Украина
    Creating Value, Delivering Excellence
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 14

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

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

        С тестами не всё так очевидно.


        Да, наличие достаточного количества хороших тестов однозначно делает разработчиков счастливее. А вот наличие хрупких тестов — наоборот. Недостаточное количество тестов, даже хороших, мало на что влияет, в т.ч. и на счастье разработчика.


        Написание тестов… не буду говорить за всех, возможно есть фанаты этого дела, но я пока не встречал ни одного разработчика, который бы становился счастливее в момент написания тестов — включая меня самого, хотя я абсолютно добровольно пишу тесты примерно 30% времени. С этим, правда, можно бороться — разработка разных моков и специализированных DDL для сложных тестов это вполне полноценное и интересное программирование, которое сильно компенсирует нудность тестирования и может даже вывести средний баланс счастья при работе над тестами в плюс.


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

          +1

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

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

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

                0

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

            +1
            Видел несложную программулину, автор которой был очень счастлив после покрытия тестами 70% кода. На этом основании она уехала в прод. Одна беда: программулина работала некорректно, а покрыты были всякие вспомогательные вещи типа чтения конфигов. Зато программист счастлив.

            больше любили писать новый функционал, чем багфиксить legacу-код. А почему?

            Потому что в среднем баги ловить сложнее, чем писать код, их содержащий. Плюс за отлов багов не премируют, а за фичи — пожалуйста.
              0
              Потому что в среднем баги ловить сложнее, чем писать код, их содержащий.

              Как по мне, дело вовсе не в сложности. Основной недостаток багфиксинга в том, что он практически никак не повышает квалификацию, т.е. время, которое тратится на баги — это чистая потеря в плане профессионального развития. А времени они могут съедать очень много. Именно поэтому я предпочитаю тратить время на тесты — тоже не самое интересное занятие, но в результате эта стратегия позволяет мне бóльшую часть рабочего времени проводить не только с пользой для проекта, но и с пользой лично для себя, в плане профессионального роста, при этом на баги, в среднем, уходит максимум 5% моего времени. Кстати, ещё с этим помогает стратегия фиксить 99% багов в первую очередь, буквально в течении пары дней после их обнаружения — если не разрешать себе складировать баги в трекере на неопределённое время то резко повышается мотивация делать по-меньше багов, раз уж увернуться от их исправления возможности всё-равно нет.

                0
                которое тратится на баги — это чистая потеря в плане профессионального развития

                А ничего, что зная как такой баг возник, можно впоследствии применять методы решения, чтобы таких багов не возникало? По мне так это неотъемлемая часть «развития».

                К слову, из наблюдений:
                Я смотрю, во фронтенде сейчас все внезапно стали «профессионально развиваться», штудируя один фреймворк за другим, вот только на выходе получаем баги вида: в ios прыгает кнопка, или fixed-элемент, cordova валится с эксепшеном (оказывается дело не в недостатке памяти на устройстве, а в рендере гребанных филдов на условных формах), а десктопные chrome/firefox показывает разные размеры элементов и т.д. и т.п. И ты впоследствии сидишь такой «че ваще происходит», а оказывается эти «профессионально развивающиеся» так «профессионально» накодировали, что логику переделывать надо.
                  0

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

                  0
                  время, которое тратится на баги — это чистая потеря в плане профессионального развития

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

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


                    Но я имел в виду немного другое: если желание развиваться есть, то написание практически любого кода предоставляет бесконечные возможности чему-то научиться в процессе, в то время как поиск багов такие возможности почти не предоставляет — узнать что-то действительно новое и полезное во время поиска и исправления бага удаётся крайне редко.


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

                0
                Если вас все устраивает в вашем коде это лишь означает, что он или слишком юн или никому не нужен. По мере взросления код начинает устраивать все меньше и меньше т.к. становится все страшнее и страшнее. При этом, парадоксально! все нужнее и нужнее. И в какой-то момент — «пора, мой друг, пора!». Дарить добро куда подальше. Желательно чтобы не догнали.
                  +1
                  Насчёт багфиксинга немного не соглашусь. Да, бывают скучные, рутинные баги, которые чинятся на автомате; бывают мутные баги, где ничего не понятно, а заказчик уже одновременно истерит и тупит, не давая требуемой информации, или давая не то, или используя мозжечок вместо мозга (вместо файла — скриншот в doc'е, сливая гигабайтные дампы в несжатом виде через дохлый канал и т.д.). Но. Бывают такие, не побоюсь этого слова, красивые баги, когда всё совершенно непонятно, и неясно, в какую сторону вообще копать; и появляется одна идея (нет, не то), другая (опять мимо), и, наконец, третья (хм, а вот это интересно… Да ладно! Не может быть!), и тут на тебя нисходит просветление, и ты вдруг ясно понимаешь, как именно она появилась, и как всё работало раньше, и почему вдруг перестало работать — все кусочки паззла складываются воедино; и ты чинишь, запускаешь с замиранием сердца, и тут…
                  image
                  О да! Всё работает как часы! Особенно круто, когда вы искали этот баг в компании (хотя бы вдвоём), и именно тебе пришло в голову решение. О таких багах приятно рассказывать в кругу таких же ботаников, как ты, которые могут оценить всю глубину разверзшейся перед тобой задницы и всю красоту найденного решения.

                  Чинить баги тоже иногда интересно.

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

                  Самое читаемое