Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 20
А как вы измеряете продуктивность программиста? В объеме кода?
Согласен. Нельзя сравнивать программиста с каменщиком. Хотя, каменщик Вася, который кладет обычный кирпич, будет «продуктивнее», чем каменщик Анатолий, который кладет декоративную кладку.
Думаю тот, у кого вы это спросили — никак не измеряет, он просто перевел статью.
Вопрос, в общем-то, риторический…
Тем более ;)
Чисто мое мнение продуктивность программиста можно измерить только способностью всегда в адекватные сроки выполнять возложенные задачи, либо, в случае их неадекватности, убедительно доказать это, поставив такие, в которые он уложится.
Вся кухня «внутри» типа количества кода — вообще не может являться показателем, то понятно. Хотя некоторые считают именно так.
Чисто мое мнение продуктивность программиста можно измерить только способностью всегда в адекватные сроки выполнять возложенные задачи, либо, в случае их неадекватности, убедительно доказать это, поставив такие, в которые он уложится.
Вся кухня «внутри» типа количества кода — вообще не может являться показателем, то понятно. Хотя некоторые считают именно так.
Скорее в соответствии с поставленными сроками.
Чтобы корова давала больше молока и меньше ела, её надо соот. меньше кормить и чаще доить.
Да, к сожалению все так и есть, продуктивность в профессии программиста очень абстрактная величина, и очень много факторов на нее влияют.
Например, написать код, так сказать, в строчку — без документации, соглашений о коде, и вообще всякого рода подобии структуры — в принципе реально даже с проектом среднего масштаба, не говоря уже о мелких, которые пишутся так повсеместно, и с одной стороны это вроде как эффективно, с другой это в разы увеличивает затраты на дальнейшую поддержку и доработку, но с третьей стороны эта поддержка и доработка может и не понадобится :)
Ну или например давний спор насчет писать с нуля или использовать готовые решения. С одной стороны кажется что готовое решение — это быстрее и лучше, но с другой готовое решение нужно еще грамотно интегрировать, подогнать под решение конкретных задач, чаще всего авторы при разработке таких вот «решений» не ограничиваются «считает 2 + 2 в полнолуние», а пытаются запихать все что попадется на глаза, за исключением разве что выпечки пирожков :) И для какого-либо несложного функционала поиск хорошего решения может занять больше времени чем собственно разработка с нуля. У готового решения могут быть дополнительные фичи, которые сначала вроде и не нужны, а потом понадобились — и вот они, и это сократит время, а могут быть и дополнительные баги, которые отловить будет уже значительно сложнее, нежели в собственноручно написанном коде, и это наоборот увеличит время разработки.
Ну а по личному опыту — больше получает тот программист, который больше попросит, создав при этом нужный уровень видимости профессионализма :) Чем больше видимости — тем больше денег :) Профессионализм при этом желателен — но не обязателен :)
Например, написать код, так сказать, в строчку — без документации, соглашений о коде, и вообще всякого рода подобии структуры — в принципе реально даже с проектом среднего масштаба, не говоря уже о мелких, которые пишутся так повсеместно, и с одной стороны это вроде как эффективно, с другой это в разы увеличивает затраты на дальнейшую поддержку и доработку, но с третьей стороны эта поддержка и доработка может и не понадобится :)
Ну или например давний спор насчет писать с нуля или использовать готовые решения. С одной стороны кажется что готовое решение — это быстрее и лучше, но с другой готовое решение нужно еще грамотно интегрировать, подогнать под решение конкретных задач, чаще всего авторы при разработке таких вот «решений» не ограничиваются «считает 2 + 2 в полнолуние», а пытаются запихать все что попадется на глаза, за исключением разве что выпечки пирожков :) И для какого-либо несложного функционала поиск хорошего решения может занять больше времени чем собственно разработка с нуля. У готового решения могут быть дополнительные фичи, которые сначала вроде и не нужны, а потом понадобились — и вот они, и это сократит время, а могут быть и дополнительные баги, которые отловить будет уже значительно сложнее, нежели в собственноручно написанном коде, и это наоборот увеличит время разработки.
Ну а по личному опыту — больше получает тот программист, который больше попросит, создав при этом нужный уровень видимости профессионализма :) Чем больше видимости — тем больше денег :) Профессионализм при этом желателен — но не обязателен :)
Хех, забыли о поддержке и расширяемости кода :)
Ну а в общем, странно слышать что кто-то в 10 раз эффективнее. Написать коротенькую задачку — может быть. Написать модуль — уже проблематичнее. А уж на длинном проекте, хорошо если десятки процентов разницы видны.
Имхо идеальный суперпрограммист — в первую очередь телепат, который понимает в ТЗ то что там хотели, точнее захотят, а не то что получилось написать. А уж с какой скоростью он впечатывает код — дело десятое, поскольку много раз так бывало что пишишь-пишишь, пошел покурить — пришел — все стер и пара строчек все решает.
Ну а в общем, странно слышать что кто-то в 10 раз эффективнее. Написать коротенькую задачку — может быть. Написать модуль — уже проблематичнее. А уж на длинном проекте, хорошо если десятки процентов разницы видны.
Имхо идеальный суперпрограммист — в первую очередь телепат, который понимает в ТЗ то что там хотели, точнее захотят, а не то что получилось написать. А уж с какой скоростью он впечатывает код — дело десятое, поскольку много раз так бывало что пишишь-пишишь, пошел покурить — пришел — все стер и пара строчек все решает.
В принципе, есть куча разных метрик для оценки труда программиста, их можно даже использовать, но стопроцентной качественной оценки не получится. Но метрики всё равно полезны.
Потому что если платить пропорционально продуктивности, то продуктивность снижается. Уже провели кучу исследований на эту тему.
Как кто-то будучи в 10 раз продуктивнее соратников может остаться незамеченным?
Очень просто, не во всех компаниях уделяют достаточно внимания чтоб определять продуктивность (для них программисты это как шаманы, делают там что-то непонятное...)
Опять же стереотипы. Некоторые начальники хотят не получить продукт, а видеть что люди работают.
Работал как-то над одним продуктом, умудрялся за час переделать всё что коллега делал вчерашний рабочий день (а делал он так словно учится кодить первый месяц) и ещё за час, сделать то что ожидали от меня. В итоге начальник видел что я постоянно отдыхаю, а коллега постоянно работает, меня просто выкинули и сказали «ты лентяй, мало работаешь» (Слава богу это выяснилось в первый же месяц, работать на таких я и сам не рад.)
Если бы каменщик работал в 10 раз эффективнее своих коллег, это также было бы очевидно
Нет, там ещё сложнее чем в программировании, нельзя уложить больше некоторого количества рядов пока не затвердеет, иначе стенка искривится, и через сутки всё всплывёт и придётся всё переделывать опять, в итоге хороший каменщик может укладывать в 10 раз медленнее, постоянно отдыхать и пить кофе, однако пользы от него будет намного больше.
Наткнулся еще вот на такую статью: «Видно ли, что программист работает?»
К счастью, все не настолько плохо как описано в статье. Если ваш начальник определяет производительность по внешнему виду, а не по количеству/качеству решенных задач — надо менять место работы (или начальника).
Нельзя дать оценку эффективности инженерного труда, потому что любая более-менее значительная разработка — дело командное. Потому говорить можно об эффективности команды.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему программистам не платят пропорционально их продуктивности