"90% времени работы, которое уходило на поиск литературы, я делегировал гуглу. Как же это аморально, но так приятно, это исторический момент, учёные больше не нужны, закрываем лаборатории!"
Среднестатистический хороший джун из промышленной разработки напишет код (именно как код) лучше среднестатистического великолепного научного работника.
И поэтому я вполне верю что ИИ пишет код лучше чем 99% профессоров. Планка очень низкая.
ИИ наверняка и астрофизику знает лучше, чем 99 процентов программистов. И что дальше?
Утверждение, что ИИ делает лучше то, чему кто-то там посвятил всю свою жизнь, звучит вообще смешно. Или не особо этот кто-то себя и посвятил, или его работа не включает в себя создание чего то нового вообще.
Вот они-то как раз не поехавшие, а сознательно разгоняющие волну. Задача производителей железа - продать как можно больше железа. Кому - все равно.
А так да, поддерживаю, горить им в аду. Столько ресурсов летит в трубу. Было бы интересно посмотреть статистику выполняемых запросов к llm, и какая часть из них хоть как-то полезна.
Небольшая даже не замечание, а фантазия по поводу mySleep - надо понимать, что точность её будет крайне сильно зависеть от того, в каком порядке будут шедулиться нити и насколько хорошо они избавлены от блокирующих вызовов.
В примере шедулер перебирает нити последовательно. Можно пофантазировать и реализовать mySleep с выставлением времени оставшегося ожидания в описатель нити. И например обрабатывать это ожидание на уровне самого шедулера, а не после переключения в контекст нити. Вообще на неё не переключаться например. Или запускать её с большим приоритетом по истечении таймаута.
Хотя понятно, что в любом случае многозадачность тут кооперативная и зависшая нить не позволит шедулиться никому.
По годовой статистике не совсем согласен. Это зависит от проекта, может у вас и правда так. Но часто видел, что на сложных проектах разные части системы поддерживаются разными разработчиками. И, соответственно, и баги у них отличаются по сложности этих частей. Если система однородная, то, может, и выровняется.
Про ручной труд - у меня сложилось впечатление, что в предложенном подходе его не сильно меньше, чем при обычной оценке по дейликам и списанному времени. А где ручной труд, там и субъективизм. Просто тут он более "гранулярный", что ли.
В конечном то счете смысл всех оценок должен быть в оценке импакта на бизнес, а не на количество кода или строк документации.
Короче - время покажет. Наверняка же вы дорабатывать и корректировать что-то будете в этой схеме. Интересно, к чему придёте.
"если человек приходит на работу, значит он скорее всего что-то делает"
Это утверждение не просто спорное, оно ложное. То что человек приходит на работу значит только то что он сидит на стуле на территории работодателя. Больше ничего.
"вряд ли работа одного и того же разработчика будет состоять только из фикса багов повышенной сложности"
Если ваш коллектив не состоит из одинаковых клонированных сотрудников - перекос по сложности решаемых багов будет обязательно.
"В данном случае можно периодически проводить ревью созданных страниц"
"Ответ – не пропускать такие mr на ревью."
То есть система, предназначенная для упрощения и автоматизации оценки производительности сотрудников требует ручной работы и микроменеджмента.
Выглядит так, что это все применимо только на эталонной галере в вакууме с обезличенными сотрудниками. Откуда там мотивация у сотрудников "не пропускать на ревью" такие мр-ы - не понятно.
У меня сложилось впечатление, что у автора либо очень узкий опыт по типам компаний, либо малый опыт управления командой. Обычно такое и приводит к поиску "волшебной спасительной формулы". Может, вам стоит посмотреть в сторону разбиения команды на подгруппы с ответственными за эти подгруппы, а не пытаться охватить в одного всё с использованием сомнительных формул?
С мукой или без муки?
Окончательно дропнул опрос на этом пункте. Никак не влияет.
Такое ощущение что опрос ИИ и составлял, причём плохой. Потраченного времени жаль.
"90% времени работы, которое уходило на поиск литературы, я делегировал гуглу. Как же это аморально, но так приятно, это исторический момент, учёные больше не нужны, закрываем лаборатории!"
Среднестатистический хороший джун из промышленной разработки напишет код (именно как код) лучше среднестатистического великолепного научного работника.
И поэтому я вполне верю что ИИ пишет код лучше чем 99% профессоров. Планка очень низкая.
ИИ наверняка и астрофизику знает лучше, чем 99 процентов программистов. И что дальше?
Утверждение, что ИИ делает лучше то, чему кто-то там посвятил всю свою жизнь, звучит вообще смешно. Или не особо этот кто-то себя и посвятил, или его работа не включает в себя создание чего то нового вообще.
Вот они-то как раз не поехавшие, а сознательно разгоняющие волну. Задача производителей железа - продать как можно больше железа. Кому - все равно.
А так да, поддерживаю, горить им в аду. Столько ресурсов летит в трубу. Было бы интересно посмотреть статистику выполняемых запросов к llm, и какая часть из них хоть как-то полезна.
Спасибо за отличную статью!
Небольшая даже не замечание, а фантазия по поводу mySleep - надо понимать, что точность её будет крайне сильно зависеть от того, в каком порядке будут шедулиться нити и насколько хорошо они избавлены от блокирующих вызовов.
В примере шедулер перебирает нити последовательно. Можно пофантазировать и реализовать mySleep с выставлением времени оставшегося ожидания в описатель нити. И например обрабатывать это ожидание на уровне самого шедулера, а не после переключения в контекст нити. Вообще на неё не переключаться например. Или запускать её с большим приоритетом по истечении таймаута.
Хотя понятно, что в любом случае многозадачность тут кооперативная и зависшая нить не позволит шедулиться никому.
По годовой статистике не совсем согласен. Это зависит от проекта, может у вас и правда так. Но часто видел, что на сложных проектах разные части системы поддерживаются разными разработчиками. И, соответственно, и баги у них отличаются по сложности этих частей. Если система однородная, то, может, и выровняется.
Про ручной труд - у меня сложилось впечатление, что в предложенном подходе его не сильно меньше, чем при обычной оценке по дейликам и списанному времени. А где ручной труд, там и субъективизм. Просто тут он более "гранулярный", что ли.
В конечном то счете смысл всех оценок должен быть в оценке импакта на бизнес, а не на количество кода или строк документации.
Короче - время покажет. Наверняка же вы дорабатывать и корректировать что-то будете в этой схеме. Интересно, к чему придёте.
"если человек приходит на работу, значит он скорее всего что-то делает"
Это утверждение не просто спорное, оно ложное. То что человек приходит на работу значит только то что он сидит на стуле на территории работодателя. Больше ничего.
"вряд ли работа одного и того же разработчика будет состоять только из фикса багов повышенной сложности"
Если ваш коллектив не состоит из одинаковых клонированных сотрудников - перекос по сложности решаемых багов будет обязательно.
"В данном случае можно периодически проводить ревью созданных страниц"
"Ответ – не пропускать такие mr на ревью."
То есть система, предназначенная для упрощения и автоматизации оценки производительности сотрудников требует ручной работы и микроменеджмента.
Выглядит так, что это все применимо только на эталонной галере в вакууме с обезличенными сотрудниками. Откуда там мотивация у сотрудников "не пропускать на ревью" такие мр-ы - не понятно.
У меня сложилось впечатление, что у автора либо очень узкий опыт по типам компаний, либо малый опыт управления командой. Обычно такое и приводит к поиску "волшебной спасительной формулы". Может, вам стоит посмотреть в сторону разбиения команды на подгруппы с ответственными за эти подгруппы, а не пытаться охватить в одного всё с использованием сомнительных формул?