Ааа, вы не про стимпанк калейдоскоп из текущей статьи, вы про квантовые законы.
Это отдельная история и у меня есть соображения на этот счет. Но это тема для отдельной статьи. Быть может, я ее напишу.
Но если коротко В понятиях современных ИТ технологий можно было бы рассмотреть всю нашу вселенную и реальность как виртуальную машину. Внутри нее есть свои групповые политики, константы и сетевые интерфейсы. ZFC это операционная система конкретной ВМ. Скорость света - ее тактовая частота. А планковские единицы это разрядность шины. Но программа внутри виртуальной машины не может заглянуть за пределы этой среды (неполнота). Она может по косвенный признакам понять, что, где-то там есть гипервизор (хост). Но что он из себя представляет и сколько еще виртуальных машин на нем крутится - загадка.
Когда программа запускается на тысячах компьютеров, но у нее нет облачного сервера для обмена, то программа думает, что этот конкретный компьютер и есть единственная реальность, со всей структурой ее папок и обоями на рабочем столе.
Декогеренция в этой модели это как маркер на сетевом пакете, который через концентратор полетел во все виртуальные машины. Вот мы ловим пакет с этой меткой в конкретной ВМ и видим его размер. В какой ВМ мы его поймали? Видимо в той, в которой находимся. Не имея доступа к хосту и концентратору невозможно узнать, что стало с другими пакетами.
Здесь фильтром пакетов работает не интерфейс, а сам наблюдатель. Подобно тому, как если внимательно смотреть на гору и видеть ее вершину, но невозможно в этот же момент внимательно смотреть на речку под горой.
Ваше квантовое ядро это хост, а коннектор - интерфейс к нему, верно?
В озере есть такая бусинка и она черного цвета. Она не отражает свет. В какой-то момент стразик поворачивается в ее сторону и всё, темнота. Нет луча из озера чтобы довернуть стразик в сторону другой бусинки. Процесс остановился.
Полностью согласен с вашим посылом и вижу, что у вас очень большой опыт.
либо вообще в стримы с экрана (а их все равно никто не смотрит, или смотрят когда и так уже ясно, что человек не работает)
Вот смысл статьи как раз оцифровать (картировать) это. Построить паттерны.
Так что мне не понятна идея, чью боль мы хотим решить. Программиста, когда его промежуточные этапы работы уходят в мусорное ведро, он страдает от ощущения, "что возможно сделал мало", и болеет потом синдромом самозванца. Или руководства, которое видит очень нестабильный перформанс программистов и теряет возможность предсказать скорости процессов.
И ту и другую. Если из этих тепловых карт удастся выделить паттерны. Каждый найдет в них свое. Программист поймет, что он не просто так потратил время. Будет видно его интеллектуальную активность на все 100, что нет повода для неловкого чувства. И руководство увидит способы мышления для разных людей, а так же то, что одни задачи эффективнее решает Вася, а другие - Петя. Но это будет не субъективная оценка начальника, а реальная карта. Как-то так.
Не совсем то. GitAI фиксирует рассуждения модели, промежуточные этапы, уточнения контекста.
С живым человеком рассуждения зафиксировать не получится. Человек просто делает и не проговаривает это все. Но можно зафиксировать инкрементальные изменения того, как вы писали слово "привет". п->пр->при->прив->приве->привет Затем ставили перед ним табуляции, меняли регистр привет->_привет->__привет->__Привет Это все действия, которые были сделаны до того, как появился какой-то работающий блок кода
Далее вы с кем-то обсуждали в чате эту задачу. Трекер видит, что обсуждение в контексте этой задачи и добавляет этой задаче баллы. Еще вы читали stackoverflow на тему этой задачи и трекер снова отмечает это.
Сырой лог можно затем сжать в некие формы.
Все эти маркеры выстроить в некую последовательность и вес (но это уже этап анализа и построения карты)
Мне сложно сейчас сказать, на что будет похожа эта карта и какие выводы из нее можно будет сделать, но задумка в этом. ИИ здесь нужен для выделения паттернов, потому что вручную этот "шум" анализировать невозможно.
Сейчас вы смещаете фокус в другое русло и противоречите себе
Коротко хронология нашей беседы
Зачем проверять, работал ли программист? Результат - это фичи, оптимизация, польза. Процесс ради процесса - вреден. Полировка кода без бизнес-цели - бессмысленна.
Окей. Давайте про результат. Бизнес купил программиста и хочет максимум результата (2 фичи вместо одной). Почему только одна? Может, ему печенек не хватает? Бизнес ищет метрики, чтобы понять, выжал ли он из ресурса всё.
Вы мыслите на уровне ларька. В большой корпорации часто держат людей просто так - для пространства, для маневра, для имени, для захвата рынка. Фичи - это не главное. Главное деньги - это капитализация. Считать комиты и строки - удел мелких. Важны лишь сроки, бюджет и результат, а процесс - дело десятое. Если результат предоставлен в срок, ты - молодец.
Противоречие
Если бизнесу плевать на фичи, и он держит людей ради имени или чтобы забить рынок, то вопрос «Почему программист сделал мало фич?» просто не возникает. Понятие эффективности не возникает. Бизнес не дергает такого программиста вопросами про сторипоинты. (Но бизнес почему-то дергает. Видимо, ларечники, в душе).
Если же бизнес задается вопросом «Почему только одна фича?», значит, он находится именно в той парадигме, где важна эффективность и где каждый день простоя - это потеря денег. И эти самые фичи оформляются как CAPEX (инвестиция), чтобы показать инвесторам активы. Задавая вопрос "почему только одна фича?" бизнес как раз и стремится увеличить актив, минимизируя CAPEX (вложения).
Смещение фокуса
Сначала вы говорите, что не нужно отчитываться за процесс, потому что важен результат. Отчитываться нужно за результат и платить за него же. Затем внезапно вы говорите, что корпорации нанимают Звезду, которая ничего не делает, но это увеличивает привлекательность компании.
Однако компания сознательно пошла на первый и на второй шаг. И ждет от каждого из них разный результат. Измеряет эти результаты и путь к ним по-разному .
Нанимая программистов ждет фичи и задает вопросы об эффективности: почему одна фича, а не две
Нанимая Звезду ждет имидж и взлет акций и задает вопросы о PR: почему только 0.5% конверсии
Компания задает эти вопросы, потому что они неизбежны где есть деньги. Бизнес покупает станок, который по паспорту производит Х деталей в час. Как только запаса мощности перестанет хватать, рано или поздно бизнес задаст вопрос: Почему Х? А как сделать Х+1? Бизнес вынужден лезть в процесс. Он пока не готов покупать второй станок и пытается понять, все ли соки он выжал из существующего.
Как раз все эти суррогатные метрики и являются изобретением крупного и гигантского бизнеса. Мелкому и среднему это не надо, хоть они и пытаются посматривать на старших братьев. Но там все на виду. Директор видит, что Вася сидит до ночи и в курилке не появляется уже неделю, потому что НДС и аврал.
А в крупном, с размытой географией и часовыми поясами, где не понятно, как за всеми уследить, начинают изобретать/покупать сотни разных метрик.
Метрики - это дитя недоверия, рожденное масштабом.
Бизнес хочет понимать, что он заплатил Х не за красивые глаза.
Что есть результат? Выпуск фичи?
У бизнеса есть масса задач, а ресурс, в виде программиста, ограничен.
Если строить деловые отношения на доверии, из предположения, что человек не просто так делал работу долго, а что это действительно нельзя было сделать быстрее, то ваш вариант нормальный. Но это утопия.
Бизнес же хочет сделать что-то еще за этот период, сроки горят. А программер вроде как занят другой задачей. Именно из-за наличия других задач, которые бизнесу тоже нужны сейчас, возникает резонный вопрос: Программист действительно ей занят или просто тянет время? А если поднажать на газ?
Обычно бизнес платит оклад и хочет за этот оклад (по сути абонентская плата) получать максимально возможное количество фичей. Но фича получилась только одна.
У бизнеса всегда будут вопросы: Почему только одна? А могли ли мы получить 2 фичи? Что нужно, чтобы было 2 фичи? Может, нам купить печеньки или более мощное оборудование? Изменить график работы? Чего не хватает, чтобы было 2 фичи в месяц?
Все вот эти сторипоинты это лишь попытка бизнеса суррогатными метриками доказать самому себе, что он использовал ресурс на максимум.
Я не очень понимаю вектор этого разговора. Зачем вы навешиваете на меня ярлыки, которых нет. "2005 год, водопад..." Это не моя проблема. Я не пишу код уже давно (о чем говорил в самом начале), хотя по-прежнему очень близок к разработке. И как бы если посмотреть с этой позиции, можно сказать, что мне все равно, как там ПМ оценивают свои сторипоинты. Я лишь поделился размышлениями и не более.
Если суть статьи вам не понравилась и вы не увидели в нем рационального зерна, ок.
Может вам не понравился заголовок статьи и вы хотите сказать, что он неправдоподобен? Это просто заголовок. В статье несколько другой посыл.
построить образ проблемной конфигурации
А разве чтобы его построить, не нужно вникнуть в проблему и изучить хотя бы условия, при которых это воспроизводится. Разве это не интеллектуальная деятельность?
Все это окружение, виртуалки, эксперименты, о которых вы говорите, разве будут как-то отражены в финальном комите? Но вы их делали. Вы тратили время на гипотезы и их проверки. Там будет только фикс по делу. Артефакты могут остаться, если кто-то требует их в качестве доказательств, но это не всегда и не везде так. Если у вас этот процесс налажен - прекрасно. Но я видел массу примеров в весьма крупных финтехах, когда разраб пофиксил багу и никаких тестов не появилось, а ручник даже не удосужился сделать несколько скринов о том, что он это протестил. Вы скажете, что это проблема команды и процессов. Нужно повесить техлида и разогнать сеньора QA. Возможно. Но идеального мира не существует. Косяков полно везде.
Потом отладка, и исправление
Вот в этом и кроется вся соль задумки. Отладка это не нажатие одной кнопки. Весь процесс этой отладки никто не видит. Не видно количества усилий, которые были на это затрачены. Видно только результат фикса, новые тесты, что-то еще. Это все готовый результаты. Они не появились по щелчку пальцев. Вы работали, думали, искали нестыковки. Это интеллектуальная деятельность, объем которой не виден в комите и в скринах. Этого артефакта просто нет, потому что нет системы, которая могла бы его зафиксировать. Не видно путь, который вы прошли, чтобы получить результат.
Вы говорите про высокий уровень разработки в современном мире? Скорее он перегружен процессами вокруг, а багов стало только больше. Фреймворки генерят что-то под капотом, создавая мусорный код, а разраб не знает, как работает ORM и дергает в цикле атрибут БД.
Пример про баг в три строчки: когда убрали WITH NOLOCK, который кто-то когда-то добавил. Халтура это была или оправданный хинт на тот момент - неизвестно. Но он был. А человек уже давно не работает. В какой-то момент это выстрелило. Оказалось, что он где-то внутри вложенного запроса в хранимке, которая вызывается только в одном месте раз в квартал. И это то, о чем вы говорите:
В 1%, ой-бой, это исправление безобидного недосмотра уволившегося коллеги. Еще 1% остается на то, что это валидный кейс.
Это не значит, что так не бывает.
Пример оправданной оптимизации:
Чтобы в наше время кто-то действительно этим занимался... В современном мире мне назвать такой пример сложно. Это скорее исключение. Потому что сторипоинты показывают, что проще докупить еще мощностей в ЦОД. Проще послать пользователя подальше, и сказать, что у него старый телефон, чем заниматься оптимизацией. Это реальность. Куча багованого софта, который никто никогда не будет исправлять, потому что якобы всего одна жалоба за все время, а не мажор. Зато там все покрыто автотестами. Вы пользуетесь оперой? У нас же явно сказано, что мы гарантируем только хром. Разве не так выглядит реальность? Но это уже очень большое отступление от темы статьи.
Повторюсь, мне непонятен контекст разговора. Что мы обсуждаем?
PS. Статья не предлагает менять подход к разработке. Статья лишь предлагает попробовать оценить когнитивные затраты.
Конечно 3 строчки это багфикс/оптимизация или доработка. Разве где-то речь шла о том, что это новая фича?
О каком 2005 и дизассемблере вы говорите? Я вам приведу десятки примеров, как в современных архитектурах не могли починить месяцами плавающий баг авторизации из-за куков. Выделяли каждый спринт несколько часов. Каждый новый решатель говорил, что предыдущий балбес, а я вот точно знаю где искать. Но обломали зубы. Баг так и живет.
Зачем отчитываться? Но вы сами говорите про эстимейты. Зачем тогда они? Тикет закрыт, результат есть и ладно. Зачем эстимейты? Для отчетности. Для планирования. Для оценки. Для приоритетов. Бизнес хочет знать, сколько ему это будет стоить до начала, сколько это реально стоило и насколько действительно задача сложная. Но это все суррогат, потому что измеряет теплое в килограммах.
Кто ставит эти эстимейты? Люди. На основании чего? Субъективной оценки: я угадаю эту мелодию с трех нот. Если речь идет о разработке с нуля или линейных изменениях, типа покрасить кнопочку, тогда да, можно оценить трудозатраты. Дизайн есть? АПИ есть? Тогда 10 минут.
Но если ставится задача починить баг или оптимизировать какой-то кусок в легаси. Какая здесь может быть оценка? Это пальцем в небо. Я оптимизирую этот запрос из 500 строк за 2 часа. Что? Как можно дать такую оценку не зная причины тормозов? Там может быть все что угодно, от конфигов до блокировок и умирающих дисков.
А если кто-то скажет месяц, но починит за час, нужно ли здесь поинтересоваться, кто был настолько пессимистичен и как избежать этого в будущем? А может кто-то справился бы за полчаса. Нужно ли передать такого типа задачи тому, кто справился бы за полчаса?
Здесь уже оценка скорее сводится тому, насколько эта починка необходима. Некий верхний порог, типа если за 2 дня не удастся разобраться - откладываем на неопределенный срок.
Все, что описано в статье, это про то, почему на задачу было потрачено Х часов. Действительно человек ей занимался или просто сказал что она сложная, а сам развлекался неделю, даже не прикасаясь к ней. После сорванных сроков попросил еще времени. Суррогатные метрики обесценивают труд одних, но необоснованно поднимая стоимость других.
Я вам расскажу историю из студенческих лет.
Подрабатывал я в автосервисе электриком. Однажды состоятельный клиент привез старый УАЗик, чтобы подготовить его для охоты. Он не скупился на запчасти. Там поменяли КПП, половину мотора и прочего. Одной из задач было установить туда новое электрооборудование: стеклоочиститель, новые фары, вывести управление светом на подрулевой переключатель и прочее. Как вы знаете, в старом УАЗике подрулевой только один, управляющий поворотниками. Был куплен новый руль от волги, торпеда, подрулевые, двигатель дворников с несколькими скоростями и программируемым интервалом. Осталось дело за малым - подключить это все.
Я 2 недели приходил по вечерам, прозванивал, обжимал клеммы, плел новые жгуты из проводов, каждый провод был с биркой и подписан. Никакой изоленты. Схему нарисовал.
Знаете, как руководство сервиса оценило мою работу? Они взяли нормачасы из официальной книжки автоваза.
Замена подрулевого (с/у) 10 минут. Замена кнопки габаритов (с/у) 3 минуты. Замена реле стеклоочистителя (с/у) 1 минута. И т.д. Получите 300р. Якобы это я такой медленный, раз делал так долго. Вон, в книжке все давно рассчитано и клиента они возьмут по книжке. (конечно они все понимали, просто не хотели мне платить 30%, как изначально договорились)
(с УАЗика они взяли за эту работу 5000р, а 95 бензин тогда стоил 17р)
Так какой тут должен был быть эстимейт? По книжке ~30 минут.
Не знаю, где вы увидели здесь кнут. Идея была обратная, призванная показать, что 2 строки кода могут даваться очень непросто, в то время, как кнут требует отчитаться, куда ты потратил 2 недели.
Но она может показать путь, который человек раньше не замечал
С этим я абсолютно согласен и регулярно использую модели с этой целью. Иногда она складывает комбинацию, позволяющую взглянуть на вопрос под другим углом. Или выделить паттерн в твоем тексте, о котором ты сам не догадывался.
Но в этом и основное отличие от создания нового.
Человек по сути делает то же самое в физическом мире. Он ходит по одной и той же тропинке каждый день на работу. Ничего необычного. И тут бах - вспышка. Что-то сложилось в голове и ты заметил какую-то закономерность. Ты ее не придумал, она была, но ты ее заметил и облек в некую формулировку. Это тот самый новый мост, о котором вы говорите.
Но модель этого сделать не может. Не потому что она плохая, а потому что она не присутствует в физическом мире. Она не может кожей понять в чем разница между холодом и жаром и при чем здесь теплые варежки. Значит, ее мостики фундаментально ограничены.
Вы видите сны, которые нельзя нарисовать на бумаге, потому что это будет совсем не то, что вы видели. Сны не укладываются в модель 3х мерного мира. А сны или ощущения от пролитого кипятка на руку — это переживания, которые и способствуют построению новых мостиков.
В этом смысле человек тоже не творит ничего нового. Все это уже есть, а наш опыт позволяет это связать воедино. Закон тяготения был, Ньютон его не создавал, но он построил мостик и рассказал об этом миру.
Вот интересно, если модель обучать разным текстам, но целенаправленно выпилить оттуда все упоминания про Ньютона и закон, она сможет помочь найти этот мостик в стихах Шекспира и описании полета птиц (в общем, на основании того, что было известно в те времена)?
А еще вы уже потратили время на уточнение запроса, чтобы добиться результата, но его так и нет. Валенки имеют несколько другой вид, нежели сапоги, покрытые то ли мехом то ли войлоком.
То, что у него на ногах, больше похоже на унты/торбаса, но никак не на валенки
Валенки
Я же говорил изначально, что бессмысленно мучить калейдоскоп, в котором нет нужных бусинок. Их там просто нет. В обучающей базе были десятки тысяч сапог и только 10 валенок. Его будет перекашивать в сторону сапог постоянно.
А простые люди в этом не разбираются. Когнитивный диссонанс из-за маркетингового названия сделал свое дело. После GPT уже целые профессии безопасников появились, призванных не выпустить ИИ из под контроля, а то еще захватят землю и поработят человечество. Отсюда же все идет. Поэтому бизнес бежит за этими ИИ, как зомби.
Ааа, вы не про стимпанк калейдоскоп из текущей статьи, вы про квантовые законы.
Это отдельная история и у меня есть соображения на этот счет. Но это тема для отдельной статьи. Быть может, я ее напишу.
Но если коротко
В понятиях современных ИТ технологий можно было бы рассмотреть всю нашу вселенную и реальность как виртуальную машину. Внутри нее есть свои групповые политики, константы и сетевые интерфейсы.
ZFC это операционная система конкретной ВМ.
Скорость света - ее тактовая частота. А планковские единицы это разрядность шины.
Но программа внутри виртуальной машины не может заглянуть за пределы этой среды (неполнота).
Она может по косвенный признакам понять, что, где-то там есть гипервизор (хост). Но что он из себя представляет и сколько еще виртуальных машин на нем крутится - загадка.
Когда программа запускается на тысячах компьютеров, но у нее нет облачного сервера для обмена, то программа думает, что этот конкретный компьютер и есть единственная реальность, со всей структурой ее папок и обоями на рабочем столе.
Декогеренция в этой модели это как маркер на сетевом пакете, который через концентратор полетел во все виртуальные машины. Вот мы ловим пакет с этой меткой в конкретной ВМ и видим его размер. В какой ВМ мы его поймали? Видимо в той, в которой находимся.
Не имея доступа к хосту и концентратору невозможно узнать, что стало с другими пакетами.
Здесь фильтром пакетов работает не интерфейс, а сам наблюдатель. Подобно тому, как если внимательно смотреть на гору и видеть ее вершину, но невозможно в этот же момент внимательно смотреть на речку под горой.
Ваше квантовое ядро это хост, а коннектор - интерфейс к нему, верно?
Поясните. Видимо, я не уловил суть вопроса.
Мне нравится ваш вопрос. Благодарю.
Речь идет о бусинке eos.
В озере есть такая бусинка и она черного цвета. Она не отражает свет. В какой-то момент стразик поворачивается в ее сторону и всё, темнота. Нет луча из озера чтобы довернуть стразик в сторону другой бусинки. Процесс остановился.
Полностью согласен с вашим посылом и вижу, что у вас очень большой опыт.
Вот смысл статьи как раз оцифровать (картировать) это. Построить паттерны.
И ту и другую. Если из этих тепловых карт удастся выделить паттерны. Каждый найдет в них свое. Программист поймет, что он не просто так потратил время. Будет видно его интеллектуальную активность на все 100, что нет повода для неловкого чувства. И руководство увидит способы мышления для разных людей, а так же то, что одни задачи эффективнее решает Вася, а другие - Петя. Но это будет не субъективная оценка начальника, а реальная карта. Как-то так.
Вероятно, вы про Git AI
Не совсем то. GitAI фиксирует рассуждения модели, промежуточные этапы, уточнения контекста.
С живым человеком рассуждения зафиксировать не получится. Человек просто делает и не проговаривает это все. Но можно зафиксировать инкрементальные изменения того, как вы писали слово "привет".
п->пр->при->прив->приве->привет
Затем ставили перед ним табуляции, меняли регистр
привет->_привет->__привет->__Привет
Это все действия, которые были сделаны до того, как появился какой-то работающий блок кода
Далее вы с кем-то обсуждали в чате эту задачу.
Трекер видит, что обсуждение в контексте этой задачи и добавляет этой задаче баллы.
Еще вы читали stackoverflow на тему этой задачи и трекер снова отмечает это.
Сырой лог можно затем сжать в некие формы.
Все эти маркеры выстроить в некую последовательность и вес (но это уже этап анализа и построения карты)
Мне сложно сейчас сказать, на что будет похожа эта карта и какие выводы из нее можно будет сделать, но задумка в этом.
ИИ здесь нужен для выделения паттернов, потому что вручную этот "шум" анализировать невозможно.
Сейчас вы смещаете фокус в другое русло и противоречите себе
Коротко хронология нашей беседы
Зачем проверять, работал ли программист? Результат - это фичи, оптимизация, польза. Процесс ради процесса - вреден. Полировка кода без бизнес-цели - бессмысленна.
Окей. Давайте про результат. Бизнес купил программиста и хочет максимум результата (2 фичи вместо одной). Почему только одна? Может, ему печенек не хватает? Бизнес ищет метрики, чтобы понять, выжал ли он из ресурса всё.
Вы мыслите на уровне ларька. В большой корпорации часто держат людей просто так - для пространства, для маневра, для имени, для захвата рынка. Фичи - это не главное. Главное деньги - это капитализация. Считать комиты и строки - удел мелких. Важны лишь сроки, бюджет и результат, а процесс - дело десятое. Если результат предоставлен в срок, ты - молодец.
Противоречие
Если бизнесу плевать на фичи, и он держит людей ради имени или чтобы забить рынок, то вопрос «Почему программист сделал мало фич?» просто не возникает. Понятие эффективности не возникает. Бизнес не дергает такого программиста вопросами про сторипоинты. (Но бизнес почему-то дергает. Видимо, ларечники, в душе).
Если же бизнес задается вопросом «Почему только одна фича?», значит, он находится именно в той парадигме, где важна эффективность и где каждый день простоя - это потеря денег. И эти самые фичи оформляются как CAPEX (инвестиция), чтобы показать инвесторам активы. Задавая вопрос "почему только одна фича?" бизнес как раз и стремится увеличить актив, минимизируя CAPEX (вложения).
Смещение фокуса
Сначала вы говорите, что не нужно отчитываться за процесс, потому что важен результат. Отчитываться нужно за результат и платить за него же.
Затем внезапно вы говорите, что корпорации нанимают Звезду, которая ничего не делает, но это увеличивает привлекательность компании.
Однако компания сознательно пошла на первый и на второй шаг. И ждет от каждого из них разный результат. Измеряет эти результаты и путь к ним по-разному .
Нанимая программистов ждет фичи и задает вопросы об эффективности: почему одна фича, а не две
Нанимая Звезду ждет имидж и взлет акций и задает вопросы о PR: почему только 0.5% конверсии
Компания задает эти вопросы, потому что они неизбежны где есть деньги. Бизнес покупает станок, который по паспорту производит Х деталей в час. Как только запаса мощности перестанет хватать, рано или поздно бизнес задаст вопрос: Почему Х? А как сделать Х+1? Бизнес вынужден лезть в процесс. Он пока не готов покупать второй станок и пытается понять, все ли соки он выжал из существующего.
Как раз все эти суррогатные метрики и являются изобретением крупного и гигантского бизнеса. Мелкому и среднему это не надо, хоть они и пытаются посматривать на старших братьев. Но там все на виду. Директор видит, что Вася сидит до ночи и в курилке не появляется уже неделю, потому что НДС и аврал.
А в крупном, с размытой географией и часовыми поясами, где не понятно, как за всеми уследить, начинают изобретать/покупать сотни разных метрик.
Метрики - это дитя недоверия, рожденное масштабом.
Бизнес хочет понимать, что он заплатил Х не за красивые глаза.
Что есть результат? Выпуск фичи?
У бизнеса есть масса задач, а ресурс, в виде программиста, ограничен.
Если строить деловые отношения на доверии, из предположения, что человек не просто так делал работу долго, а что это действительно нельзя было сделать быстрее, то ваш вариант нормальный. Но это утопия.
Бизнес же хочет сделать что-то еще за этот период, сроки горят. А программер вроде как занят другой задачей. Именно из-за наличия других задач, которые бизнесу тоже нужны сейчас, возникает резонный вопрос: Программист действительно ей занят или просто тянет время? А если поднажать на газ?
Обычно бизнес платит оклад и хочет за этот оклад (по сути абонентская плата) получать максимально возможное количество фичей. Но фича получилась только одна.
У бизнеса всегда будут вопросы:
Почему только одна?
А могли ли мы получить 2 фичи?
Что нужно, чтобы было 2 фичи?
Может, нам купить печеньки или более мощное оборудование? Изменить график работы? Чего не хватает, чтобы было 2 фичи в месяц?
Все вот эти сторипоинты это лишь попытка бизнеса суррогатными метриками доказать самому себе, что он использовал ресурс на максимум.
Я не очень понимаю вектор этого разговора. Зачем вы навешиваете на меня ярлыки, которых нет. "2005 год, водопад..." Это не моя проблема. Я не пишу код уже давно (о чем говорил в самом начале), хотя по-прежнему очень близок к разработке. И как бы если посмотреть с этой позиции, можно сказать, что мне все равно, как там ПМ оценивают свои сторипоинты. Я лишь поделился размышлениями и не более.
Если суть статьи вам не понравилась и вы не увидели в нем рационального зерна, ок.
Может вам не понравился заголовок статьи и вы хотите сказать, что он неправдоподобен? Это просто заголовок. В статье несколько другой посыл.
А разве чтобы его построить, не нужно вникнуть в проблему и изучить хотя бы условия, при которых это воспроизводится. Разве это не интеллектуальная деятельность?
Все это окружение, виртуалки, эксперименты, о которых вы говорите, разве будут как-то отражены в финальном комите? Но вы их делали. Вы тратили время на гипотезы и их проверки.
Там будет только фикс по делу. Артефакты могут остаться, если кто-то требует их в качестве доказательств, но это не всегда и не везде так. Если у вас этот процесс налажен - прекрасно. Но я видел массу примеров в весьма крупных финтехах, когда разраб пофиксил багу и никаких тестов не появилось, а ручник даже не удосужился сделать несколько скринов о том, что он это протестил. Вы скажете, что это проблема команды и процессов. Нужно повесить техлида и разогнать сеньора QA. Возможно. Но идеального мира не существует. Косяков полно везде.
Вот в этом и кроется вся соль задумки. Отладка это не нажатие одной кнопки. Весь процесс этой отладки никто не видит. Не видно количества усилий, которые были на это затрачены. Видно только результат фикса, новые тесты, что-то еще. Это все готовый результаты. Они не появились по щелчку пальцев. Вы работали, думали, искали нестыковки. Это интеллектуальная деятельность, объем которой не виден в комите и в скринах. Этого артефакта просто нет, потому что нет системы, которая могла бы его зафиксировать. Не видно путь, который вы прошли, чтобы получить результат.
Вы говорите про высокий уровень разработки в современном мире? Скорее он перегружен процессами вокруг, а багов стало только больше. Фреймворки генерят что-то под капотом, создавая мусорный код, а разраб не знает, как работает ORM и дергает в цикле атрибут БД.
Пример про баг в три строчки: когда убрали
WITH NOLOCK, который кто-то когда-то добавил. Халтура это была или оправданный хинт на тот момент - неизвестно. Но он был. А человек уже давно не работает. В какой-то момент это выстрелило. Оказалось, что он где-то внутри вложенного запроса в хранимке, которая вызывается только в одном месте раз в квартал. И это то, о чем вы говорите:Это не значит, что так не бывает.
Пример оправданной оптимизации:
Чтобы в наше время кто-то действительно этим занимался... В современном мире мне назвать такой пример сложно. Это скорее исключение. Потому что сторипоинты показывают, что проще докупить еще мощностей в ЦОД. Проще послать пользователя подальше, и сказать, что у него старый телефон, чем заниматься оптимизацией. Это реальность. Куча багованого софта, который никто никогда не будет исправлять, потому что якобы всего одна жалоба за все время, а не мажор. Зато там все покрыто автотестами.
Вы пользуетесь оперой? У нас же явно сказано, что мы гарантируем только хром.
Разве не так выглядит реальность? Но это уже очень большое отступление от темы статьи.
Повторюсь, мне непонятен контекст разговора. Что мы обсуждаем?
PS. Статья не предлагает менять подход к разработке. Статья лишь предлагает попробовать оценить когнитивные затраты.
Конечно 3 строчки это багфикс/оптимизация или доработка. Разве где-то речь шла о том, что это новая фича?
О каком 2005 и дизассемблере вы говорите? Я вам приведу десятки примеров, как в современных архитектурах не могли починить месяцами плавающий баг авторизации из-за куков. Выделяли каждый спринт несколько часов. Каждый новый решатель говорил, что предыдущий балбес, а я вот точно знаю где искать. Но обломали зубы. Баг так и живет.
Зачем отчитываться? Но вы сами говорите про эстимейты. Зачем тогда они? Тикет закрыт, результат есть и ладно. Зачем эстимейты? Для отчетности. Для планирования. Для оценки. Для приоритетов. Бизнес хочет знать, сколько ему это будет стоить до начала, сколько это реально стоило и насколько действительно задача сложная. Но это все суррогат, потому что измеряет теплое в килограммах.
Кто ставит эти эстимейты? Люди. На основании чего? Субъективной оценки: я угадаю эту мелодию с трех нот. Если речь идет о разработке с нуля или линейных изменениях, типа покрасить кнопочку, тогда да, можно оценить трудозатраты. Дизайн есть? АПИ есть? Тогда 10 минут.
Но если ставится задача починить баг или оптимизировать какой-то кусок в легаси. Какая здесь может быть оценка? Это пальцем в небо. Я оптимизирую этот запрос из 500 строк за 2 часа. Что? Как можно дать такую оценку не зная причины тормозов? Там может быть все что угодно, от конфигов до блокировок и умирающих дисков.
А если кто-то скажет месяц, но починит за час, нужно ли здесь поинтересоваться, кто был настолько пессимистичен и как избежать этого в будущем? А может кто-то справился бы за полчаса. Нужно ли передать такого типа задачи тому, кто справился бы за полчаса?
Здесь уже оценка скорее сводится тому, насколько эта починка необходима. Некий верхний порог, типа если за 2 дня не удастся разобраться - откладываем на неопределенный срок.
Все, что описано в статье, это про то, почему на задачу было потрачено Х часов. Действительно человек ей занимался или просто сказал что она сложная, а сам развлекался неделю, даже не прикасаясь к ней. После сорванных сроков попросил еще времени. Суррогатные метрики обесценивают труд одних, но необоснованно поднимая стоимость других.
Я вам расскажу историю из студенческих лет.
Подрабатывал я в автосервисе электриком. Однажды состоятельный клиент привез старый УАЗик, чтобы подготовить его для охоты. Он не скупился на запчасти. Там поменяли КПП, половину мотора и прочего. Одной из задач было установить туда новое электрооборудование: стеклоочиститель, новые фары, вывести управление светом на подрулевой переключатель и прочее. Как вы знаете, в старом УАЗике подрулевой только один, управляющий поворотниками. Был куплен новый руль от волги, торпеда, подрулевые, двигатель дворников с несколькими скоростями и программируемым интервалом. Осталось дело за малым - подключить это все.
Я 2 недели приходил по вечерам, прозванивал, обжимал клеммы, плел новые жгуты из проводов, каждый провод был с биркой и подписан. Никакой изоленты. Схему нарисовал.
Знаете, как руководство сервиса оценило мою работу? Они взяли нормачасы из официальной книжки автоваза.
Замена подрулевого (с/у) 10 минут.
Замена кнопки габаритов (с/у) 3 минуты.
Замена реле стеклоочистителя (с/у) 1 минута.
И т.д.
Получите 300р.
Якобы это я такой медленный, раз делал так долго. Вон, в книжке все давно рассчитано и клиента они возьмут по книжке. (конечно они все понимали, просто не хотели мне платить 30%, как изначально договорились)
(с УАЗика они взяли за эту работу 5000р, а 95 бензин тогда стоил 17р)
Так какой тут должен был быть эстимейт? По книжке ~30 минут.
Не знаю, где вы увидели здесь кнут. Идея была обратная, призванная показать, что 2 строки кода могут даваться очень непросто, в то время, как кнут требует отчитаться, куда ты потратил 2 недели.
Я не знаю где вы увидели агитацию все бросить и ничего не делать.
Статья:
показывает ограничения, о которых мы сейчас говорим
в связи с этими ограничениями призывает использовать LLM с осторожностью и внимательно проверять
предостерегает от бездумного использования и показывает к чему это может привести
Больше в статье ничего нет.
Разве в этом нет рационального зерна?
Но почему-то у некоторых триггернуло, будто я какой-то ретроград и предлагаю вернуться к калькуляторам.
С этим я абсолютно согласен и регулярно использую модели с этой целью. Иногда она складывает комбинацию, позволяющую взглянуть на вопрос под другим углом. Или выделить паттерн в твоем тексте, о котором ты сам не догадывался.
Но в этом и основное отличие от создания нового.
Человек по сути делает то же самое в физическом мире. Он ходит по одной и той же тропинке каждый день на работу. Ничего необычного. И тут бах - вспышка. Что-то сложилось в голове и ты заметил какую-то закономерность. Ты ее не придумал, она была, но ты ее заметил и облек в некую формулировку. Это тот самый новый мост, о котором вы говорите.
Но модель этого сделать не может. Не потому что она плохая, а потому что она не присутствует в физическом мире. Она не может кожей понять в чем разница между холодом и жаром и при чем здесь теплые варежки. Значит, ее мостики фундаментально ограничены.
Вы видите сны, которые нельзя нарисовать на бумаге, потому что это будет совсем не то, что вы видели. Сны не укладываются в модель 3х мерного мира. А сны или ощущения от пролитого кипятка на руку — это переживания, которые и способствуют построению новых мостиков.
В этом смысле человек тоже не творит ничего нового. Все это уже есть, а наш опыт позволяет это связать воедино. Закон тяготения был, Ньютон его не создавал, но он построил мостик и рассказал об этом миру.
Вот интересно, если модель обучать разным текстам, но целенаправленно выпилить оттуда все упоминания про Ньютона и закон, она сможет помочь найти этот мостик в стихах Шекспира и описании полета птиц (в общем, на основании того, что было известно в те времена)?
Да, согласен, такие валенки подходят для рукавиц с указательным пальцем для спускового крючка. Для "дитмароза" самое оно. Тогда все сходится.
Скрытый текст
В этой метафоре я сознательно избегал таких "страшных" слов, как аппроксимация, авторегрессия, градиентный спуск и обратное распространение ошибки)))
Но там это все есть в виде процесса
Отсюда и берутся темнокожие Белоснежки.
А еще вы уже потратили время на уточнение запроса, чтобы добиться результата, но его так и нет. Валенки имеют несколько другой вид, нежели сапоги, покрытые то ли мехом то ли войлоком.
То, что у него на ногах, больше похоже на унты/торбаса, но никак не на валенки
Валенки
Я же говорил изначально, что бессмысленно мучить калейдоскоп, в котором нет нужных бусинок. Их там просто нет. В обучающей базе были десятки тысяч сапог и только 10 валенок. Его будет перекашивать в сторону сапог постоянно.
Вы не понимаете, это другое)
Ваш вариант имеет сильный скандинавский оттенок, особенно шеврон на шапке, подчеркнутые усы, которые именно как усы, а не часть бороды, кожаные сапоги
И это нормально, это перекос, о котором я говорил
И вот в этом вашем "мало чем отличаются" кроется весь подвох
Ожидание
Реальность
Никаких валенок нет, есть нечто похожее на сапоги
По вашей логике код в 3 строки мало чем отличается от кода в 4 строки
Но эта одна строка может быть важным условием
Это вы знаете тонкости определений))
А простые люди в этом не разбираются. Когнитивный диссонанс из-за маркетингового названия сделал свое дело. После GPT уже целые профессии безопасников появились, призванных не выпустить ИИ из под контроля, а то еще захватят землю и поработят человечество.
Отсюда же все идет. Поэтому бизнес бежит за этими ИИ, как зомби.
Версия про стохастического попугая или умный Т9 вам нравится больше?