Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 76
Может быть дело в том, что опыт и стаж — не одно и тоже?
Увы, для большинства одно и то же.
Когда-то эта простая притча заставила меня многое пересмотреть в своей жизни:
Однажды пожилой человек начал учить Учителя Ио жизни.
— Почему я должен поступать так, как ты мне говоришь? — спросил Ио.
— Потому что я тебя старше! — вскричал пожилой человек.
Тогда Учитель Ио сказал:
— Насыщает не время, проведенное в столовой, а количество съеденных беляшей.
Однажды пожилой человек начал учить Учителя Ио жизни.
— Почему я должен поступать так, как ты мне говоришь? — спросил Ио.
— Потому что я тебя старше! — вскричал пожилой человек.
Тогда Учитель Ио сказал:
— Насыщает не время, проведенное в столовой, а количество съеденных беляшей.
Вообще-то, в индивидуальной работе, эффективность прежде всего зависит от личных качеств, а потом уже от опыта.
Так в любой профессии. Токари, сварщики, столяры и прочие профессии точно так же различаются.
Опыт просто снижает количество ошибок на этапе проектирования, когда идет выбор варианта решения. А дальше работают уже личные качества человека.
Так в любой профессии. Токари, сварщики, столяры и прочие профессии точно так же различаются.
Опыт просто снижает количество ошибок на этапе проектирования, когда идет выбор варианта решения. А дальше работают уже личные качества человека.
На самом деле это можно отнести не только к программистам. Например умение водить (особенно парковать, особенно задним ходом, особенно по зеркалам) и стаж вождения мало связаны. И таких умений можно насобирать over 9000.
Относительно программистов из своих наблюдений соглашусь с тем, что чаще всего эти люди не признают и не терпят критики в свой адрес и адрес своих творений.
Относительно программистов из своих наблюдений соглашусь с тем, что чаще всего эти люди не признают и не терпят критики в свой адрес и адрес своих творений.
Важно не только отсутствие корреляции между опытом и продуктивностью, но и огромная разница для людей с одинаковым уровнем опыта. Среди профессиональных водителей примерно одного стажа вряд ли встретишь отличия в разы.
Стаж не показатель. Один 5 лет сидит в бюджетной организации и ковыряет в носу, второй 5 лет работает в команде профессионалов и делает серьезный продукт. Стаж у них будет один и тот же, а опыт работы разный. В статье эти понятия также подменены и под опытом работы подразумевают стаж.
А как тогда формализовать опыт? А то какая то эфимерная величина.
Не знаю. Если речь о собеседовании, то можно поговорить с соискателем о том, чем он занимался и понять, насколько он «опытен». Для целей подобного исследования, наверно, никак.
Да никак его не формализуешь. Это же не сантиметры, его линейкой не измеришь.
Никто не знает. Но то, что опыт неизвестно как формализовать не дает нам возможности приравнивать его к стажу, увы.
Смотреть на достижения за эти 7 лет. 7 лет джумлу настраивать, да визитки клепать и 7 лет в хайлоад-проектах, разный опыт
По поводу исследований. Правильно ли я понимаю, что единственное современное исследование упомянуто в книге двенадцатилетней давности, являющейся учебников по коммерческой системе оценки сроков разработки софта, «Software Cost Estimation with Cocomo II»? До этого 89-й год, тогда все-таки разработка была совсем другая.
Конечно нет. Можете и сами погуглить. Представлены исследования, имеющие высокий индекс цитирования в других работах.
Эх, если бы я умел гуглить исследования о продуктивности программистов… :(. К сожалению, я их не то что погуглить не могу — я даже не могу представить как такое исследование провести. «Programmer Performance and the Effects of the Workplace.», которое я внимательно прочитал, не имеет никакого отношения к продуктивности разработчиков. Там сравнивались синтетические характеристики в синтетических задачах.
Поскажите, какие на ваш взгляд хорошие исследования этого вопроса в последние лет 5-6 проводились?
Поскажите, какие на ваш взгляд хорошие исследования этого вопроса в последние лет 5-6 проводились?
Из недавнего:
Capers Jones. Scoring and Evaluating Software Methods, Prectices and Results. 2010. у него еще много исследований интересных, увы не помню где качал
И вот это: sequoia.cs.byu.edu/lab/files/pubs/Delorey2007a.pdf
Capers Jones. Scoring and Evaluating Software Methods, Prectices and Results. 2010. у него еще много исследований интересных, увы не помню где качал
И вот это: sequoia.cs.byu.edu/lab/files/pubs/Delorey2007a.pdf
Внимательно изучил эту работу. Что они доказывали: «programmer productivity is constant in terms of lines of code per year regardless of the programming language being used». То есть — «вне звисимости от языка программирования, разработчик пишет примерно одинаковое количество строк кода в год». Какое это имеет отношение к продуктивности разработчиков и упомянутых в посте исследованих о разнице между лучшими и худшими в 20 раз?
Если уволить всех плохих программистов, то хорошие будут не «относительно недорогими» а «ужоснах, какими дорогими».
А касательно икс-фактора, мне кажется, кому-то «больше всех надо», он читает чужой код, книжки, думает над тем, что пишет и т.п. А кому-то — лишь бы отделаться.
А касательно икс-фактора, мне кажется, кому-то «больше всех надо», он читает чужой код, книжки, думает над тем, что пишет и т.п. А кому-то — лишь бы отделаться.
Вы сами пишите в конце поста:
Так что же по вашему, опыт (НЕ стаж) и знание готовых решений никак не коррелируют? Я бы с Вами тут не согласился…
… большая часть кода уже написана, на первый план выходит не продуктивность программиста, а умение находить и комбинировать готовые решения, а также умение придумать нестандартное решение...
Так что же по вашему, опыт (НЕ стаж) и знание готовых решений никак не коррелируют? Я бы с Вами тут не согласился…
А вы прочитайте фразу ровно до того куска, который вы процитировали. Это ведь вопрос эффективности. В малых командах продуктивность (писать код правильно) не так важна, как эффективность (писать нужный код).
В исследовании, на которое вы ссылаетесь, эффективность рассматривается с двух ракурсов:
1. Производственная эффективность, которая связана со скоростью кодирования и скоростью дебага. Для достижения такого рода эффективности используются высокоуровневые языки программирования.
2. Экономическая эффективность, которая характеризуется размером программы (не кода!), скоростью ее исполнения и потреблением ресурсов. Для достижения такого рода эффективности задействуют более низкоуровневые инструменты и — внимание — опыт!
(страница 17, последние 2 абзаца)
P.S. Из этого, кстати, следует, что заголовок статьи противоречит тому, что прямо утверждается в исследовании: эффективность зависит от опыта.
1. Производственная эффективность, которая связана со скоростью кодирования и скоростью дебага. Для достижения такого рода эффективности используются высокоуровневые языки программирования.
2. Экономическая эффективность, которая характеризуется размером программы (не кода!), скоростью ее исполнения и потреблением ресурсов. Для достижения такого рода эффективности задействуют более низкоуровневые инструменты и — внимание — опыт!
(страница 17, последние 2 абзаца)
P.S. Из этого, кстати, следует, что заголовок статьи противоречит тому, что прямо утверждается в исследовании: эффективность зависит от опыта.
Ещё интересна зависимость от сложности задачи. Есть ведь, условного говоря, ядро/движок, которое занимает 10-20% кода, и есть рутинная работа, вроде создания интерфейсов по готовым макетам. Кто-то ведь должен делать и простую, но необходимую работу, и мне кажется, что в таких задачах разрыв в производительности будет куда меньше.
Что будет если уволить всех «неэффективных программистов», можно было увидеть на последних зимних олимпиадах и чемпионатах мира по хоккею, где наша сборная состояла сплошь из «звёзд», в результате чего никто не хотел выполнять чёрную работу.
Что будет если уволить всех «неэффективных программистов», можно было увидеть на последних зимних олимпиадах и чемпионатах мира по хоккею, где наша сборная состояла сплошь из «звёзд», в результате чего никто не хотел выполнять чёрную работу.
соотношение лучших и худших программистов составило
20:1 по времени написания кода
Что это означает? Что лучший программист из изученных написал программу за время Х, а худший — за время 20Х?
Или что количество тех, кто уложился в некий норматив T по времени составило Х человек, а количество тех, кто не уложился — 20Х? Или наоборот?
Если первое, то эти показатели (20:1) не описывают характер связи, они описывают однородность — и только в том случае, если соотношение будет подкреплено распределением. Во втором случае всё сильно зависит от Т (хотя тоже не показывает характер связи).
Собственно, главный вопрос: как из этого соотношения был получен вывод о силе связи между стажем и продуктивностью?
Что лучший программист из изученных написал программу за время Х, а худший — за время 20Х?
Именно так.
Открыл исследование, почитал. Начнем с того, что
Не соответствует написанному в документе (см. таблицу 3 на странице 16). Должно быть так:
Согласно задаче Maze:
26:1 по времени написания кода
25:1 по времени отладки кода
13:1 по скорости работы программы
5:1 по объему кода
Но это мелочи. Возможно, каким-то образом было сведено к среднему между двумя задачами, на которых было сделано исследование.
Далее следует, на мой взгляд, более правильная интерпретация этих результатов. Делаются выводы:
1. Если программист хороший, то он очень-очень хороший. Если программист плохой, то он просто ужасный.
2. Соотношение, как правило, обусловлено работой наиболее сильных программистов (кого там увольнять собирались? 90% «плохих» что ли?)
3. Действительно плохие программисты высасывают ресурсы как пылесос
и множество других интересных.
Вывод, сделанный в статье, настораживает. Возьмем 100 кроликов. Соотношение яркости цвета самого тёмного к самому светлому составляет 75:1. В той или иной вариации вы уже видели эти цифры. Но мало кто знал, что всем кроликам было 2 года. Отсюда делаем вывод, что нет сильной связи между цветом кролика и его возрастом. WTF??
20:1 по времени написания кода
25:1 по времени отладки кода
10:1 по скорости работы программы
5:1 по объему кода
Не соответствует написанному в документе (см. таблицу 3 на странице 16). Должно быть так:
Согласно задаче Maze:
26:1 по времени написания кода
25:1 по времени отладки кода
13:1 по скорости работы программы
5:1 по объему кода
Но это мелочи. Возможно, каким-то образом было сведено к среднему между двумя задачами, на которых было сделано исследование.
Далее следует, на мой взгляд, более правильная интерпретация этих результатов. Делаются выводы:
1. Если программист хороший, то он очень-очень хороший. Если программист плохой, то он просто ужасный.
2. Соотношение, как правило, обусловлено работой наиболее сильных программистов (кого там увольнять собирались? 90% «плохих» что ли?)
3. Действительно плохие программисты высасывают ресурсы как пылесос
и множество других интересных.
Вывод, сделанный в статье, настораживает. Возьмем 100 кроликов. Соотношение яркости цвета самого тёмного к самому светлому составляет 75:1. В той или иной вариации вы уже видели эти цифры. Но мало кто знал, что всем кроликам было 2 года. Отсюда делаем вывод, что нет сильной связи между цветом кролика и его возрастом. WTF??
Собственно, главный вопрос: как из этого соотношения был получен вывод о силе связи между стажем и продуктивностью?
Ни в одном исследовании не было выявлено связи опыта (стажа) и продуктивности.
Понятно что есть минимальный уровень опыта, с которым это выполняется, и для конкретной задачи требуется минимальный уровень понимания технической и предметной области.
Сделаю предположение, почему не было выявлено: потому что не выявлялось. Изучались совсем другие вещи.
Если 30 лет не выявлено, то видимо связи то и нет. Если бы было одно исследование, то был бы один разговор. А исследований несколько, причем очень даже адекватных, и все равно не выявлено.
Возможно, это так. Но в этом случае приведите ссылки на эти исследования, тогда и будет разговор по существу. Я комментирую только то, что написано вами в вашем блоге. А написанное в нем противоречит единственному исследованию, на которое он ссылается.
И ещё, следует различать два разных утверждения:
1. Связи выявлено не было.
2. Выявлено, что связи нет.
Второе из первого не следует. Одна из возможных причин первого озвучена комментарием выше: никто не ставил задачей выявлять такую связь. Также возможная причина — нет подходящей методики выявления связи (см. ниже про чистоту эксперимента).
1. Связи выявлено не было.
2. Выявлено, что связи нет.
Второе из первого не следует. Одна из возможных причин первого озвучена комментарием выше: никто не ставил задачей выявлять такую связь. Также возможная причина — нет подходящей методики выявления связи (см. ниже про чистоту эксперимента).
Исследование на связь двух переменных A (стаж) и B (эффективность) делается так: берется одна переменная (А), и изменяется в некоторых пределах (от 1 до 10 лет, скажем). При этом наблюдается изменение другой переменной (В). Чем меньше влияние других переменных (пол, национальность, проект, менеджер, время суток, самочувствие, политическая обстановка, погода, душевное состояние), тем чище эксперимент. Если при большом изменении А изменение B тоже большое, а при малом изменении А изменение В тоже малое, то связь сильная. Во всех других случаях она слабая.
В описанном же выше эксперименте переменная А зафиксирована на отметке 7, смотрится разброс переменной В и из этого делается вывод, что В от А не зависит. Это неправильно. Контрпример:
Стаж = 1 год: время выполнения задачи от 1000 до 20000 минут. Соотношение 1:20.
Стаж = 2 года: время выполнения задачи от 800 до 16000 минут. Соотношение 1:20.
Стаж = 3 года: время выполнения задачи от 500 до 10000 минут. Соотношение 1:20
Стаж = 4 года: время выполнения задачи от 300 до 6000 минут. Соотношение 1:20
Говорите, не зависит эффективность от стажа? ;)
Но скорее всего будут такие данные:
Стаж = 1 год: время выполнения задачи от 1000 до 20000 минут. Соотношение 1:20.
Стаж = 2 года: время выполнения задачи от 800 до 14000 минут. Соотношение 1:18.
Стаж = 3 года: время выполнения задачи от 500 до 5000 минут. Соотношение 1:10
Стаж = 4 года: время выполнения задачи от 300 до 1500 минут. Соотношение 1:5
Из которых мы сможем сделать два вывода:
1. Эффективность зависит от стажа. Чем больше стаж, тем меньше среднее арифметическое между худшим и лучшим результатом (бред, конечно, но другого вывода не сделать из этих данных, нужно знать распределение для более адекватных выводов).
2. Разброс зависит от стажа. Чем больше стаж, тем меньше разброс.
В описанном же выше эксперименте переменная А зафиксирована на отметке 7, смотрится разброс переменной В и из этого делается вывод, что В от А не зависит. Это неправильно. Контрпример:
Стаж = 1 год: время выполнения задачи от 1000 до 20000 минут. Соотношение 1:20.
Стаж = 2 года: время выполнения задачи от 800 до 16000 минут. Соотношение 1:20.
Стаж = 3 года: время выполнения задачи от 500 до 10000 минут. Соотношение 1:20
Стаж = 4 года: время выполнения задачи от 300 до 6000 минут. Соотношение 1:20
Говорите, не зависит эффективность от стажа? ;)
Но скорее всего будут такие данные:
Стаж = 1 год: время выполнения задачи от 1000 до 20000 минут. Соотношение 1:20.
Стаж = 2 года: время выполнения задачи от 800 до 14000 минут. Соотношение 1:18.
Стаж = 3 года: время выполнения задачи от 500 до 5000 минут. Соотношение 1:10
Стаж = 4 года: время выполнения задачи от 300 до 1500 минут. Соотношение 1:5
Из которых мы сможем сделать два вывода:
1. Эффективность зависит от стажа. Чем больше стаж, тем меньше среднее арифметическое между худшим и лучшим результатом (бред, конечно, но другого вывода не сделать из этих данных, нужно знать распределение для более адекватных выводов).
2. Разброс зависит от стажа. Чем больше стаж, тем меньше разброс.
За что я люблю математику (-ов), так за наглядность в примерах. Полностью с Вами согласен. Добавить можно только то, что «время выполнения задачи» ограничено снизу. Т.е. ускорение эффективности (снижение времени решения задачи в единицу времени стажа) будет с годами падать, пока не упрется в нижний предел.
Было бы хорошо, если бы такое всегда выполнялось. Но в моей практике слишком много контрпримеров.
Идея уволить всех плохих и оставить только хороших похожа на идею уместить весь код, нужный человечеству, в 20,000 строк
Слишком утопично.
Ладно, допустим вы действительно верите, что горстка профессионалов способна обеспечить потребности всей отрасли.
Дело за малым: научиться объективно измерять эффективность программистов. Насколько мне известно, этого пока не умеет делать никто.
О, да, можно сортировать кандидатов в лабораторных условиях по времени, затраченным ими на реализацию, скажем, переворота строки.
И мы получим рейтинг внутри конкретной группы программистов на основании конкретной задачи (максимум — класса задач) решенной в конкретное время.
В реальной жизни задачи весьма разнообразны. Кроме того, присутствует человеческий фактор. Не верю, что все программисты, эффективно перевернувшие строки на собеседовании, также эффективно справятся с любыми другими классами задач в любое время.
Слишком утопично.
Ладно, допустим вы действительно верите, что горстка профессионалов способна обеспечить потребности всей отрасли.
Дело за малым: научиться объективно измерять эффективность программистов. Насколько мне известно, этого пока не умеет делать никто.
О, да, можно сортировать кандидатов в лабораторных условиях по времени, затраченным ими на реализацию, скажем, переворота строки.
И мы получим рейтинг внутри конкретной группы программистов на основании конкретной задачи (максимум — класса задач) решенной в конкретное время.
В реальной жизни задачи весьма разнообразны. Кроме того, присутствует человеческий фактор. Не верю, что все программисты, эффективно перевернувшие строки на собеседовании, также эффективно справятся с любыми другими классами задач в любое время.
Только вот все забывают, что 80% разработки любого проекта — рутина, и должны быть обычные, не звездные программисты, которые эту рутину будут разгребать огромными навозными лопатами. Медленно, неторопливо, изо дня в день. Что вполне выгодно для бизнеса — не каждый день нужны смелые решения и нестандартные подходы.
Если человек сидит на одной работе над одним проектом то он не будет развиваться (какой нибудь внутренний софт).
Если человек получил удачный опыт и постоянно его везде использует то он не будет развиваться (некоторые гуру которые «знают» как правильно делать).
Про производительность могу сказать только одно, проекты разного размера требуют разные подходы. Если проект больший, то «быстрота» выполнения задачи не нужна (иногда запрещена), требуется следовать некоторым принципам и методологиям. Если же проект маленький, то требуется именно методичная реализация небольшого функционала. Отсюда все проблемы в том числе и холивар по поводу оверинженеринга.
Если человек получил удачный опыт и постоянно его везде использует то он не будет развиваться (некоторые гуру которые «знают» как правильно делать).
Про производительность могу сказать только одно, проекты разного размера требуют разные подходы. Если проект больший, то «быстрота» выполнения задачи не нужна (иногда запрещена), требуется следовать некоторым принципам и методологиям. Если же проект маленький, то требуется именно методичная реализация небольшого функционала. Отсюда все проблемы в том числе и холивар по поводу оверинженеринга.
Последнее, но не менее важное — надо сильно пересмотреть методику найма программистов. Вместо отсева по ключевым словам в резюме и задач на логику, надо кандидатам писать код, желательно в “лабораторных” условиях, чтобы можно было отследить продуктивность и качество.
Перестаньте оценивать: время написания кода, время отладки кода, скорость работы программы, объем кода и т.д.
Попробуйте научиться оценивать творческие способности ЧЕЛОВЕКА!
Интересно, а что больше всего смущает минусующих: утверждение что программист — творец, или что он — человек, а не робот с «механическими» характеристиками?
Лично мне всегда достаточно было достаточно убедится, что кандидат мне «приятен» в общении и он практически знает и умеет настраивать свои инструменты. Творческий потенциал выясняется уже в процессе работы, т.к. другие методы оценки по моему мнению не очень эффективны.
Лично мне всегда достаточно было достаточно убедится, что кандидат мне «приятен» в общении и он практически знает и умеет настраивать свои инструменты. Творческий потенциал выясняется уже в процессе работы, т.к. другие методы оценки по моему мнению не очень эффективны.
Маленькая семейная байка, адаптированная под контекст данной статьи.
В далеком 1978 году мой папа и моя мама работали программистами в одном НИИ. Папа работал в лаборатории на четвертом этаже, а мама в лаборатории на втором этаже пятиэтажного здания. Машинный зал был на пятом. Для получения результатов работы программы необходимо было поднять стопку перфокарт в машинный зал, дождаться очереди, загрузить перфокарты в компьютер и дождаться результата. Папа был сильнее мамы в два раза (мог унести за раз больше перфокарт), в два раза быстрее ходил по зданию, и путь его до машинного зала был в три раза короче. Таким образом, он был эффективнее мамы в 12 раз. Еще, как начальник лаборатории, он мог существенно сократить свое время ожидания в очереди к компьютеру. В результате, он писал код в 20 раз быстрее и 20 раз быстрее его отлаживал.
Я это все к тому, что на результатах исследований 1968 года (а в реалиях нашей страны и 1981-1989 годов) не могут базироваться выводы 2014 года, особенно в такой сфере, как IT.
В далеком 1978 году мой папа и моя мама работали программистами в одном НИИ. Папа работал в лаборатории на четвертом этаже, а мама в лаборатории на втором этаже пятиэтажного здания. Машинный зал был на пятом. Для получения результатов работы программы необходимо было поднять стопку перфокарт в машинный зал, дождаться очереди, загрузить перфокарты в компьютер и дождаться результата. Папа был сильнее мамы в два раза (мог унести за раз больше перфокарт), в два раза быстрее ходил по зданию, и путь его до машинного зала был в три раза короче. Таким образом, он был эффективнее мамы в 12 раз. Еще, как начальник лаборатории, он мог существенно сократить свое время ожидания в очереди к компьютеру. В результате, он писал код в 20 раз быстрее и 20 раз быстрее его отлаживал.
Я это все к тому, что на результатах исследований 1968 года (а в реалиях нашей страны и 1981-1989 годов) не могут базироваться выводы 2014 года, особенно в такой сфере, как IT.
Можно ли в контексте данного исследования утверждать, что два одинаковых по оценке программиста напишут по-разному оценённый рабочий код, если один его будет писать в блокноте, а второй в очень крутой IDE?
Папа был сильнее мамы в два раза (мог унести за раз больше перфокарт)Это наводит на мысль о том, что продуктивность многих тогдашних программистов (и особенно программисток) можно было увеличить в два раза (а не то и существенно больше, чем в два раза — особенно для сложных задач), выдав им для индивидуального пользования колёсные тележки, предназначенные для перевозки перфоркарт (вместо перетаскивания их в руках).
К счастью, в настоящее время эта мысль перестала быть актуальною в отрасли.
Тележка не решает проблему лестниц. У моей мамы (по семейной легенде) был специальный чемоданчик для этих целей. И она его таскала по зданию института с 1977 по 1979 год. И лайфхаки, позволяющие увеличивать продуктивность, были, просто в памяти моей не отложились. Помню только из детства, как родители эти лайфхаки с коллегами обсуждали в процессе кухонных посиделок.
Вообще, в байке почти все правда (кроме оценок эффективности программиста и этажности здания)
Вообще, в байке почти все правда (кроме оценок эффективности программиста и этажности здания)
Серьезно, учитывая факты выше, можно набрать небольшую команду относительно недорогих, но высоко продуктивных, программистов. И это будет в разы выгоднее чем держать штат опытных специалистов.
Дело осталось за малым, а именно набрать «небольшую команду относительно недорогих, но высоко продуктивных, программистов». Я так и не понял, почему вдруг они станут «относительно недорогими», если рынок и так ощущает нехватку специалистов (причем и условно «плохих»). Я понимаю ход мысли (они будут работать продуктивнее), но это утопия — их просто загонят на рутинных задачах и никакого развития уже не будет.
Поверхностные какие-то выводы делает автор.
На разных этапах разработки будут востребованы разные качества.
В самом начале проекта актуальны люди со стратегическим видением проекта, на этапе активной фазы разработки — люди со способностью быстро писать код, в конце проекта и на этапе поддержки продукта — другие качества возьмут вверх: умение быстро разбираться в чужих наработках, усидчивость.
На разных этапах разработки будут востребованы разные качества.
В самом начале проекта актуальны люди со стратегическим видением проекта, на этапе активной фазы разработки — люди со способностью быстро писать код, в конце проекта и на этапе поддержки продукта — другие качества возьмут вверх: умение быстро разбираться в чужих наработках, усидчивость.
5:1 по объему кодаИндусы-прогеры точно расколбасят этот фактор оценки, независимо от качества своего кода.
Нанимать надо опытных программистов, потому что они уже знают готовые решения для 90% случаев и хороших, потому что они могут быстро дописать недостающие 10%… да и еще недорогих… ваш КО
Если Capers Jones прав, на больших проектах «суперпрограммисты» приближаются по эффективности к «середнякам». Поэтому, команда из одних «звёзд» не будет в 20 раз эффективнее «обычных» команд.
Выдержка из книги «The art of designing embedded_systems» (на английском):
Выдержка из книги «The art of designing embedded_systems» (на английском):
Скрытый текст
Мне кажется, продуктивность сотрудника сильно коррелирует с оплатой труда, как с наиболее весомым мотиватором. Ведь с одной стороны есть работодатель — хочет заплатить как можно меньше и как можно быстрее и качественнее получить продукт. С другой стороны есть работник — хочет заработать как можно больше за как можно меньшие затраты (времени, нервов).
Чем лучше взаимосвязь работодателя и работника, тем лучше они находят соотношение спроса и предложения. А когда соотношение найдено, то оба довольны. Например, программист может зарабатывать больше чем в среднем по организации (на уровне менеджмента среднего звена), но быть не довольным и халтурить. Причина? А он директора в глаза не знает. Есть некий договор, он его подписал, отправил в канцелярию и с тех пор его карьерный рост это сплошная неопределённость. Может быть выкинут, а может быть и не выкинут. И вот уже проект подходит к концу, продукт продаётся, а новых перспектив или планов на горизонте не видно. Тоже самое с инициативой. Можешь пропыхтеть над какой-нибудь плюшкой, до которой никто не додумался, а тебе в ответ пожмут руку и скажут: «Большое тебе человеческое спасибо» (которое, как известно, карман не жмёт).
Другое дело когда организация (от лица директора) сразу же ставит программиста в известность: что ей от него нужно, каких работ и в какие сроки. С поощрениями. Соответственно, за совершенно конкретный барыш, программист готов будет несколько ночей RTFM-эмить технологии любой сложности. Для этого как раз и существуют курсы повышения квалификации. Оно может компании и нафиг не нужно, чтобы у программиста была стена увешана сертификатами. Но зато он будет знать за что ему готовы повысить оклад.
Так что продуктивность зависит от тимлида и его способности построить диалог между маленьким человеком в компании (джуниором) с высшим звеном руководства. Мне интуиция подсказывает, что самые неэффективные (во всех смыслах) программисты встречаются в средних и крупных фирмах, где нет такого диалога. В крохотных фирмочках все и так друг друга знают и может быть даже работают в одном кабинете, и там таких проблем нет.
Чем лучше взаимосвязь работодателя и работника, тем лучше они находят соотношение спроса и предложения. А когда соотношение найдено, то оба довольны. Например, программист может зарабатывать больше чем в среднем по организации (на уровне менеджмента среднего звена), но быть не довольным и халтурить. Причина? А он директора в глаза не знает. Есть некий договор, он его подписал, отправил в канцелярию и с тех пор его карьерный рост это сплошная неопределённость. Может быть выкинут, а может быть и не выкинут. И вот уже проект подходит к концу, продукт продаётся, а новых перспектив или планов на горизонте не видно. Тоже самое с инициативой. Можешь пропыхтеть над какой-нибудь плюшкой, до которой никто не додумался, а тебе в ответ пожмут руку и скажут: «Большое тебе человеческое спасибо» (которое, как известно, карман не жмёт).
Другое дело когда организация (от лица директора) сразу же ставит программиста в известность: что ей от него нужно, каких работ и в какие сроки. С поощрениями. Соответственно, за совершенно конкретный барыш, программист готов будет несколько ночей RTFM-эмить технологии любой сложности. Для этого как раз и существуют курсы повышения квалификации. Оно может компании и нафиг не нужно, чтобы у программиста была стена увешана сертификатами. Но зато он будет знать за что ему готовы повысить оклад.
Так что продуктивность зависит от тимлида и его способности построить диалог между маленьким человеком в компании (джуниором) с высшим звеном руководства. Мне интуиция подсказывает, что самые неэффективные (во всех смыслах) программисты встречаются в средних и крупных фирмах, где нет такого диалога. В крохотных фирмочках все и так друг друга знают и может быть даже работают в одном кабинете, и там таких проблем нет.
По моему продуктивность как раз мало связана с величиной зарплаты, ибо оплата и прочие материальные стимулы лишь удерживает человека на текущем рабочем месте а вовсе не стимулирует его лучше работать. Вот вам простой пример: если зарплату увеличить в 2 раза-будет человек в 2 раза лучше работать? Если не в 2 то на сколько? на 10%?
На протяжении всего текста меня не покидало ощущение, что это какой-то изощрённый троллинг, что автор сознательно принижает, даже игнорирует важность творческого мышления, кругозора, адаптации. Как будто он из другой культуры. И точно, автор — индус.
Главное преимущество опытных программистов не в том, что они умеют быстрее писать и отлаживать больше кода, который использует меньше памяти и процессорного времени.
Главное преимущество опытных программистов в том, что они пишут меньше кода на выброс.
Главное преимущество опытных программистов в том, что они пишут меньше кода на выброс.
идиотский вопрос — как померить свою собственную эффективность?
1. Придумать себе цель, выраженную числом. Это будет число G.
2. В процессе достижения записывать затраты всех ресурсов, относительно которых вы хотите изменить эффективность. Например, часы (в итоге получим эффективность по времени). Это будет число T.
3. Когда цель будет достигнута, поделить G на T. Получим число Е. Это будет ваша эффективность.
Что с ней делать? Распечатать и гордиться.
Что еще можно с ней делать:
1. Ещё раз достичь цель G, замерить новое число T2. Поделить G на T2 и получить эффективность E2. Сравнивая E и E2, впасть в депрессию, либо сказать себе, что жизнь удалась.
2. Помериться числом E с другими, если методика определения эффективности одинаковая.
2. В процессе достижения записывать затраты всех ресурсов, относительно которых вы хотите изменить эффективность. Например, часы (в итоге получим эффективность по времени). Это будет число T.
3. Когда цель будет достигнута, поделить G на T. Получим число Е. Это будет ваша эффективность.
Что с ней делать? Распечатать и гордиться.
Что еще можно с ней делать:
1. Ещё раз достичь цель G, замерить новое число T2. Поделить G на T2 и получить эффективность E2. Сравнивая E и E2, впасть в депрессию, либо сказать себе, что жизнь удалась.
2. Помериться числом E с другими, если методика определения эффективности одинаковая.
Помнится было исследование в США по поводу учёных. На продуктивность. В США умеют считать деньги, выделяемые на науку.
И вот оказалось, что лишь 1-3% учёных выдают «результат».
Было решено отказаться от формирование больших команд и собирать только «продуктивных».
За год такого решения «эффективность» упала в N раз (не помню уже).
Как оказалась масса (97-99%) т.н. «непродуктивных» каким-то образом всё-таки влияет на результат.
Ссылку уже не смогу найти.
И вот оказалось, что лишь 1-3% учёных выдают «результат».
Было решено отказаться от формирование больших команд и собирать только «продуктивных».
За год такого решения «эффективность» упала в N раз (не помню уже).
Как оказалась масса (97-99%) т.н. «непродуктивных» каким-то образом всё-таки влияет на результат.
Ссылку уже не смогу найти.
Мысль очень правильная, т.к. творческое озарение даже у талантливых людей — явление не частое.
Предположим в государстве есть только 100 ученых — 90% обычные, 10% талантливые.
За год только у одного из 10 талантливых и у двух из 90 обычных было озарение и они нашли решения изучаемых проблем — выдали результат.
Т.е. примерно каждый 10-й талантливый и каждый 45-й обычный ученый.
Это все только мои предположения т.к. точные цифры будут зависеть от критерия определения «талантливый или обычный».
В любом случае логика такая — количество талантливых ограниченно и если оставить только 10 талантливых потеряем 2% результата обычных.
Хотя возможно, что содержать 10 талантливых и получать их 1% результата (который в этом случае превращается уже в 10%) кому-то покажется выгоднее.
Но это смотря о каком результате идет речь, например если нужно придумывать новое оружие, то любой здравомыслящий глава государства не станет отказываться ни от какой части результата и будет продолжать финансировать всех 100 ученых.
Эту же логику (государство + ученые) можно перенести на (компанию + программисты)!
Предположим в государстве есть только 100 ученых — 90% обычные, 10% талантливые.
За год только у одного из 10 талантливых и у двух из 90 обычных было озарение и они нашли решения изучаемых проблем — выдали результат.
Т.е. примерно каждый 10-й талантливый и каждый 45-й обычный ученый.
Это все только мои предположения т.к. точные цифры будут зависеть от критерия определения «талантливый или обычный».
В любом случае логика такая — количество талантливых ограниченно и если оставить только 10 талантливых потеряем 2% результата обычных.
Хотя возможно, что содержать 10 талантливых и получать их 1% результата (который в этом случае превращается уже в 10%) кому-то покажется выгоднее.
Но это смотря о каком результате идет речь, например если нужно придумывать новое оружие, то любой здравомыслящий глава государства не станет отказываться ни от какой части результата и будет продолжать финансировать всех 100 ученых.
Эту же логику (государство + ученые) можно перенести на (компанию + программисты)!
deleted
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опыт работы не имеет значения