Как оценить труд программистов?
Рассказывает Майк Хэдлоу, автор блога mikehadlow.blogspot.ru
Когда кто-то выполняет тяжелую физическую работу, мы легко можем оценить, насколько он старается: вы можете видеть сам процесс работы, чувствовать запах пота. Кроме того, наглядно виден и результат: кирпичная стена становится выше, дыра в земле становится глубже. Поощрять тяжелую физическую работу — один из человеческих инстинктов. Вот почему все мы так любим виды спорта на выносливость (футбол, регби, баскетбол и т.д.). А вот оценить старания программистов гораздо сложнее. Порой по ним вообще нельзя сказать, что они работают!
В 2004-ом году я работал в компании-провайдере кабельного ТВ. Как и в любой большой организации, штат нашей компании был разделен на несколько относительно независимых групп разработчиков, у каждой из которых было свое назначение. Аналоговым ТВ и цифровым занимались совершенно разные подразделения.
Подразделение аналогового ТВ спроектировало свою систему на основе ранней версии Microsoft Biztalk. Разрабатывали и поддерживали ее четверо наших сотрудников и парни из Microsoft. Все работали на пределе своих сил: часто по ночам и на выходных. Бывало, что они все собирались за одним столом и компьютером, и каждый выдвигал свои предложения по поводу того, как можно улучшить или исправить код. Все подразделение находилось в постоянной деятельности и работало командой.
Подразделение цифрового ТВ было устроено совершенно иначе. Большая часть кода была написана одним человеком. Будем называть его Дейв. Я был в этом подразделении джуниором. Сначала мне было сложно понимать код Дейва — не было длинных процедур, в которых выполнялись все нужные действия, вместо этого было множество мелких классов и методов, каждый не длиннее нескольких строк. Коллеги жаловались на Дейва, мол, он переусложняет очевидные вещи. Но потом он взял меня под свое крыло, предложил несколько книг по ООП, рассказал про принципы SOLID и юнит-тестирование. После того, как я вник во все это, код Дейва стал казаться мне элегантным и понятно устроенным, я стал ценить его красоту. C ним никогда не было проблем, а изменения было вносить так же просто, как писать новый код. Юнит-тесты отлавливали те редкие баги, которые все-таки пробивались в продакшн.
В результате это все выглядело так, как будто мы с Дейвом почти не трудились — никогда не засиживались допоздна, не приходили по выходным, в отличие от людей из подразделения аналогового ТВ, круглосуточно гадающих, что работает не так в их коде. Могло показаться, что требования к нам и аналоговому ТВ совершенно разные, но на самом деле они были одинаковые — просто мы спроектировали и выстроили инфраструктуру, которую легко поддерживать.
И вот, в один прекрасный день, наш босс говорит нам, что отныне он будет платить зарплату на основе того, как усердно мы работаем. Когда я пошел говорить с ним, он сказал, что мы с Дейвом недостаточно хорошо работаем и совершенно не заботимся о компании, в отличие от героев, которые посвящают этому все свои вечера и выходные.
Наша компания была одним из редких случаев, когда было наглядно видно соответствие между хорошим и плохим дизайном ПО и поведением команды разработчиков. В большинстве организаций нельзя сказать точно, действительно ли программист отдается все свои силы на решение возникающих перед ним сложных задач, или же он просто не справляется. Если вы не можете (а кто может?) позволить себе две команды разработчиков, выполняющих одну и ту же работу, то вы никогда не сможете установить это точно. Как насчет того парня, который зависает в интернете на рабочем месте с 9 до 5? Он просто написал хороший код, или же его работа легче, чем у других? А того, который сидит за рабочим местом днями и ночами, постоянно что-то делая? С точки зрения обывателя, первый работает плохо, а второй хорошо. Ведь если человек постоянно в работе, это значит, что он заботится о ней больше, чем тот, кто ничего не делает.
К чему я все это пишу? Видимость тяжелой работы как правило является индикатором того, что человек не справляется с назначенной ему задачей. Разработка ПО не может осуществляться в условиях, когда программиста постоянно отвлекают, давят на него и т.д. Порой лучший способ решить проблему — просто перестать думать о ней, а пойти хорошо отдохнуть и поспать. Порой, после этого решение приходит само. Одна из моих любимых книг — «Апология математика». В ней Годфри Харди, один из ведущих британских математиков XX-ого века, рассказывает о том, как он проводил свой рабочий день. После 4 часов напряженной умственной работы он весь вечер смотрел крикет ? Более 4 часов ментальной работы в день — это непродуктивно и бесполезно.
А менеджерам я хочу сказать следующее: оценивайте программиста по его результатам, а не по тому, сколько он времени проводит за рабочим местом. Порой бывает не лишним посидеть вместе с ними и понаблюдать за их работой (хотя некоторых это жутко раздражает) — так вы получите представление о том, что они реально делают. А идеальным вариантом является работа из дома: вам придется оценивать разработчиков по их результатам, а не по количеству часов, проведенных за столами, потраченных на написание ужасного кода и вбрасывание «полезных» идей.
Оригинал: «Code Rant: Are Your Programmers working hard, Or Are They Lazy»