Я долго размышлял на данную тему и наконец решил изложить.
Вся эта история с оценкой кода по количеству написанных строк или другие попытки оценить объем работы мне всегда не давали покоя.
Сейчас я не пишу код в промышленных масштабах, разве что для себя какой-то мелкий инструмент. Но когда-то я писал много и занимался этим больше 15 лет.
Придешь утром в офис и начинаешь что-то писать, сохраняясь в промежутках, конечно же. А вечером мне нравилось иногда нажать ctrl+z и смотреть в ускоренном темпе, пусть и в обратном порядке, как бегал курсор, как выделялись, появлялись и исчезали какие-то блоки кода. Сначала условие и цикл появились в одном месте, потом кусок кода из цикла перешел в процедуру, цикл вообще исчез и т.д. Это завораживающий танец курсора и текста под ним.
К концу дня новая лаконичная процедура, пара вставок в существующие блоки. В общей сложности 50-80 строк кода. Часто приходилось дорабатывать легаси, где нужно аккуратно внедрить свои вставки в разных местах, ничего не сломав.
И я задавал себе вопрос: а кто видел все эти мои поиски и скитания? Для внешнего наблюдателя видно только сколько строк было утром и сколько их стало вечером. Но это вообще не то. Эти 80 строк даже не намекают на то, чем я занимался целый день. Уверен, вы понимаете, о чем речь.
Сейчас, в эпоху тотальной увлеченности ИИ, меня не покидает мысль, что неплохо бы весь этот когнитивный процесс легализовать.
Здесь не будет инструкций как я это сделал. Здесь будет просто рассуждение вокруг да около.
Телеметрия
На сайтах давно применяются механизмы отслеживания поведения пользователя. Куда он нажал, сколько был на странице, насколько глубоко скролил и т.д.
Почему в разработке такого нет? Переходы между модулями, наведение курсора на какие-то методы для просмотра подсказок, переход по зависимостям, поиск и прочее. Набрать текст, выделить, удалить, переместить, подключить библиотеку, поправить конфиг, запустить.
Внесение изменений, компиляция, тестовый запуск, повторное изменение с последующей компиляцией. Пошаговая отладка с заходом. Это же масса времени и когнитивной работы.
Или отладка SQL запроса. Вы же знаете, как это бывает, когда можно неделю отлаживать тяжелый запрос. Смотреть планы, замерять I/O-статистику, добавлять индексы. Выдергивать куски вложенных запросов и отлаживать их отдельно, а затем вставлять в общий запрос. Кто это видит? Никто. Только вы.
В конце недели ваш комит выглядит как 3 короткие, но идеальные правки в запросе. Чем ты занимался всю неделю? Добавил эти три строки? Иногда самому становится не по себе от осознания того, как результат твоей работы выглядит для стороннего наблюдателя.
Все привыкли оценивать результат, но в разработке, как и в науке, 90% времени — это постановка эксперимента и поиск ошибки. Инструменты оценки за это не заточены. Они заточены на результат, будто вы копаете яму отсюда и до обеда.
Никто не оценит все ваши страдания, пробы и ошибки, но именно в них рождается результат.
А вот если бы телеметрия собирала все ваши действия в лог, а потом построить на этом граф или этот ваш ИИ бы оценил, насколько это непросто. Для бизнеса ваша работа стала бы прозрачной и доказуемой.
Парадокс мастерства
Есть байка про Пикассо, когда его попросили нарисовать на салфетке набросок. Он сделал это за пару минут. А на вопрос, сколько ему за это должны, назвал огромную сумму. Это возмутило заказчика, ведь как можно требовать такую сумму всего 2 минуты. На что художник ответил, что потратил на это не 2 минуты, а всю жизнь.
Разве эта байка не перекликается с разработчиками, которые тратят массу времени на невидимую работу, а затем пытаются доказать заказчику, что это не просто 2 строчки кода?
А что, если попробовать?
Можно собрать тысячи честных логов процесса разработки и процесса имитации, а затем обучить на этом модель, чтобы выделить паттерны. Такие сырые логи, конечно же, не годятся для обучения модели, но из них можно построить тепловую карту и/или граф активности. На графе будет видно "пульс" процесса. Кто-то делает это быстрее, а кто-то медленнее, но процесс будет примерно одинаковый. Ваша работа станет доказуемой. Разумеется, собирать нужно всё — не только IDE, но и окружение.
Это должна быть внешняя утилита, которая просто ведет лог работы. В настройках пользователь сам задает что именно собирать и из каких приложений. Фильтры заголовков с регулярками, типы объектов и вот это вот все. Тогда будет видно, что вы после отладчика перешли в какой-то SQL редактор (SSMS/PLSQL) или postman, долго его мучили, а оттуда на stackoverflow и крутили там десятки страниц.
В итоге получится инкрементальная запись действий с учетом контекста, а не дельта результата. Не для слежки, а для анализа того, как именно мы (люди) это делаем, ведь это самое интересное.
Законная лень или как мы на самом деле ищем решения
Всем известно, что человек не может писать код с 9 до 18, особенно, если требуется поиск решения, а не просто набор текста стандартных алгоритмов. Бывает, что мысль не идет. Можно сколько угодно себя заставлять писать — толку не будет. Либо такого понапишешь, что потом не разобрать. Решение крутится где-то на языке. Вы чувствуете, что оно есть и оно достаточно простое, но ясная картинка не складывается. Вы уже перепробовали десятки вариантов, а каменный цветок не выходит. Нужно отвлечься — почитать анекдоты/новости, посмотреть котиков, чтобы произошла дефрагментация мысли. Это инкубация, которая может длиться от нескольких часов до нескольких дней. В какой-то момент происходит вспышка — решение сложилось. Вы открываете свой код, смотрите, что вы там понаписали, и думаете: боже, что это?! Удалить! И пишете за 5 минут сразу работающий блок, который раньше не взлетал несколько дней. И это чувство неловкости перед самим собой: я потратил столько времени, а если спросят, то и показать как бы нечего. Это когнитивный диссонанс. Мы привыкли измерять объемами. Если это что-то стоящее, то его должно быть много, не так ли?
Как объяснить бизнесу, почему вы одну из двух недель потратили на видосики?
Такой период, как инкубация-инсайт, будет виден на тепловой карте, потому что ему предшествовал процесс интенсивного перебора вариантов, когда вы переписывали один и тот же кусок еще и еще, затем пауза в IDE, котики в браузере и короткое финальное решение.
Может возникнуть вопрос приватности. Но ведь человек сам может выбирать, что логировать, а что нет, и это в его интересах, а главное — логи не обязательно должны содержать тексты, они могут содержать только маркеры, на основе которых можно строить тепловые карты. Здесь не имеет значения, что именно написано и какого качества это было на этапе поиска решения, намного важнее число попыток и количество вариантов, ибо именно сюда и ушло все время.
Эффективные менеджеры могут попытаться использовать это против вас. Ведь Петя продолжал жрать кактус и таки выдал какое-то чудовище, в то время, как Вася пошел смотреть котиков и вернулся с тремя строчками идеального кода. Но здесь как раз и нужна статистика по таким картам и беспристрастность ИИ. Подобно тому, как нейросеть анализирует снимки флюорограммы, когда даже опытный специалист не видит там ничего особенного, а нейронка видит маркеры.
Почему этого до сих пор нет? Ну ладно, если кто-то недобросовестный занимается очковтирательством, но большинство ведь честно выполняют свою работу и любят ее. Когда вы увлечены, вы не замечаете, как летит время. Целый день честно чем-то занимался, никаких котиков. Но вот уже коллеги начали собираться домой. Смотришь на часы, там 18:00. А где результат? Самому не понятно, куда ушло время. Такие тепловые карты вам самим помогут понять, где были моменты максимального напряжения и какой реальный интеллектуальный вклад был сделан, несмотря на то, что пощупать нечего.
Приведу простую аналогию.
Школьная задача по математике, где нужно найти площадь поля, например.
Формулировка задачи: дано А,Б,В, какая площадь поля?
Можно ответить коротко: 1км2
Однако учитель требует показать решение, как ты получил этот ответ. Он хочет видеть формулу. Но даже эта формула слишком поверхностный уровень. Интереснее узнать ещё более глубокий срез, который покажет цепь логических рассуждений, приведших к решению. Где будет видно, почему именно эта формула или теорема были применены и что этой теореме предшествовало. Добыта она была в памяти, как готовый рецепт, или ты до этого дошел. Пример с математикой здесь близок, когда нужно вывести формулу, но формула это уже результат, а сам процесс остался за кадром. В школе нас учат именно процессу (способу) нахождения решения, а формулы — лишь инструменты.
В школе рассказывают как применять теорему Пифагора. Начинают гонять десятки задач, чтобы человек с разных сторон приходил к одной и той же теореме. Когда материал усвоен, начинается новая тема. Но в школе учат готовому процессу, который за сотни лет уже превратился в методичку.
А на работе человек часто вынужден выстраивать свой процесс самостоятельно. Да, на основе школьного, но самостоятельно.
У кого-то он более эффективный, а у кого-то менее и, скорее всего, разница в способности и скорости решения тех или иных задач на работе заключается в разных процессах, которые люди выстроили в своей голове. Вероятно, тепловая карта позволит понять, в чем разница в этом смысле между Петей и Васей. Почему Вася решает типовые задачи быстрее, чем Петя, но при этом Петя способен на решение нетривиальных задач, а Вася на них буксует.
Возможно, этим тепловым картам найдется применение и в науке, а может быть они могут стать заменой тестов на собесах (вместо решения задачек и IQ можно показать "паспорт" способа своего мышления, ведь именно за этим, а не за знанием алгоритмов, все охотятся в найме)...
Что скажете?
Комментарии (33)
d3d12
04.03.2026 14:10Умиляет такой стиль кода:
вместо:if (a == b) c = d; else c = e;писать:
if (a == b) { c = d; } else { c = e; }Мастер-класс по KPI.
parakhod_1
04.03.2026 14:10c = a == b ? d : e;
Вообще форматтеры у всех давным-давно живут. И запускаются либо в pre-commit hook, либо вообще по любому изменению в файле.
Так что как не пиши отформатирует одинаково.
d3d12
04.03.2026 14:10c = a == b ? d : eЭто уж слишком хардкорно.
ЛЛМ учились на таком КПИ-стиле и норовят писать так же. Пока им не сунешь codestyle.md. Хотя последний Opus 4.6 уже видя стиль проекта, пишет в таком же стиле.parakhod_1
04.03.2026 14:10Я сам так всегда пишу. Во-первых короче, а во-вторых функционально и immutable, тут c - константа, а у вас она переприсваивается.
shornikov
04.03.2026 14:10А потом добавится еще действий, и все равно разворачивать.
Мне ваш вариант не нравится: это он в однобуквенных переменных читается, а в длинных - либо уйдет за экран, либо сам перенесется. Не лучше тогда и скобочки добавить для будущих поколений.
И Diff наглядней будет.d3d12
04.03.2026 14:10Ели добавится. А если не добавится - то не разворачивать.
А мне не нравится, когда ради 10 смысловых строк кода, над скроллить 3 экрана. Особенно, если это функционально и логически обособленный блок - лучше бы он целиком охватывался взглядом, без скролла.
ris58h
04.03.2026 14:10Я как-то по запарке после такого if ещё строчку вставил и потом долго тупил со странных результатов. После этого предпочитаю всегда фигурные скобки ставить, а для компактности тернарный оператор есть.
В Гугл, похоже, об этом тоже что-то знают
https://google.github.io/styleguide/javaguide.html#s4.1-braces
Braces are used with
if,else,for,doandwhilestatements, even when the body is empty or contains only a single statement.
WantedPotato
04.03.2026 14:10func some(a,b,d,e int) int { if a == b { return d } return e } func main() { ... c := some(1,2,3,4) }
vitalist84
04.03.2026 14:10Есть мнение, что платить нужно именно за количество строк кода.
Что толку от того что вы поправили 2 строчки кода? Через месяц причину уже не вспомнить, придет другой человек и уберет их, чтобы поправить очередной баг, и тоже потратит на удаление целую неделю. Кроме этих 2-х строчек должны были родиться тесты на 100 строчек кода. И вот за эти 102 строчки и нужно начислять зарплату.
Руководители и старшие разработчики не в счет. Их сложно померить. Можно предложить считать строчки кода подчиненных с некоторым коэффициентом.
sic
04.03.2026 14:10Давайте не будем придумывать, какими способами можно еще греть планету через инференс. Всегда же можно рендерить котиков!
А по сути, эта статья как будто из года 2005. Ностальгия есть, к этим замечательным временам "неделя мучения, и вот они заветные три строки". Но сейчас нет. Если это багфикс, то хоть и сам фикс может занимать даже одну строку, или один символ, как артефакты работы нужны еще тесты, которые не проходятся старым кодом, и скорее всего, очевидно, небольшое изменение архитектуры, чтобы эти тесты подключить к проблемному коду (и если "не повезет" очень как дофига придется замокать). Если это архитектурное изменение, то хорошо, редко, но возможно, что все изменение в API это три строки. Но это еще пачка вики-док с описанием как мигрировать, чем лучше новое решение, как минимум. И опять же тесты. Ну а фичи на три строчки маловероятны. Тут наоборот, в каком-нибудь легаси, кажется что фича на три строки, а в реальности пришлось перелопатить полтысячи.
А в 2005 да, бывало такое, что эти три строки достались сутками ковыряния бинарей в дизассемблере и отладчике. Но обычно это когда что-то сделать "нельзя, не надо, но очень хочется". Но сейчас такие практики, мб, только у вирусописателей и остались.
Не верю я в три строчки, не верю.
rt001 Автор
04.03.2026 14:10Конечно 3 строчки это багфикс/оптимизация или доработка. Разве где-то речь шла о том, что это новая фича?
О каком 2005 и дизассемблере вы говорите? Я вам приведу десятки примеров, как в современных архитектурах не могли починить месяцами плавающий баг авторизации из-за куков. Выделяли каждый спринт несколько часов. Каждый новый решатель говорил, что предыдущий балбес, а я вот точно знаю где искать. Но обломали зубы. Баг так и живет.
sic
04.03.2026 14:10О том 2005, где в небольшой компании живет жесткий водопад, репозиторий cvs (это хорошо, если так) и файлики. Там же в этих файликах выкидывались какие-то progress_module1.txt, какие-то сборочные артефакты, какие-то тестовые бинари и у кого как. Тогда да, работа это то, что попадает в репозиторий, а остальное раз в месяц сносил админ (на самом деле эникей, которого пнули, что место на шаре мол кончается). В тех же файликах еще нередко валялись фотки с новогоднего корпоратива, ppt презентации для заказчиков, какие-то небольшие игрухи. Замечательные были врема, спору нет...
И если Вы продолжаете в них жить, да при текущем уровне зарплат, то ничуть не сострадаю вашей проблеме, скорее просто завидую.
Но какие багфиксы на три строчки в этом мире? Говорите, плавающая проблема? Так первое с чего начинают, строят образ проблемной конфигурации (даже в самом унылом случае, это виртуалка с специально сконфигурированной средой, которая попадает потом в бинарные артефакты), а чаще это отдельный бранч, где плавающий баг специально доталкивается до повторяющегося отдельным кодом. И это еще до непосредственно исследования бага и его исправления. Потом отладка, и исправление. Да даже если непосредственно обход проблемы занимает три строчки, нужно всегда смотреть на окружение этого кода, постараться рефакторить то, что этот баг скрывало. Ну и в конце концов тесты. Чтобы вот четенько было видно, что до фикса тест был красненьким (да-да, этого не обязательно можно добиться юнит-тестами, и тогда проблемные конфиги надо включать уже в интеграционные тесты, в общем тут еще больше вариантов), но вот эти тесты точно никак нигде и никогда не будут тремя строчками.
С моим опытом скажу, что любые PR в три строчки без других артефактов (обозначено выше) можно сначала отклонить, а потом уже изучить. Потому что это не будут фиксы, в 98% это просто костыли. В 1%, ой-бой, это исправление
безобидногонедосмотра уволившегося коллеги. Еще 1% остается на то, что это валидный кейс.А дальше все просто, если у сотрудника эти 1% превращаются в хотя бы 20% его работы, то вывод даже без теоремы Байеса понятен, он халтурит.
Про оптимизации еще смешнее. Вот тут хочу любой пример. Да, в три строчки где-то можно поменять под задачу коллекцию вроде дерева, на хэш-мапу. Или убрать лишний запрос к БД, потому что в соседнем поле эти данные и так болтаются. Но остаются два вопроса, как в эти три строчки уместить еще и доказательство того, что оптимизация полезна в принципе (то есть как "у себя локально потестил", вроде в 2 раза быстрее, а вам зачем знать, что и как я тестил), и что там можно две недели оптимизировать, когда профайлеры всего и везде есть.
Все когда-то халтурили, все иногда выгорали, изредка можно встретить реально противную проблемку, но что бы три строчки кода за две недели без других артефактов было хоть чем-то похожим на норму говорить смешно. А если это превращается в 6 строчек за месяц, то грустно, и пора с человеком прощаться.
rt001 Автор
04.03.2026 14:10Я не очень понимаю вектор этого разговора. Зачем вы навешиваете на меня ярлыки, которых нет. "2005 год, водопад..." Это не моя проблема. Я не пишу код уже давно (о чем говорил в самом начале), хотя по-прежнему очень близок к разработке. И как бы если посмотреть с этой позиции, можно сказать, что мне все равно, как там ПМ оценивают свои сторипоинты. Я лишь поделился размышлениями и не более.
Если суть статьи вам не понравилась и вы не увидели в нем рационального зерна, ок.
Может вам не понравился заголовок статьи и вы хотите сказать, что он неправдоподобен? Это просто заголовок. В статье несколько другой посыл.
построить образ проблемной конфигурации
А разве чтобы его построить, не нужно вникнуть в проблему и изучить хотя бы условия, при которых это воспроизводится. Разве это не интеллектуальная деятельность?
Все это окружение, виртуалки, эксперименты, о которых вы говорите, разве будут как-то отражены в финальном комите? Но вы их делали. Вы тратили время на гипотезы и их проверки.
Там будет только фикс по делу. Артефакты могут остаться, если кто-то требует их в качестве доказательств, но это не всегда и не везде так. Если у вас этот процесс налажен - прекрасно. Но я видел массу примеров в весьма крупных финтехах, когда разраб пофиксил багу и никаких тестов не появилось, а ручник даже не удосужился сделать несколько скринов о том, что он это протестил. Вы скажете, что это проблема команды и процессов. Нужно повесить техлида и разогнать сеньора QA. Возможно. Но идеального мира не существует. Косяков полно везде.Потом отладка, и исправление
Вот в этом и кроется вся соль задумки. Отладка это не нажатие одной кнопки. Весь процесс этой отладки никто не видит. Не видно количества усилий, которые были на это затрачены. Видно только результат фикса, новые тесты, что-то еще. Это все готовый результаты. Они не появились по щелчку пальцев. Вы работали, думали, искали нестыковки. Это интеллектуальная деятельность, объем которой не виден в комите и в скринах. Этого артефакта просто нет, потому что нет системы, которая могла бы его зафиксировать. Не видно путь, который вы прошли, чтобы получить результат.
Вы говорите про высокий уровень разработки в современном мире? Скорее он перегружен процессами вокруг, а багов стало только больше. Фреймворки генерят что-то под капотом, создавая мусорный код, а разраб не знает, как работает ORM и дергает в цикле атрибут БД.
Пример про баг в три строчки: когда убрали
WITH NOLOCK, который кто-то когда-то добавил. Халтура это была или оправданный хинт на тот момент - неизвестно. Но он был. А человек уже давно не работает. В какой-то момент это выстрелило. Оказалось, что он где-то внутри вложенного запроса в хранимке, которая вызывается только в одном месте раз в квартал. И это то, о чем вы говорите:В 1%, ой-бой, это исправление
безобидногонедосмотра уволившегося коллеги. Еще 1% остается на то, что это валидный кейс.Это не значит, что так не бывает.
Пример оправданной оптимизации:
Чтобы в наше время кто-то действительно этим занимался... В современном мире мне назвать такой пример сложно. Это скорее исключение. Потому что сторипоинты показывают, что проще докупить еще мощностей в ЦОД. Проще послать пользователя подальше, и сказать, что у него старый телефон, чем заниматься оптимизацией. Это реальность. Куча багованого софта, который никто никогда не будет исправлять, потому что якобы всего одна жалоба за все время, а не мажор. Зато там все покрыто автотестами.
Вы пользуетесь оперой? У нас же явно сказано, что мы гарантируем только хром.
Разве не так выглядит реальность? Но это уже очень большое отступление от темы статьи.Повторюсь, мне непонятен контекст разговора. Что мы обсуждаем?
PS. Статья не предлагает менять подход к разработке. Статья лишь предлагает попробовать оценить когнитивные затраты.
sic
04.03.2026 14:10Я не пишу код уже давно
Вот а я пишу код. Так что мне не понятна идея, чью боль мы хотим решить. Программиста, когда его промежуточные этапы работы уходят в мусорное ведро, он страдает от ощущения, "что возможно сделал мало", и болеет потом синдромом самозванца. Или руководства, которое видит очень нестабильный перформанс программистов и теряет возможность предсказать скорости процессов.
Обе проблемы важны, требуют решения, но обычно в грамотно организованных командах они решаются через фиксацию промежуточных результатов. Это важно еще и с другой стороны, что "недоделанное" решение, имеющее полезные артефакты (ту же конфигурацию, где проблема повторяется) можно перенести на другого программиста, если у изначально ее решавшего, появляется более срочный кейс.
Даже менее консистентные промежуточные результаты в большинстве компаний фиксировались, если это тикет на плавающий баг, то ежедневно обновляется план дальнейшего исследования, и фиксируются попытки, которые не привели к результатам. Поначалу, там, где не было так принято, некоторые носы ворочали, а потом сами убедились, что очень удобно придти в понедельник "с пустой головой" и понять с чего надо продолжить. А тикет всегда добавляется в PR.
Может изначально я как-то слишком прямолинейно начал, но, хоть и не отрицаю проблем, описанных в статье, утверждаю, что решение уже есть, и оно в организации работы команды. Для хаба "управление разработкой" это как бы довольно очевидно.
Но я видел массу примеров в весьма крупных финтехах, когда разраб пофиксил багу и никаких тестов не появилось, а ручник даже не удосужился сделать несколько скринов о том, что он это протестил. Вы скажете, что это проблема команды и процессов. Нужно повесить техлида и разогнать сеньора QA. Возможно. Но идеального мира не существует. Косяков полно везде.
Вот именно. Я бы это бы и сказал, может помягче, но суть та же. Не надо позволять работникам даже играть в Генри Форда. Если не ставить документирование о выполненной работе в процессы команды, то очень быстро команда фрагментируется до тех кто использует отсутствие лишней вербозности себе в плюс, и на тех, кто от этого "молча" страдает.
Это сломанный процесс, который раньше решали либо глупыми и формальными KPI, либо ежедневными собраниями по полчаса, где все отчитываются друг перед другом что делают (но слово не воробей), либо вообще в стримы с экрана (а их все равно никто не смотрит, или смотрят когда и так уже ясно, что человек не работает).
А проблему "старается"/"не старается" не нужно решать. Вот допутим некий Коля берет некую "сложную задачу" (потому что либо плавающая, либо описание неполное, либо ранее ее уже кто-то брал, но не справился, или она снова всплыла). Оценивает ее в две недели. Открывает отладчик, и начинает там рандомные какие-то пути гонять, в код поглядывая, надеясь что проблема на глаз найдется. А что, времени еще уйма, если он ждет решения в три строчки, то он хоть в последний момент его может разродить.
Прошла неделя, проблему Коля не смог воспроизвести, но уже в принципе придумал решение в 5 строчек, как ее вообще закостылить. Сидит дальше в отладчике ковряет. Вот уже два дня осталось, Коля уже коммитит свой workaround в 5 строчек, в тикете пишет, "проблема не воспроизвелась, но теперь она точно не вылезет". Надеется на чудо в пятиницу, но если что готов, сделать PR того что есть. Старался? Ну да, наверное. Или просто фрустрировал. Но дело не в этом, дело в том, что проблема решена хреново. И это выстрелит при первом же существенном рефакторинге. И Коля это знает. И теперь, чтобы не встрять еще долго он не будет брать задачи связанные с рефакторингом.
Допустим я беру такую задачу. Первым делом пытаюсь уточнить подробности о проблеме, чаще всего они исходят от клиентов продукта/сервиса, параллельно добавляю логирование всех хоть как-то связанных с проблемой мест. Логи естественно отключаемые. Сразу добавляю несколько тестов, которые хоть на моей машине и будут зелененькими, но есть шанс, что где-то, хоть на CI мигнут. Мигнут тесты, будут логи, будет понимание проблемного стейта. Если проблема еще более редкая, то уже буду просить клиентов, понятно через службу поддержки, развернуть апдейт, который якобы чинит баг, ну и здесь понятно что можно и дальше рабочий процесс рассказывать, но да, это не игра в одни ворота. "Коля, отладчик, код, и тишина". Здесь нужна организация. Часто люди за этим и идут работать в команду.
И так у них и складывается понимание, что есть хорошая команда, а что слабая, что есть удобная организация, а что бардак. Хорошие практики закрепляются, эволюционируют...
И тут Вы правы, дело не в 2005 году. В принципе это просто часть моего опыта. Но где-то с тех пор, ни в каких других командах (а не все из них были прям супер) такой практики как "две недели - три строчки кода" ни в прямом ни в менее строгом значении уже не существовало.
А когда нет юниттестов, логов, билдсервера, CI, автотестов, специалиста поддержки пользователей, таск трекера, гита, - хотя бы чего-то из этого, то путь может быть сложнее.
rt001 Автор
04.03.2026 14:10Полностью согласен с вашим посылом и вижу, что у вас очень большой опыт.
либо вообще в стримы с экрана (а их все равно никто не смотрит, или смотрят когда и так уже ясно, что человек не работает)
Вот смысл статьи как раз оцифровать (картировать) это. Построить паттерны.
Так что мне не понятна идея, чью боль мы хотим решить. Программиста, когда его промежуточные этапы работы уходят в мусорное ведро, он страдает от ощущения, "что возможно сделал мало", и болеет потом синдромом самозванца. Или руководства, которое видит очень нестабильный перформанс программистов и теряет возможность предсказать скорости процессов.
И ту и другую. Если из этих тепловых карт удастся выделить паттерны. Каждый найдет в них свое. Программист поймет, что он не просто так потратил время. Будет видно его интеллектуальную активность на все 100, что нет повода для неловкого чувства. И руководство увидит способы мышления для разных людей, а так же то, что одни задачи эффективнее решает Вася, а другие - Петя. Но это будет не субъективная оценка начальника, а реальная карта. Как-то так.
frostsumonner
04.03.2026 14:10Мне очень нравилось и до сих пор нравится когда у тебя в пуле разные задачи: в одних тебе надо потратить неделю и в результуте написать две сьрочки, в других за 1 день написать 500. В этом случае ты можешь начать с непонятной баги, котрая случается только на проде, и если нет прогресса, перейти к какой-то скучной технической таске.
AndrewTishkin
04.03.2026 14:10Мне скидывали вот такие видео от одного известного в своих кругах товарища:
https://youtube.com/shorts/FZqBp1i73tI?si=p6MKkKS2DyrdPgpb
https://www.youtube.com/live/\_H0isUrZ8l0?si=WvLa7Hf4eSxJm4aP&t=35m52s
Android1983
04.03.2026 14:10Вот. Самая актуальная тема разработчик и оценка его деятельности. Я бы предложил кто захочет пусть кидают предложения как проверить что программист вообще работал. Тут просто вариантов много, но нужен самый эффективный.
parakhod_1
04.03.2026 14:10Вот опять же - зачем нужно проверять «что программист работал»? Сизиф вон тоже работал.
Если мы говорим об абсолютно любом бизнесе, а даже и не бизнесе, некоммерческой или государственной организации, то единственный критерий - это результат работы. Новый функционал. Оптимизация старого функционала (измеряемая - уменьшение задержек или количества запросов, уменьшение затрат, поддержка большого количества устройств). Облегчение дальнейшей поддержки проекта или имплементации нового функционала.
Процесс работы ради процесса (например стремление сделать код максимально изящным и красивым) - это абсолютно бессмысленное, не сказать вредное. Кстати очень многие опен-сорсщики приходящие в коммерческие компании этого не понимают. И обижаются когда их стремление отполировать код до совершенства никто не ценит
rt001 Автор
04.03.2026 14:10Бизнес хочет понимать, что он заплатил Х не за красивые глаза.
Что есть результат? Выпуск фичи?
У бизнеса есть масса задач, а ресурс, в виде программиста, ограничен.
Если строить деловые отношения на доверии, из предположения, что человек не просто так делал работу долго, а что это действительно нельзя было сделать быстрее, то ваш вариант нормальный. Но это утопия.
Бизнес же хочет сделать что-то еще за этот период, сроки горят. А программер вроде как занят другой задачей. Именно из-за наличия других задач, которые бизнесу тоже нужны сейчас, возникает резонный вопрос: Программист действительно ей занят или просто тянет время? А если поднажать на газ?
Обычно бизнес платит оклад и хочет за этот оклад (по сути абонентская плата) получать максимально возможное количество фичей. Но фича получилась только одна.
У бизнеса всегда будут вопросы:
Почему только одна?
А могли ли мы получить 2 фичи?
Что нужно, чтобы было 2 фичи?
Может, нам купить печеньки или более мощное оборудование? Изменить график работы? Чего не хватает, чтобы было 2 фичи в месяц?Все вот эти сторипоинты это лишь попытка бизнеса суррогатными метриками доказать самому себе, что он использовал ресурс на максимум.
parakhod_1
04.03.2026 14:10Мне кажется у вас есть небольшое непонимание того, как работает бизнес. То есть на уровне, условно говоря, ночного ларька, всё примерно так. Но для чуть более сложных систем всё чуть сложнее. Для больших корпораций - вообще совершенно по-другому.
Да, у бизнеса есть масса задач, это верно. И тактических, и стратегических. Для реализации этих задач бизнесу нужны ресурсы. Человеческие ресурсы в том числе. Но рассуждать о них в терминах "сроки сгорят" и "фичей сделать" - это крайнее упрощение. Иногда (я бы даже сказал изредка) встречающееся среди младшего менеджмента в не самых крупных и удачливых компаниях, но не более того.
Бизнес заинтересован в деньгах. Деньги - это не обязательно прибыли (в информационных технологиях и вообще хайтеке даже чаще всего совсем не прибыли). Деньги - это не фичи. Деньги - это то, как оценивается компания. На основании того, что она делает. Или планирует сделать. Или на основании интеллектуальной собственности которая у неё есть. Или аудитории (в широком или узком смысле - два десятка топовых хирургов мирового уровня пользующихся специализированным софтом сделают компанию гораздо более дорогостоящей чем два миллиона бездельников, условно тапающих на условного хомяка, хотя это тоже каких-то денег вероятно стоит).
Фичи? Фичи это хорошо, когда надо именно фичи. Когда они создают customer value, если она важна. Иногда компании держат какой-то проект и соотвественно команду на проекте исключительно для того чтобы держать часть рынка, или ту же интеллектуальную собственность. Будет добавлено сто фич или ноль фич - вообще без разницы. Иногда компании (особенно крупные) держат сотрудников просто для того чтобы иметь возможность бросить их на какой-нибудь другой проект. И они могут вообще ничего не делать, это выгодно бизнесу, потому что у них есть ресурс и пространство для маневра. Ну хорошо, конечно, когда этих людей можно чем-то занять (например тот же код в порядок приводить, если делать больше нечего), но и это совершенно не обязательно.
Не говоря уж о случае, когда человека держат просто за имя или за звания. И исключительно это добавляет к стоимости компании (и к деньгам соотвественно), а уж что он делает - вообще не важно. Кстати бывает что таким людям лучше б вообще ничего не делать (особенно на уровне менеджмента), меньше убытков будет.
Ну и возвращаяся к тому самом простому случаю, с фичами. Бизнесу по-хорошему совершенно параллельно, кто там и сколько будет работать. Ему нужны фичи в определённые сроки за определённые деньги. Плюс какая-то гибкость в возможности изменять количество добавляемых фич, сроки и деньги (понятно что эти три параметра взаимосвязанные). А уж как это делается (и кем конкретно - штатным сотрудником, контрактором, внешним подрядчиком) - это вообще дело двадцатое. А уж то, сколько километров наматывает мышкой и сколько строк коммитит конкретный Вася - это вообще никому по-хорошему не интересно.rt001 Автор
04.03.2026 14:10Сейчас вы смещаете фокус в другое русло и противоречите себе
Коротко хронология нашей беседы
Зачем проверять, работал ли программист? Результат - это фичи, оптимизация, польза. Процесс ради процесса - вреден. Полировка кода без бизнес-цели - бессмысленна.
Окей. Давайте про результат. Бизнес купил программиста и хочет максимум результата (2 фичи вместо одной). Почему только одна? Может, ему печенек не хватает? Бизнес ищет метрики, чтобы понять, выжал ли он из ресурса всё.
Вы мыслите на уровне ларька. В большой корпорации часто держат людей просто так - для пространства, для маневра, для имени, для захвата рынка. Фичи - это не главное. Главное деньги - это капитализация. Считать комиты и строки - удел мелких. Важны лишь сроки, бюджет и результат, а процесс - дело десятое. Если результат предоставлен в срок, ты - молодец.
Противоречие
Если бизнесу плевать на фичи, и он держит людей ради имени или чтобы забить рынок, то вопрос «Почему программист сделал мало фич?» просто не возникает. Понятие эффективности не возникает. Бизнес не дергает такого программиста вопросами про сторипоинты. (Но бизнес почему-то дергает. Видимо, ларечники, в душе).
Если же бизнес задается вопросом «Почему только одна фича?», значит, он находится именно в той парадигме, где важна эффективность и где каждый день простоя - это потеря денег. И эти самые фичи оформляются как CAPEX (инвестиция), чтобы показать инвесторам активы. Задавая вопрос "почему только одна фича?" бизнес как раз и стремится увеличить актив, минимизируя CAPEX (вложения).
Смещение фокуса
Сначала вы говорите, что не нужно отчитываться за процесс, потому что важен результат. Отчитываться нужно за результат и платить за него же.
Затем внезапно вы говорите, что корпорации нанимают Звезду, которая ничего не делает, но это увеличивает привлекательность компании.Однако компания сознательно пошла на первый и на второй шаг. И ждет от каждого из них разный результат. Измеряет эти результаты и путь к ним по-разному .
Нанимая программистов ждет фичи и задает вопросы об эффективности: почему одна фича, а не две
Нанимая Звезду ждет имидж и взлет акций и задает вопросы о PR: почему только 0.5% конверсии
Компания задает эти вопросы, потому что они неизбежны где есть деньги. Бизнес покупает станок, который по паспорту производит Х деталей в час. Как только запаса мощности перестанет хватать, рано или поздно бизнес задаст вопрос: Почему Х? А как сделать Х+1? Бизнес вынужден лезть в процесс. Он пока не готов покупать второй станок и пытается понять, все ли соки он выжал из существующего.
Как раз все эти суррогатные метрики и являются изобретением крупного и гигантского бизнеса. Мелкому и среднему это не надо, хоть они и пытаются посматривать на старших братьев. Но там все на виду. Директор видит, что Вася сидит до ночи и в курилке не появляется уже неделю, потому что НДС и аврал.
А в крупном, с размытой географией и часовыми поясами, где не понятно, как за всеми уследить, начинают изобретать/покупать сотни разных метрик.
Метрики - это дитя недоверия, рожденное масштабом.
parakhod_1
04.03.2026 14:10Естественно я сместил фокус. На то о чём начали говорить вы.
Вы начали говорить об интересах бизнеса.
На что я вам сказал что даже фичи - это вообще ни разу не основной интерес бизнеса.
А даже если вернуться исключительно к фичам, то замеры трудолюбивости конкретного Васи - это вообще ни о чём.
Ну и да, вы видите "противоречия" в том, что я говорю что бизнес - это вообще-то не что-то простое, и бывают разные ситуации и разные требования.
При этом обратите внимание на свой лонгрид - вы везде описываете "бизнес" как какое-то одно существо с одним желанием. Когда в реальности это множество интересов совершенно разных людей, часто взаимоисключающих (но правда деньги нравятся всем, и тут можно найти общее, да и то я вам элементарно приведу десяток примеров того, как под деньгами каждый понимает совершенно своё, и опять же интересы людей могут быть полностью противоположны).
И да, метрики от недоверия - есть такое. Не то чтобы прям необходимое, но работает чтобы отфильтровывать хотя бы небольшой процент тех кто уж совсем ничего не делает и никакого толку не приносит никаким образом. Просто один из механизмов саморегуляции, который, кстати, применяется не всеми и не везде.
vityo
04.03.2026 14:10Идея хорошая, а норм реализации или идею конкретную или предложение не понял. Где-то видел новость, что пытаются создать новый формат для гит в котором комментарии будут идти не от пользователя, а от аи которая этот код изменяла, и будут метаданными рядом со строками самими. Чтобы видеть ее скитания. Похоже на твою идею?
rt001 Автор
04.03.2026 14:10Вероятно, вы про Git AI
Не совсем то. GitAI фиксирует рассуждения модели, промежуточные этапы, уточнения контекста.
С живым человеком рассуждения зафиксировать не получится. Человек просто делает и не проговаривает это все. Но можно зафиксировать инкрементальные изменения того, как вы писали слово "привет".
п->пр->при->прив->приве->привет
Затем ставили перед ним табуляции, меняли регистр
привет->_привет->__привет->__Привет
Это все действия, которые были сделаны до того, как появился какой-то работающий блок кода
Далее вы с кем-то обсуждали в чате эту задачу.
Трекер видит, что обсуждение в контексте этой задачи и добавляет этой задаче баллы.
Еще вы читали stackoverflow на тему этой задачи и трекер снова отмечает это.Сырой лог можно затем сжать в некие формы.
Все эти маркеры выстроить в некую последовательность и вес (но это уже этап анализа и построения карты)
Мне сложно сейчас сказать, на что будет похожа эта карта и какие выводы из нее можно будет сделать, но задумка в этом.
ИИ здесь нужен для выделения паттернов, потому что вручную этот "шум" анализировать невозможно.
parakhod_1
Очередное рацпредложение как правильно контролировать процесс? Вместо того чтобы просто смотреть время от времени на реальные результаты? Ну ок.
Да, единственный вариант как сделать так, чтобы сотрудник работал хорошо - это сделать так, чтобы он был сам заинтересован в результатах своей работы. И тут все рецепты давно известны. Либо работа должна быть такая, чтобы человека от ней штырило. Либо у человека должен быть прямой финансовый интерес в компании (доля/RSU/опционы). Оптимально и то и другое.
А на каждый новый кнут найдутся нехитрые способы его обойти.
rt001 Автор
Не знаю, где вы увидели здесь кнут. Идея была обратная, призванная показать, что 2 строки кода могут даваться очень непросто, в то время, как кнут требует отчитаться, куда ты потратил 2 недели.
parakhod_1
А зачем вообще нужно отчитываться и показывать чего-то кому-то, если это про процесс, а не про результат?
У вас же не абстрактные "две строки кода", у вас тикет на них. И на тикет есть какой-то эстимейт. И пусть это будет даже не две строки а минус две строки. А может и вообще ноль строк. Но если тикет закрыт - то результат есть.
Вопросы тут могут быть только если он закрыт за две недели, а заэстимейтен он был на четыре часа. Вот тут да, можно просто поинтересоваться кто был настолько оптимистичен и как избежать этого в будущем (либо эстимейтить лучше, либо в следующий раз поручать такого типа задачи тому, кто сделает их за два часа, а не за две недели).
rt001 Автор
Зачем отчитываться? Но вы сами говорите про эстимейты. Зачем тогда они? Тикет закрыт, результат есть и ладно. Зачем эстимейты? Для отчетности. Для планирования. Для оценки. Для приоритетов. Бизнес хочет знать, сколько ему это будет стоить до начала, сколько это реально стоило и насколько действительно задача сложная. Но это все суррогат, потому что измеряет теплое в килограммах.
Кто ставит эти эстимейты? Люди. На основании чего? Субъективной оценки: я угадаю эту мелодию с трех нот. Если речь идет о разработке с нуля или линейных изменениях, типа покрасить кнопочку, тогда да, можно оценить трудозатраты. Дизайн есть? АПИ есть? Тогда 10 минут.
Но если ставится задача починить баг или оптимизировать какой-то кусок в легаси. Какая здесь может быть оценка? Это пальцем в небо. Я оптимизирую этот запрос из 500 строк за 2 часа. Что? Как можно дать такую оценку не зная причины тормозов? Там может быть все что угодно, от конфигов до блокировок и умирающих дисков.
А если кто-то скажет месяц, но починит за час, нужно ли здесь поинтересоваться, кто был настолько пессимистичен и как избежать этого в будущем? А может кто-то справился бы за полчаса. Нужно ли передать такого типа задачи тому, кто справился бы за полчаса?
Здесь уже оценка скорее сводится тому, насколько эта починка необходима. Некий верхний порог, типа если за 2 дня не удастся разобраться - откладываем на неопределенный срок.
Все, что описано в статье, это про то, почему на задачу было потрачено Х часов. Действительно человек ей занимался или просто сказал что она сложная, а сам развлекался неделю, даже не прикасаясь к ней. После сорванных сроков попросил еще времени. Суррогатные метрики обесценивают труд одних, но необоснованно поднимая стоимость других.
Я вам расскажу историю из студенческих лет.
Подрабатывал я в автосервисе электриком. Однажды состоятельный клиент привез старый УАЗик, чтобы подготовить его для охоты. Он не скупился на запчасти. Там поменяли КПП, половину мотора и прочего. Одной из задач было установить туда новое электрооборудование: стеклоочиститель, новые фары, вывести управление светом на подрулевой переключатель и прочее. Как вы знаете, в старом УАЗике подрулевой только один, управляющий поворотниками. Был куплен новый руль от волги, торпеда, подрулевые, двигатель дворников с несколькими скоростями и программируемым интервалом. Осталось дело за малым - подключить это все.
Я 2 недели приходил по вечерам, прозванивал, обжимал клеммы, плел новые жгуты из проводов, каждый провод был с биркой и подписан. Никакой изоленты. Схему нарисовал.
Знаете, как руководство сервиса оценило мою работу? Они взяли нормачасы из официальной книжки автоваза.
Замена подрулевого (с/у) 10 минут.
Замена кнопки габаритов (с/у) 3 минуты.
Замена реле стеклоочистителя (с/у) 1 минута.
И т.д.
Получите 300р.
Якобы это я такой медленный, раз делал так долго. Вон, в книжке все давно рассчитано и клиента они возьмут по книжке. (конечно они все понимали, просто не хотели мне платить 30%, как изначально договорились)
(с УАЗика они взяли за эту работу 5000р, а 95 бензин тогда стоил 17р)
Так какой тут должен был быть эстимейт? По книжке ~30 минут.
parakhod_1
Ну тут у вас ключевой вопрос "а кто эстимейтит".
Зачем эстимейтить понятно - не для отчётности, а именно для планирования. Когда не влезает в отведённые сроки, надо урезать функционал.
А вот эстимейтят либо сами инженеры, либо PM со слов тех же инженеров. Если это происходит как-то по-другому, то надо просто в спокойном режиме искать нормальную работу.