Откуда берется эффективность программиста 2

Я получил несколько интересных комментариев на вчерашний пост Откуда берётся эффективность программиста, которые навели меня на мысль, что я не слишком четко изложил свою позицию по этому вопросу.
В комментариях люди пишут, что я не прав, говоря, что эффективность измеряется только временем, проведенным за клавиатурой. Что кто-то за 4 рабочих часа может сделать больше, чем другой за 8.
Но ведь это именно то, о чем я и писал!
Возможно первый пример про “работящего Васю” и “обычного Петю” сбил всех с толку, но этот пример показывает только то, что при прочих равных производительнее будет тот, кто больше времени уделяет работе, а не другим делам. Это вроде как очевидно и споров не должно вызывать.
Другое дело, что разница в производительности (эффективности) между такими Петей и Васей будет не очень-то большой, если они отличаются только усидчивостью - разница будет в процентах или десятках процентов, максимум в 2 раза (хотя бывают и клинические случаи, когда опытнейшие люди просто испытывают уже отвращение к работе и занимаются ей от силы 10% своего времени, но это все же клиника, которую можно не рассматривать).
К тому же редко встретишь программиста, который никогда не ленится или никогда не впадает в “рабочий раш”. Обычно программисты переключаются между режимами Пети и Васи несколько раз в месяц (а некоторые умудряются переключаться и каждый день).


Зато если Петя и Вася отличаются уровнем знаний, опытом и природной одаренностью, то разница в их производительности может уже составлять десятки раз.
Например, даже если Петя сидит за клавиатурой 3 часа в день, а Вася - 8, но при этом Петя одарён и опытен, а Вася - студент, только начавший изучение программирования, то производительность Пети будет в сотни раз выше, чем Васи. И неважно, что он клавиатуру может за целый день даже не потрогать - у него перед Васей такое преимущество, которое тому простой усидчивостью никак не наверстать.

Пример со студентом наиболее нагляден и понятен, но и среди профессионалов существует такая же разница - кто-то просто работает в 10 раз лучше, чем другие. И это сложно чем-то конкретным объяснить - ни опыт, ни знания тут в принципе ни при чем, хотя и оказывают влияние. Но бывает, что программист с 5 годами опыта работает на порядок эффективнее, чем программист с 20 годами опыта.
Вообще, чем дольше я в этой индустрии, тем больше я укрепляюсь в мысли, что программирование сродни искусству. Мы, как художники - либо умеем “рисовать” и делаем шедевры, либо не умеем - и делаем какашки.


Также я получил один интересный комментарий про то, что производительность программиста и его эффективность - это совершенно разные и несравнимые вещи.
Чтож, это зависит от того, что считать “производительностью”, а что “эффективностью”. Если под производительностью программиста кто-то понимает число строк кода, которые тот настрочил, то да - это не эффективность. Строки кода - это вообще не параметр для программиста, как бы не пытались его продвигать любители метрик.
Плохие программисты пишут много кода, который в итоге усложняет программу и в особенности её поддержку в будущем. Такой код пишется быстро, но в будущем он превращается в болото, не дающее развивать программу дальше и тянущее весь проект на дно.
Хорошие программисты пишут мало строк кода, которые делают много работы. Такой код уже гораздо легче понимать, развивать и поддерживать.
А лучшие программисты берут проект и уменьшают число строк кода в нем, делая код проще и надежнее и добавляя при этом новую функциональность. У них что, отрицательная производительность?
Для меня производительность программиста - это умение решать поставленную задачу за определенное время. Например, Вася получил User Story и сделал ее за 5 дней. А Петя такую же User Story сделал с тем же уровнем качества за 10 дней. Очевидно, что Вася в 2 раза более производителен. И также очевидно, что он в 2 раза более эффективен, так как делает в 2 раза больше за то же время.
А сколько строк кода каждый из них написал или удалил - это неважно.
Проблема же измерения эффективности в том, что у программистов нет эталонных задач, которые можно было бы давать периодически Васе и Пете и сравнивать их эффективность. Все задачи разные и сравнивать время, потраченное на разные фичи разными людьми - это занятие неблагодарное.
А дать двум программистам для сравнения реализовать одну и ту же фичу независимо друг от друга - на это менеджмент никогда не пойдет, “ибо неэффективно”. Может и зря…


Похожие записи:
Откуда берется эффективность программиста
Один день из жизни Программиста
10 заповедей для программистов
Shu-ha-ri для программистов
Непрограммирующие программисты
25 самых опасных программистских ошибок

15 комментариев к Откуда берется эффективность программиста 2

  • ganjubas

    Позволю себе снова откомментировать, ибо анализу моего предыдущего комента уделен целый параграф :) Автор, вы совершенно правы в том, что

    это зависит от того, что считать “производительностью”, а что “эффективностью”.

    Я как раз про то и говорил, что в своей оригинальной статье вы отождествляете эти два понятия, заменяя одно другим. В то время как я считаю, что это неверно. “продуктивность” - это кол-во пользы (или estimate этого самого кол-ва), которую программист нанес проекту. А вот эффективность (в моих терминах) - это скорость, с которой программист способен наносить эту пользу. Я ни в коем разе не имел в виду кол-во строк кода как метрику эффективности и уж тем более продуктивности программистов.

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

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

    • Я понимаю, что вы имеете в виду. Переводя на физические термины, получается, что эффективность - это скорость, а продуктивность - это расстояние, пройденное за время проекта. S=V*T. А значит, что продуктивность прямо пропорциональна эффективности, а значит их можно и нужно сравнивать :) Программист с лучшей эффективностью “напродуктивит” больше, чем программист с меньшей эффективностью за то же время.

      В конце концов это всего лишь семантика терминов - хороший программист он и в африке хороший программист :)

      Это точно! Хотя хотел бы я посмотреть на хорошего программиста из Африки :)

  • ganjubas

    да, теперь я думаю мы с вами on the same page что называется :) Однако сравнивать V и S с точки зрения физики все-таки не корректно :)

  • Me

    В неблагодарную тему вы ввязались ;)

  • Стас Агарков

    Я работаю по методологии scrum уже 8 месяцев, но до сих не могу понять, почему задача называется User Story. Насколько я понимаю, это переводится как «История пользователя». Где тут связь с задачей, скажите, пожалуйста. Единственное, что приходит на ум это то, что пользователь — это пользователь программы, а история — это история, которую пользователь рассказал о своей проблеме с программой программисту. Но все же хочется узнать мнение профессионала.

    • Хороший вопрос. Про User Story даже книги написаны - про то, как их правильно писать.
      Грубо говоря, User Story - это фича, сформулированная на языке пользователя. А ее уже потом делит команда на задачи.

      Например, юзер стори: “Я, как пользователь программы, хочу, чтобы программа сама автоматичеки обновлялась, но спрашивала у меня, хочу ли я обновиться в данный момент”. Эту юзер стори получает команда и не может ее сделать в одном спринте - команда делит ее за задачи, которые вписывает в спринты, например:
      - создание сервера для хранения апдейтов.
      - создание работающей системы апдейтов
      - интеграция системы апдейтов в программу
      - создание интерфейса для вопроса пользователю об установке
      и т.п.
      Задачи гораздо меньше, чем юзер стори.

      Причем пользователем может быть кто угодно, не только реальный потребитель, но и, например, программист из другого отдела:
      “Я, как программист, использующий вашу библиотеку, хочу, чтобы она предоставляла мне возможность секьюрной коммуникации с сервером”.

  • Роман

    Я оцениваю эффективность программиста исключительно субъективно, в процессе работы над тестовым проектом, например таким (не сочтите за рекламу) http://home.smartdev.pp.ua/redmine/boards/1/topics/1

  • Роман

    На самом деле это не совсем тестовый проект - это попытка убить двух зайцев: оутсорсить не слишком денежный и не слишком срочный проект (но который тем не менее нужно выполнить из-за предыдущих обязательств) и заодно подыскать толковых исполнителей для дальнейшего сотрудничества.

  • Xor

    Насчёт “дать одну задачу одновременно 2 программистам” - это неэффективно именно из-за периодически происходящих переключений. Вообще, эффективности (по крайней мере на раннем этапе) будет очень сильно зависеть от того, что у программиста происходит помимо работы. У меня на фоне дикой скорости изменения жизни за последний год сейчас, когда страсти немного поутихли + меняю работу, эффективность упала в несколько раз. За последнюю неделю вообще противно от того, что почти ничего не сделал - при том, что прекрасно знаю способы решения задач.

    • У меня на фоне дикой скорости изменения жизни за последний год сейчас, когда страсти немного поутихли + меняю работу, эффективность упала в несколько раз. За последнюю неделю вообще противно от того, что почти ничего не сделал - при том, что прекрасно знаю способы решения задач.

      Это как раз и есть пример переключения между режимами. Нет людей, которые всегда работают одинаково - бывают и долговременные спады.
      Зато потом, когда всё устаканится - вот тут ты выдашь 200% производительности :)

  • не из опыта Игорь а из его неудачь_)

Ответить

 

 

 

Вы можете использовать эти HTML тэги

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>