Спасибо, вы меня рассмешили. Мне нравится, насколько дружелюбным всегда оказывается русскоязычное сообщество!
Я отвечаю на комментарии, потому что никогда раньше не имел возможности обсудить это с русскоязычным сообществом, и для меня это что-то новое. Мне интересно, есть ли кто-то с совершенно иным образом мышления, чем тот, к которому я привык в Кремниевой долине. Такие комментарии, хоть и забавные, не производят сильного впечатления.
Вы ошибаетесь, я не пытаюсь что-то кому-то продать. Мне нравится рассказывать о своей работе, и мне также нравится, когда меня ставят перед вызовами – это расширяет мой кругозор.
Индивидуальные инженеры не понимают, что моя модель значительно лучше того мусора, который используется в большинстве случаев. Не знаю, как в России, но в США все пользуются глупыми метриками вроде подсчёта коммитов, DORA (исследование Microsoft/Google, которое вырвали из контекста и исказили) и так далее.
Моя цель – сделать разработку ПО более меритократичной, прозрачной и ориентированной на ответственность. Меньше тумана, интриг и политики)
Я автор этого исследования. Соглашусь с вами, что эти расчёты выглядят немного кликбейтно. Но я упоминаю, что это чисто гипотетический сценарий – у меня нет эмпирических данных о производительности инженеров в этих компаниях (а если бы были, я бы не мог об этом сказать).
Надеюсь, вы понимаете, что для привлечения большего числа участников в исследование иногда приходится использовать кликбейт. Основные результаты исследования абсолютно надёжны, но некоторые расчёты "на салфетке" выглядят довольно громкими. Виноват :-)
Я автор исследования, спасибо за добрые слова. Но такие комплименты лучше делать после того, как вы прочитали нашу работу.
Глючный код не должен попадать в продакшн. Если это происходит, значит, у вас проблемы с QA или другими частями CI/CD пайплайна. А если всё-таки попал, то, скорее всего, его придётся дорабатывать, что замедлит процесс, потому что придётся возвращаться и исправлять. Кроме того, мы также отслеживаем случаи, когда код "перерабатывается", и можем видеть, какое количество ваших коммитов – это новый код, а какое – переработка старого.
С уважением: проще всего бросаться словами, но гораздо лучше делать это, когда вы тщательно изучили работу автора.
Я автор этого исследования. Отвечу, скопировав комментарий, который я уже оставлял на похожее замечание:
По моему опыту, такие примеры звучат убедительно в риторике, но часто не подкреплены доказательствами. Мы годами анализировали эти вещи. Случаи, когда инженер тратит "недели на исправление критической ошибки", действительно бывают, но основная часть работы инженера обычно не про это. А если в команде есть инженер, который занимается "поиском сложных багов, которые никто больше не может найти", об этом, как правило, все знают.
Модель не идеальна, и я это признаю. Более того, я всегда открыт к критике – это помогает мне шире взглянуть на вещи.
Я автор этого исследования. Мы считаем, что наша модель учитывает это, потому что если баги влияют на множество зависимостей, то модель это распознает. Признаю, существует риск, что модель может этого не учесть. В худшем случае? Около 5 из ваших ~48 продуктивных недель в году могут быть неточными. Зато остальные 43 недели будут довольно точными.
Возможно. Более элегантное экономическое объяснение этого можно найти в исследовательской статье "Рынок лимонов".
"Рынок лимонов" -- это экономическая концепция, описанная Джорджем Акерлофом. Она иллюстрирует ситуацию, когда продавцы и покупатели имеют неравный доступ к информации о качестве товара. Продавцы знают больше о товаре (например, об автомобиле), чем покупатели. Это приводит к снижению доверия на рынке и тому, что на рынке остаются преимущественно товары низкого качества ("лимоны"), так как высококачественные товары теряют спрос.
По моему опыту, такие примеры звучат убедительно в риторике, но часто не подкреплены доказательствами. Мы годами анализировали эти вещи. Случаи, когда инженер тратит "недели на исправление критической ошибки", действительно бывают, но основная часть работы инженера обычно не про это. А если в команде есть инженер, который занимается "поиском сложных багов, которые никто больше не может найти", об этом, как правило, все знают.
//Я написал всё это на английском и перевёл через ChatGPT, так что надеюсь, получилось понятно. Я не привык говорить о таких вещах на русском!//
Под "влиянием" я не имею в виду влияние на бизнес. Мне нравится разделять два понятия: выход и результаты.
Представьте, что результаты зависят от списка приоритетных функций, составленного продуктовой командой, или от решений инженера, принимающего продуктовые решения. Выход, с другой стороны, – это осязаемая работа, которую выполняет инженер, независимо от её ценности для бизнеса.
Если инженер выдаёт много качественного результата, но его влияние на бизнес невелико – это не проблема инженера.
Как видно из этой матрицы, у вас может быть высокоэффективная инженерная команда, работающая над продуктом, который не приносит дохода. Такое часто бывает. Также можно встретить малоэффективную инженерную команду, работающую над продуктом, который, несмотря на их низкую производительность, приносит огромные деньги.
В своём исследовании мы концентрируемся именно на выходе. Это не про подсчёт строк кода. Мы рассматриваем более 40 измерений, включая когезию, сложность, связность, классы, методы, уровни хранения данных, API-интерфейсы, архитектурные паттерны и многое другое. Объяснить, как всё это работает, непросто. (Не говоря уже о том, что как человечество мы до сих пор не до конца понимаем, что происходит "под капотом" моделей машинного обучения).
Я автор этого исследования. Мы пропускаем код из каждого коммита через модель, которая оценивает его с точки зрения влияния на кодовую базу. Результаты этой модели имеют высокую корреляцию с оценками независимой группы экспертов, анализирующих код, что является наиболее точным приближением к измерению продуктивности в области программной инженерии.
Всем привет! Я автор этого исследования -- Егор Денисов-Бланч (Yegor Denisov-Blanch). Наполовину русский. Буду рад пообщаться подробнее, если кто-то хочет взять интервью для своих подписчиков. Пишите в личку!
Спасибо, вы меня рассмешили. Мне нравится, насколько дружелюбным всегда оказывается русскоязычное сообщество!
Я отвечаю на комментарии, потому что никогда раньше не имел возможности обсудить это с русскоязычным сообществом, и для меня это что-то новое. Мне интересно, есть ли кто-то с совершенно иным образом мышления, чем тот, к которому я привык в Кремниевой долине. Такие комментарии, хоть и забавные, не производят сильного впечатления.
Вы ошибаетесь, я не пытаюсь что-то кому-то продать. Мне нравится рассказывать о своей работе, и мне также нравится, когда меня ставят перед вызовами – это расширяет мой кругозор.
Мне кажется невероятно интересным, как люди умудряются неправильно понимать методологию исследования.
Индивидуальные инженеры не понимают, что моя модель значительно лучше того мусора, который используется в большинстве случаев. Не знаю, как в России, но в США все пользуются глупыми метриками вроде подсчёта коммитов, DORA (исследование Microsoft/Google, которое вырвали из контекста и исказили) и так далее.
Моя цель – сделать разработку ПО более меритократичной, прозрачной и ориентированной на ответственность. Меньше тумана, интриг и политики)
Я автор этого исследования. Соглашусь с вами, что эти расчёты выглядят немного кликбейтно. Но я упоминаю, что это чисто гипотетический сценарий – у меня нет эмпирических данных о производительности инженеров в этих компаниях (а если бы были, я бы не мог об этом сказать).
Надеюсь, вы понимаете, что для привлечения большего числа участников в исследование иногда приходится использовать кликбейт. Основные результаты исследования абсолютно надёжны, но некоторые расчёты "на салфетке" выглядят довольно громкими. Виноват :-)
Я бы посоветовал вам ознакомиться с нашей работой – тогда вы поймёте, насколько слабы ваши аргументы.
Я автор исследования, спасибо за добрые слова. Но такие комплименты лучше делать после того, как вы прочитали нашу работу.
Глючный код не должен попадать в продакшн. Если это происходит, значит, у вас проблемы с QA или другими частями CI/CD пайплайна. А если всё-таки попал, то, скорее всего, его придётся дорабатывать, что замедлит процесс, потому что придётся возвращаться и исправлять. Кроме того, мы также отслеживаем случаи, когда код "перерабатывается", и можем видеть, какое количество ваших коммитов – это новый код, а какое – переработка старого.
С уважением: проще всего бросаться словами, но гораздо лучше делать это, когда вы тщательно изучили работу автора.
Кстати, классные картинки.
Я автор этого исследования. Отвечу, скопировав комментарий, который я уже оставлял на похожее замечание:
По моему опыту, такие примеры звучат убедительно в риторике, но часто не подкреплены доказательствами. Мы годами анализировали эти вещи. Случаи, когда инженер тратит "недели на исправление критической ошибки", действительно бывают, но основная часть работы инженера обычно не про это. А если в команде есть инженер, который занимается "поиском сложных багов, которые никто больше не может найти", об этом, как правило, все знают.
Модель не идеальна, и я это признаю. Более того, я всегда открыт к критике – это помогает мне шире взглянуть на вещи.
Я автор этого исследования. Мы считаем, что наша модель учитывает это, потому что если баги влияют на множество зависимостей, то модель это распознает. Признаю, существует риск, что модель может этого не учесть. В худшем случае? Около 5 из ваших ~48 продуктивных недель в году могут быть неточными. Зато остальные 43 недели будут довольно точными.
Возможно. Более элегантное экономическое объяснение этого можно найти в исследовательской статье "Рынок лимонов".
"Рынок лимонов" -- это экономическая концепция, описанная Джорджем Акерлофом. Она иллюстрирует ситуацию, когда продавцы и покупатели имеют неравный доступ к информации о качестве товара. Продавцы знают больше о товаре (например, об автомобиле), чем покупатели. Это приводит к снижению доверия на рынке и тому, что на рынке остаются преимущественно товары низкого качества ("лимоны"), так как высококачественные товары теряют спрос.
По моему опыту, такие примеры звучат убедительно в риторике, но часто не подкреплены доказательствами. Мы годами анализировали эти вещи. Случаи, когда инженер тратит "недели на исправление критической ошибки", действительно бывают, но основная часть работы инженера обычно не про это. А если в команде есть инженер, который занимается "поиском сложных багов, которые никто больше не может найти", об этом, как правило, все знают.
//Я написал всё это на английском и перевёл через ChatGPT, так что надеюсь, получилось понятно. Я не привык говорить о таких вещах на русском!//
Под "влиянием" я не имею в виду влияние на бизнес. Мне нравится разделять два понятия: выход и результаты.
Представьте, что результаты зависят от списка приоритетных функций, составленного продуктовой командой, или от решений инженера, принимающего продуктовые решения. Выход, с другой стороны, – это осязаемая работа, которую выполняет инженер, независимо от её ценности для бизнеса.
Если инженер выдаёт много качественного результата, но его влияние на бизнес невелико – это не проблема инженера.
Как видно из этой матрицы, у вас может быть высокоэффективная инженерная команда, работающая над продуктом, который не приносит дохода. Такое часто бывает. Также можно встретить малоэффективную инженерную команду, работающую над продуктом, который, несмотря на их низкую производительность, приносит огромные деньги.
В своём исследовании мы концентрируемся именно на выходе. Это не про подсчёт строк кода. Мы рассматриваем более 40 измерений, включая когезию, сложность, связность, классы, методы, уровни хранения данных, API-интерфейсы, архитектурные паттерны и многое другое. Объяснить, как всё это работает, непросто. (Не говоря уже о том, что как человечество мы до сих пор не до конца понимаем, что происходит "под капотом" моделей машинного обучения).
Я автор этого исследования. Спасибо за добрые слова!
Я автор этого исследования. Мы пропускаем код из каждого коммита через модель, которая оценивает его с точки зрения влияния на кодовую базу. Результаты этой модели имеют высокую корреляцию с оценками независимой группы экспертов, анализирующих код, что является наиболее точным приближением к измерению продуктивности в области программной инженерии.
Всем привет! Я автор этого исследования -- Егор Денисов-Бланч (Yegor Denisov-Blanch). Наполовину русский. Буду рад пообщаться подробнее, если кто-то хочет взять интервью для своих подписчиков. Пишите в личку!