Я смотрю на коммиты на github, у меня примерно 400 в год, а у парней с микрософта и других активных разработчиков более 4000. Говорили, что эффективные программисты в 10 раз круче обычных. Что делать-то? Как свою эффективность поднять? (понятно, что можно разбивать работу на микрошаги и просто увеличить колличество коммитов, но они-то так не делают?)
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я смотрю на коммиты на github, у меня примерно 400 в год, а у парней с микрософта и других активных разработчиков более 4000. Говорили, что эффективные программисты в 10 раз круче обычных. Что делать-то? Как свою эффективность поднять? (понятно, что можно разбивать работу на микрошаги и просто увеличить колличество коммитов, но они-то так не делают?)
Комить не раз в день, а каждое исправление, каждую фичу, каждое обособленное изменение исходников.
Их 4К комитов — это не безудержная работа, а просто высокая гранулярность комитов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD> Их 4К комитов — это ... просто высокая гранулярность комитов.
Откуда такая уверенность?
Посмотрел твой профиль на Github — сначала у тебя было 100 коммитов в год, потом этот показатель вырос под полторы тысячи, что вполне наглядно отражает рост опыта.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Посмотрел твой профиль на Github — сначала у тебя было 100 коммитов в год, потом этот показатель вырос под полторы тысячи, что вполне наглядно отражает рост опыта.
Уважаемый у меня этого опыта уже 20 лет. И за год он уже давно не растет в разы (если вообще растет). А количество коммитов определяется исключительно тем как я комитил и над чем работал.
Я часто вожусь с одной проблемой несколько дней. Ранее я тупо не комитил эту работу. Потом, пообщавшись с другими программистами, и просто осознав необходимость отдельного документирования отдельных действий начал коммитить более гранулярно. Но все же я просто иногда забываю закомитить какие-то изменения или начинаю делать 2-3 дела одновременно. Понимаю, что это плохо, но безалаберность, присущая исследовательским натурам вроде меня, не дает делать как следует.
Ну, и у меня много задач/работ. Не все они связаны с программированием. И не все они комитятся.
Еще надо учитывать тот фактор, что какое-то время я работал в команде или просто помогал кому-то. Все это время, естественно, комитов от меня было меньше. Зато увеличивалось число комитов у других участников проектов.
В общем, поверь на слово. Ничего лично во мне не поменялось.
ЗЫ
Кстати, как посмотреть на этот показатель?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я смотрю на коммиты на github, у меня примерно 400 в год, а у парней с микрософта и других активных разработчиков более 4000. Говорили, что эффективные программисты в 10 раз круче обычных. Что делать-то? Как свою эффективность поднять?
Перестать менять свою производительность количеством коммитов
Здравствуйте, alpha21264, Вы писали:
ЭФ>>Я смотрю на коммиты на github, у меня примерно 400 в год, а у парней с микрософта и других активных разработчиков более 4000. Говорили, что эффективные программисты в 10 раз круче обычных. Что делать-то? Как свою эффективность поднять?
A>Перестать менять свою производительность количеством коммитов
А какие есть еще показатели производительности?
Я вот тоже раньше думал, что количество коммитов, или там число строк кода — лажа.
Однако когда глядя на историю, я все же изменил свое мнение. IMHO, достаточно вменяемые показатели.
То есть, оценивать объем работ и производительность по ним можно, но к сожалению с задержкой в месяцы-годы.
Здравствуйте, bnk, Вы писали:
bnk>alpha21264, Вы писали:
A>>Перестать менять свою производительность количеством коммитов
bnk>А какие есть еще показатели производительности?
bnk>Я вот тоже раньше думал, что количество коммитов, или там число строк кода — лажа. bnk>Однако когда глядя на историю, я все же изменил свое мнение. IMHO, достаточно вменяемые показатели. bnk>То есть, оценивать объем работ и производительность по ним можно, но к сожалению с задержкой в месяцы-годы.
Ты из советского поколения или из постсоветского? В зависимости от этого я буду по-разному объяснять.
Во-первых, показатели — то когда ты естественным интеллектом не можешь оценить некую ситуацию.
В идеальном случае лучше всё-таки развивать интеллект, а не придумывать показатели.
Показатели врут. А ещё больше врут люди, которые подкручивают показатели.
Во-вторых, если уж очень хочется придумывать показатели, то они должны показывать не объёмы кода, а его полезность.
Вот например я работал в одной западной конторе, которая... ну в общем, работает на Интел.
Наша программа разводила печатные платы (в основном интеловские материнки).
Так у нас было два показателя:
1) Сколько ошибок остаётся на плате после работы программы. (Время было гораздо менее важным критерием)
2) Сколько пожеланий пользователя (Тикетов) осталось незакрытыми.
А уж как это выражается в коде, да чёрт его знает.
Идеальная программа должна быть написана в течении вечера, быть абсолютно надёжной и работать вечно.
Здравствуйте, alpha21264, Вы писали:
A>Ты из советского поколения или из постсоветского? В зависимости от этого я буду по-разному объяснять.
Ну пионером я полгода побыть успел. Жалко вот что галстук не сохранился. Так что не совсем уверен — советское или уже пост-советское
A>Во-первых, показатели — то когда ты естественным интеллектом не можешь оценить некую ситуацию. A>В идеальном случае лучше всё-таки развивать интеллект, а не придумывать показатели. A>Показатели врут. А ещё больше врут люди, которые подкручивают показатели.
A>Во-вторых, если уж очень хочется придумывать показатели, то они должны показывать не объёмы кода, а его полезность. A>Вот например я работал в одной западной конторе, которая... ну в общем, работает на Интел. A>Наша программа разводила печатные платы (в основном интеловские материнки). A>Так у нас было два показателя: A>1) Сколько ошибок остаётся на плате после работы программы. (Время было гораздо менее важным критерием) A>2) Сколько пожеланий пользователя (Тикетов) осталось незакрытыми. A>А уж как это выражается в коде, да чёрт его знает.
A>Идеальная программа должна быть написана в течении вечера, быть абсолютно надёжной и работать вечно.
Это да. Но показатели производительности/объема, которые я имел в виду, в основном же для чего нужны — для прогнозирования, не?
То есть, чтобы оценить, сколько займет / во что обойдется та или иная работа / проект, в данных условиях, с данными людьми.
Это как фундаментальные законы — не отвечают на вопрос "зачем", зато отвечают на вопрос "как".
Например, как оценить, сколько времени займет разработка CMS, зная что в команде 5 индусов из Мумбая?
Можно по аналогии с предыдущими проектами. Как сравнить проекты? По объему коду-числу коммитов. Также производительность людей.
Я в этом ключе о полезности показателей говорил.
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, alpha21264, Вы писали:
A>>Ты из советского поколения или из постсоветского? В зависимости от этого я буду по-разному объяснять.
bnk>Ну пионером я полгода побыть успел. Жалко вот что галстук не сохранился. Так что не совсем уверен — советское или уже пост-советское
Это пост-советское. Ничего плохого в этом нет, просто эффективность ты будешь понимать так, как это американцы понимают.
Советские понимали по-другому.
A>>1) Сколько ошибок остаётся на плате после работы программы. (Время было гораздо менее важным критерием) A>>2) Сколько пожеланий пользователя (Тикетов) осталось незакрытыми. A>>А уж как это выражается в коде, да чёрт его знает.
A>>Идеальная программа должна быть написана в течении вечера, быть абсолютно надёжной и работать вечно.
bnk>Это да. Но показатели производительности/объема, которые я имел в виду, в основном же для чего нужны — для прогнозирования, не? bnk>То есть, чтобы оценить, сколько займет / во что обойдется та или иная работа / проект, в данных условиях, с данными людьми. bnk>Это как фундаментальные законы — не отвечают на вопрос "зачем", зато отвечают на вопрос "как".
Ну да. Только в программировании все эти метрики врут. Не попадают даже в порядок.
Об этом написано во всех книжках по менеджменту, начиная с самой первой "Мифический человеко-месяц".
В реальной жизни все оценки просто берутся по худшему и умножаются в десять раз.
Вообще, если в программу нужно вносить тысячи изменений, значит с программой что-то не так.
bnk>Например, как оценить, сколько времени займет разработка CMS, зная что в команде 5 индусов из Мумбая? bnk>Можно по аналогии с предыдущими проектами. Как сравнить проекты? По объему коду-числу коммитов. Также производительность людей. bnk>Я в этом ключе о полезности показателей говорил.
Всего пять индусов, или в команде ещё кто-то есть?
В очередной книжке "Peopleware" написано, что если их из проекта исключить, то проект пойдёт быстрее.
Дело в том, что все эти "распределённые команды" нужны не для повышения эффективности.
Как раз эффективность труда современный капитализм спустил в унитаз. Это делается для "управляемости".
Управляемость — это чтобы индусы не вздумали сами продавать свой продукт.
Именно для этого делаются команды, которые размазаны по всему миру,
в которых разработчики принадлежат разным культурам и говорят на разных языках.
Расплачиваются эффективностью. Я это уже говорил.
Вообще, рекомендую познакомиться с ТРИЗ (Теория Решения Изобретательских Задач).
Сначала это научит тебя правильно ставить вопросы. А потом... ууу!!! Потом будет ментальный взрыв.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я смотрю на коммиты на github, у меня примерно 400 в год, а у парней с микрософта и других активных разработчиков более 4000. Говорили, что эффективные программисты в 10 раз круче обычных. Что делать-то? Как свою эффективность поднять? (понятно, что можно разбивать работу на микрошаги и просто увеличить колличество коммитов, но они-то так не делают?)
4000 коммитов в год — это в среднем 15 коммитов в день. Т.е., это либо отдельный коммит на каждые измененные несколько строчек, либо чувак принимает патчи от команды из десятка программистов, просматривает их, и коммитит под своим аккаунтом.
Здравствуйте, VladD2, Вы писали:
VD>Я часто вожусь с одной проблемой несколько дней. Ранее я тупо не комитил эту работу. Потом, пообщавшись с другими программистами, и просто осознав необходимость отдельного документирования отдельных действий начал коммитить более гранулярно. Но все же я просто иногда забываю закомитить какие-то изменения или начинаю делать 2-3 дела одновременно. Понимаю, что это плохо, но безалаберность, присущая исследовательским натурам вроде меня, не дает делать как следует.
Я иногда в таких случаях накопившееся за несколько дней провожу несколькими, логически независимыми коммитами. Т.е., со стороны это выглядит так: сначало несколько дней ничего, а потом несколько коммитов подряд, с интервалами в 10-15 минут.
Здравствуйте, bnk, Вы писали:
bnk>Это да. Но показатели производительности/объема, которые я имел в виду, в основном же для чего нужны — для прогнозирования, не? bnk>То есть, чтобы оценить, сколько займет / во что обойдется та или иная работа / проект, в данных условиях, с данными людьми. bnk>Это как фундаментальные законы — не отвечают на вопрос "зачем", зато отвечают на вопрос "как".
Можно у людей спросить, сколько времени у них займет проект. Это работает. Только обычно надо их оценку умножать на некоторый коэффициент, и для конкретного человека или группы людей надо нащупать этот коэффициент эмперически.
Здравствуйте, bnk, Вы писали:
bnk> ЭФ>>Я смотрю на коммиты на github, у меня примерно 400 в год, а у парней с микрософта и других активных разработчиков более 4000. Говорили, что эффективные программисты в 10 раз круче обычных. Что делать-то? Как свою эффективность поднять? bnk> A>Перестать менять свою производительность количеством коммитов bnk> А какие есть еще показатели производительности?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я смотрю на коммиты на github, у меня примерно 400 в год, а у парней с микрософта и других активных разработчиков более 4000. Говорили, что эффективные программисты в 10 раз круче обычных. Что делать-то? Как свою эффективность поднять? (понятно, что можно разбивать работу на микрошаги и просто увеличить колличество коммитов, но они-то так не делают?)
Думаю, тебе надо начать коммитить каждую строчку, сразу всех обгонишь по эффективности.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, VladD2, Вы писали:
VD>Уважаемый у меня этого опыта уже 20 лет. И за год он уже давно не растет в разы (если вообще растет). А количество коммитов определяется исключительно тем как я комитил и над чем работал.
VD>Я часто вожусь с одной проблемой несколько дней. Ранее я тупо не комитил эту работу. Потом, пообщавшись с другими программистами, и просто осознав необходимость отдельного документирования отдельных действий начал коммитить более гранулярно.
Подскажите плиз годный материал по теме. Какой должна быть стратегия, чтобы частые комиты не мешали, а помогали?
ЭФ>а у парней с микрософта
Им сторонние разработчики часто присылают патчи, которые они коммитят под своими аккаунтами.
Кроме того, у парней из корпораций могут быть всякие нелепые KPI вида "Количество изменений в системе за год"
Здравствуйте, IQuerist, Вы писали:
IQ>Подскажите плиз годный материал по теме. Какой должна быть стратегия, чтобы частые комиты не мешали, а помогали?
Да стратегия очень простая. Комитить надо некое минимальное, но осмысленное изменение. Например, исправил ты баг — комить. Реализовал мелкую фичу — комить. И надо стараться не смешивать коммиты от разных фич. Например, если ты решил переформатировать код, то лучше делать это не в процессе реализации фичи или исправления бага, а отдельным комитом. Решил сделать рефакторинг — опять таки комить его отдельно от изменений меняющих функциональность.
Ну, и комитить стоит сначала локально, а потом уже стопку комитов слать на сервер.
Если выполняется большая работа, стоит завести для нее ветку.
Кроме того мы стараемся использовать ребэйз, тчобы не было много параллельных веток. Это не всегда прокатывает, но если прокатывает — это лучший выбор. Потом проще разбираться с историей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
