Адрес для входа в РФ: exler.world
Программеры филонят
27.11.2024 11:42
5850
Комментарии (175)
Исследователи из Стэнфордского университета создали модель, которая количественно оценила работоспособность более 50 тысяч разработчиков программного обеспечения из сотен крупных IT-компаний, проанализировав исходный код из закрытых репозиториев Git.
Результат меня прям удивил. Оказывается, только 14% инженеров-программистов, работающих удаленно, ни хрена не делают. Я был уверен, что их заметно больше. Также исследователи выяснили, что 9% работающих одновременно удаленно и в офисе ни черта не делают, а в офисе ни черта не делают 6%.
Мой опыт показывает, что этот процент - прям очень заметно выше. Так что у них явно что-то с методологией.
Оказалось, 14% инженеров-программистов, работающих удаленно, практически не выполняли никакой работы, то же самое касается 9% трудящихся одновременно удаленно и в офисе, а также 6% работающих в офисе постоянно. В среднем этот показатель составляет 9,5%.
Подсчет коммитов (способ сохранения изменений в коде, содержащий информацию о том, что было изменено и кем были внесены эти изменения) кода выявил, что примерно 58% сотрудников делают менее трех коммитов в месяц. Остальные 42% вносят тривиальные изменения: например, редактируют одну строку или символ, делая вид, что работают. (Отсюда.)
Войдите, чтобы оставить комментарий.
кому интересно, подробности на русском.
про удаленку еще вот такой результат получился:
про удаленку еще вот такой результат получился:
Также исследование не дает однозначного ответа на вопрос, насколько эффективно возвращение сотрудников в офисы после нескольких лет удаленной работы. А именно в этом сейчас заинтересованы многие компании. Исследование показало, что больше всего эффективных разработчиков работают удаленно, уточняет Business Insider. Производительность некоторых из них в пять раз превышает медианные показатели их коллег.
Не понимаю, что за странная идея оценивать работу программиста по коммитам?
У среднего программиста есть множество другой важной работы. Принимать участие в митингах, вносить предложения по улучшению работы, тестировать, запускать что-то, отвечать на вопросы сослуживцев, писать планы, искать причину проблем, проверять коммиты других, и много чего ещё.
У среднего программиста есть множество другой важной работы. Принимать участие в митингах, вносить предложения по улучшению работы, тестировать, запускать что-то, отвечать на вопросы сослуживцев, писать планы, искать причину проблем, проверять коммиты других, и много чего ещё.
Software metric
Common software measurements include:
ABC Software Metric
Balanced scorecard
Bugs per line of code
Code coverage
Cohesion
Comment density[3]
Connascent software components
Constructive Cost Model
Coupling
Cyclomatic complexity (McCabe's complexity)
Cyclomatic complexity density[4][5]
Defect density - defects found in a component
Defect potential - expected number of defects in a particular component
Defect removal rate
DSQI (design structure quality index)
Function Points and Automated Function Points, an Object Management Group standard[6]
Halstead Complexity
Instruction path length
Maintainability index
Source lines of code - number of lines of code
Program execution time
Program load time
Program size (binary)
Weighted Micro Function Points
Cycle time (software)
First pass yield
Corrective Commit Probability[7]
.......
Как вовремя я это все безобразие бросил.
Common software measurements include:
ABC Software Metric
Balanced scorecard
Bugs per line of code
Code coverage
Cohesion
Comment density[3]
Connascent software components
Constructive Cost Model
Coupling
Cyclomatic complexity (McCabe's complexity)
Cyclomatic complexity density[4][5]
Defect density - defects found in a component
Defect potential - expected number of defects in a particular component
Defect removal rate
DSQI (design structure quality index)
Function Points and Automated Function Points, an Object Management Group standard[6]
Halstead Complexity
Instruction path length
Maintainability index
Source lines of code - number of lines of code
Program execution time
Program load time
Program size (binary)
Weighted Micro Function Points
Cycle time (software)
First pass yield
Corrective Commit Probability[7]
.......
Как вовремя я это все безобразие бросил.
Так оно и есть! 😄
Самый верхний кусочек кода на С. А дальше уже ребята из Бангалора переписали на жабе 😄
Покрыть тестами, завернуть в микросервис и в кубернетес на кластер.
cond засылать эвентом через Кафку. Результат писать в hdfs.
Вот тогда норм.
А так нещитово, любительщина какая-то.
PS: Кстати, во времена молодого Билла Гейтса Жабы, которая на картинке, даже в проекте не было.
Зануда-моде-офф 😄
cond засылать эвентом через Кафку. Результат писать в hdfs.
Вот тогда норм.
А так нещитово, любительщина какая-то.
PS: Кстати, во времена молодого Билла Гейтса Жабы, которая на картинке, даже в проекте не было.
Зануда-моде-офф 😄
Светлая мечта всей ваты - "Чтобы эти умники на нас работали. За пайку."
У меня был коллега и я никогда не мог понять, как он работает. Мы сидели в соседних кубиклах, слышали друг друга, и оба делали примерно одну и ту же работу в тот момент. Он отвечал за streamed FFT, я - за DFT для LTE. Оба блока примерно одинаковые по сложности. И я слышал, как он постоянно печатал что-то со скоростью машинистки, в то время, как я лениво елозил мышкой по экрану, добавляя по несколько строк, а то и символов, в минуту. Проходя мимо, я видел, что у него открыт редактор и он правда что-то всё время пишет на VHDL.
К моменту релиза библиотеки у нас было написано примерно одинаковое количество кода на VHDL за одно и то же время, при том, что он нажимал примерно раз в 100 больше меня на клавиши. До сих пор не знаю, как он писал - писал и тут же удалял? Комментировал всё, а потом удалял комментарии? В общем, для меня это осталось загадкой. Вполне возможно, для него мой способ работы - тоже.
Ещё один комментарий от другого коллеги, уже из другого проекта: "Когда садишься за компьютер, очень хочется не думать, а сразу что-то печатать." Возможно, здесь ключ к разгадке?
К моменту релиза библиотеки у нас было написано примерно одинаковое количество кода на VHDL за одно и то же время, при том, что он нажимал примерно раз в 100 больше меня на клавиши. До сих пор не знаю, как он писал - писал и тут же удалял? Комментировал всё, а потом удалял комментарии? В общем, для меня это осталось загадкой. Вполне возможно, для него мой способ работы - тоже.
Ещё один комментарий от другого коллеги, уже из другого проекта: "Когда садишься за компьютер, очень хочется не думать, а сразу что-то печатать." Возможно, здесь ключ к разгадке?
он нажимал примерно раз в 100 больше меня на клавиши
Можно фигачить говнокод и потом рефачить. Мне иногда так проще думается, чем заранее представить и продумать, иногда буксуешь. А тут вот уже перед глазами что-то работающее, но плохое, и понятно, как это привести в чувство.
О, я видел таких деятелей, которые оценивали работу программистов по коммитам в неделю. Хорошо, что я с ними почти никогда в жизни не имел дела. (один раз имел, 3 месяца, несколько лет назад - мне хватило).
Интересно, а как бы они оценивали работу хардверщиков - по количеству припаянных микросхем?
Интересно, а как бы они оценивали работу хардверщиков - по количеству припаянных микросхем?
Интересно, а как бы они оценивали работу хардверщиков - по количеству припаянных микросхем?
Чота я похоже перерабатьіваю
Про подсчет продуктивности по строкам кода:
folklore.org
folklore.org
что примерно 58% сотрудников делают менее трех коммитов в месяц. Остальные 42% вносят тривиальные изменения: например, редактируют одну строку или символ, делая вид, что
Офигеть, если честно. У меня за вчера где-то коммитов 20. Около тысячи строчек кода + несколько тысяч строк мок-данных.
Коммитов двадцать - это потому самому было лень код запускать, и тестировал на CI, а оно всё падало и падало?
У меня есть уникумы, которые коммитят, не проверяя даже на уровне "компилится оно или нет". Зато дешёвые, что руководство и ценит.
Коммитов двадцать - это потому самому было лень код запускать, и тестировал на CI, а оно всё падало и падало?
Ну, осуждаю, но бывает. Хоть засквошил потом?
Ну, осуждаю, но бывает. Хоть засквошил потом?
Заменил все табы на пробелы? Так и миллион строк кода можно за раз поменять.
Не воспримите за наезд, но в какой это области в день 1000 строк кода?
У меня за вчера где-то коммитов 20. Около тысячи строчек кода + несколько тысяч строк мок-данных.
Не воспримите за наезд, но в какой это области в день 1000 строк кода?
А потом вы будете спрашивать, почему софт превращается в дерьмо...
Тысяча строк кода в день. 125 строк в час, две строки в минуту. Чуваку думать некогда, он код педалит.
Несколько тысяч строк мок-данных. Ну тут ваще. Мало того, что мок, за который в приличных фирмах стреляют в голову, так еще и несколько тысяч.
Короче, у него еще, жена - модель, яхта океанского класса и три приватных джета
Тысяча строк кода в день. 125 строк в час, две строки в минуту. Чуваку думать некогда, он код педалит.
Несколько тысяч строк мок-данных. Ну тут ваще. Мало того, что мок, за который в приличных фирмах стреляют в голову, так еще и несколько тысяч.
Короче, у него еще, жена - модель, яхта океанского класса и три приватных джета
только 14% инженеров-программистов, работающих удаленно, ни хрена не делают. Я был уверен, что их заметно больше. Также исследователи выяснили, что 9% работающих одновременно удаленно и в офисе ни черта не делают, а в офисе ни черта не делают 6%.
Остальные — умные. Один раз автоматизировал удаление/добавление всех точек с запятой в питоновом коде, и каждый день кроном запускаешь. Можно хоть каждый час.
Остальные 42% вносят тривиальные изменения: например, редактируют одну строку или символ, делая вид, что работают.
Из человеколюбия.
Его ж разорвёт в бане из-за такой темы.
Его ж разорвёт в бане
Его ж разорвёт в бане
Free Pafnustain!
Присоединяюсь к петиции! Хлеба и зрелищ!
из сотен крупных IT-компаний, проанализировав исходный код из закрытых репозиториев Git
Если из метаданных можно наковырять количество и объем коммитов с привязкой к организации, то это закрытость уровня "а в этом женском туалете у нас стены нет, пойдёмте дальше".
Может метаданные получили?
а как они задачи закривают?
бред какой-то...
бред какой-то...
а, то есть туда в таску - релиз можно не прикреплять?
а я не знал...
а я не знал...
а как они задачи закривают?
Проверил, из моих 15 разрабов коммитили все за последний месяц (тьфу-тьфу, постучим по дереву)
которая количественно оценила работоспособность более 50 тысяч разработчиков программного обеспечения из сотен крупных IT-компаний, проанализировав исходный код из закрытых репозиториев Git.
А те аж бегом побегли открывать доступ незнамо кому, к своим сорцам, да. 😄"Закрытые репозитории" не просто так же закрыты.
Секретное за физический пределы офиса не должно попадать.
С согласия этих компаний?
"Закрытые репозитории" не просто так же закрыты.
Каким макаром какие-то там сторонние исследователи получили доступ к закрытым репам "сотен крупных IT-компаний"?
Пойду сделаю пару коммитов. И проверю почту заодно
Вот прямо сейчас у меня идёт третий день попыток заставить работать одну функцию, которая в идеальной среде укладывается в две строки кода. А под CMS - не работает, собака женского пола.
Вот я вокруг этих двух строк разные варианты и пробую. По мнению исследователей из Стэнфордского университета я - бездельник?
Вот я вокруг этих двух строк разные варианты и пробую. По мнению исследователей из Стэнфордского университета я - бездельник?
За простыни кода нужно карать.
К сожалению, с менеджерами я знаком лучше, чем с творчеством "индусов". Так что верю 😄
Когда последний раз писал курсовую (1984 год) преподаватель задал вопрос "почему вы используете простой перебор со сравнением, а не циклы?"
Я сказал что-то вроде "потому что так заработало с первого раза, а у коллеги, с его циклами, нет".
Я сказал что-то вроде "потому что так заработало с первого раза, а у коллеги, с его циклами, нет".
Потому индусы и пишут простыни кода, что оценивают их безмозглые менеджеры.
Ну, если исследователи из Стэнфордского университета меряют работоспособность "индусскими" параметрами, то конечно, они же ученые.
Вот если ты стучишь по клаве со скоростю света и комитишь как не в себя, то ты значит продуктивный работник. "Но в основном фигня какая-то получается" (с) анекдот
Вот если ты стучишь по клаве со скоростю света и комитишь как не в себя, то ты значит продуктивный работник. "Но в основном фигня какая-то получается" (с) анекдот
Я один раз прикололся. Написал программку, которая перехватывает нажатия клавиш и вместо них впендюривает свои. Включил, когда докладывал об успехах своей команды, и притворился, что гугль-докс съел заранее подготовленную презентацию, и что я её вот прям щаз набью заново. После чего молотил по клавишам, ни разу не коснувшись пробела.
Обожаю фильмы про хакеров, которые с огромной скоростью клавиатурят.
А на экране ползут красивые строчки комментариев...
А на экране ползут красивые строчки комментариев...
Дело началось проще. До меня наш производственный процесс выглядел следующим образом: с утра мы садились и играли в сику, на деньги (вы умеете играть в сику?). Так. Потом вставали, разматывали барабан с кабелем и кабель укладывали под землю. А потом – известное дело: садились, и каждый по-своему убивал свой досуг, ведь все-таки у каждого своя мечта и свой темперамент: один – вермут пил, другой, кто попроще – одеколон «Свежесть», а кто с претензией – пил коньяк в международном аэропорту Шереметьево. И ложились спать.
А наутро так: садились и пили вермут. Потом вставали и вчерашний кабель вытаскивали из-под земли и выбрасывали, потому что он уже весь мокрый был, конечно. А потом – что же? – потом садились играть в сику, на деньги. Так и ложились спать, не доиграв.
Рано утром уже будили друг друга: «Лёха! Вставай в сику играть!» «Стасик, вставай доигрывать вчерашнюю сику!» Вставали, доигрывали в сику. А потом – ни свет, ни заря, ни «Свежести» не попив, ни вермуту, хватали барабан с кабелем и начинали его разматывать, чтоб он до завтра отмок и пришел в негодность. А потом – каждый за свой досуг, потому что у каждого свои идеалы. И так все сначала.
Став бригадиром, я упростил этот процесс до мыслимого предела. Теперь мы делали вот как: один день играли в сику, другой – пили вермут, на третий день – опять в сику, на четвертый – опять вермут. А тот, кто с интеллектом, – тот и вовсе пропал в аэропорту Шереметьево: сидел и коньяк пил. Барабан мы, конечно, и пальцем не трогали, – да если б я и предложил барабан тронуть, они все рассмеялись бы, как боги, потом били бы меня кулаками по лицу, ну а потом разошлись бы: кто в сику играть, на деньги, кто вермут пить, а кто «Свежесть».
А наутро так: садились и пили вермут. Потом вставали и вчерашний кабель вытаскивали из-под земли и выбрасывали, потому что он уже весь мокрый был, конечно. А потом – что же? – потом садились играть в сику, на деньги. Так и ложились спать, не доиграв.
Рано утром уже будили друг друга: «Лёха! Вставай в сику играть!» «Стасик, вставай доигрывать вчерашнюю сику!» Вставали, доигрывали в сику. А потом – ни свет, ни заря, ни «Свежести» не попив, ни вермуту, хватали барабан с кабелем и начинали его разматывать, чтоб он до завтра отмок и пришел в негодность. А потом – каждый за свой досуг, потому что у каждого свои идеалы. И так все сначала.
Став бригадиром, я упростил этот процесс до мыслимого предела. Теперь мы делали вот как: один день играли в сику, другой – пили вермут, на третий день – опять в сику, на четвертый – опять вермут. А тот, кто с интеллектом, – тот и вовсе пропал в аэропорту Шереметьево: сидел и коньяк пил. Барабан мы, конечно, и пальцем не трогали, – да если б я и предложил барабан тронуть, они все рассмеялись бы, как боги, потом били бы меня кулаками по лицу, ну а потом разошлись бы: кто в сику играть, на деньги, кто вермут пить, а кто «Свежесть».
Москва—Петушки
Поэма
На предыдущем проекте в огромной и очень кривой системе от HP не раз бывало, что приходится 1-2 дня поискать, где всё же ошибка, а потом парой строк исправить. Или исправляешь по нормальному системную функцию, а потом весело ищешь и правишь в миллионе мест, где она использовалась... И это всё занимает время, хотя и не очень много - но за неделю ты сделал всего 1 задачу с 1 коммитом, в котором несколько десятков строк...
Я как то пару дней потратил чтоб найти и отредактировать одну строку, более того один символ.
И иногда это пробел 😺
И иногда это пробел 😺
Или вообще находишь и чинишь с помощью созвонов и емейлов без коммитов ))
Или наоборот - находится быстро, символов для правки много, но времени занимает дофигища, с учетом тестирования.
А коммит один.
А коммит один.
Остальные 42% вносят тривиальные изменения: например, редактируют одну строку или символ, делая вид, что работают.
Я пишу, но комичу локально в основном. А пушу время от времени, когда уже почти всё готово. Если какая-то большая задача, которая делается неделю-две - то на сервере комитов не будет, но это не значит, что работа не идёт.
Те же джуны часто переделывают по 5 раз одно и тоже - и там в день просто куча коммитов. Вот они, получается, супер работники...
У нас просто есть план на квартал и он разбивается на спринты. Ставятся задачи в спринты - если выполняешь, то всё отлично. И неважно сколько там коммитов/строк кода/времени - хочешь ночью работай а днём на паре созвонов побудь (время созвонов, кстати, в тайм трекере не учитывается... Надо его раскидывать на задачи), и занимайся своими делами, если тебе так удобно.
Те же джуны часто переделывают по 5 раз одно и тоже - и там в день просто куча коммитов. Вот они, получается, супер работники...
У нас просто есть план на квартал и он разбивается на спринты. Ставятся задачи в спринты - если выполняешь, то всё отлично. И неважно сколько там коммитов/строк кода/времени - хочешь ночью работай а днём на паре созвонов побудь (время созвонов, кстати, в тайм трекере не учитывается... Надо его раскидывать на задачи), и занимайся своими делами, если тебе так удобно.
planning, retrospectives, etc
A Nightmare… IMO
«Обычно» рабочий день 6.5 часов на sprint tasks, остальное время на standups, planning, retrospectives, etc. При этом не нужно «раскидывать» ceremonies на задачи.
«Обычно» рабочий день 6.5 часов на sprint tasks, остальное время на standups, planning, retrospectives, etc. При этом не нужно «раскидывать» ceremonies на задачи.
Когда разрабов мало, и каждый делает строго свою задачу, то там не сильно принципиально. Как один из вариантов бэкапа - согласен, но одна ветка не всегда критично + бэкапы локально делаются
Если какая-то большая задача, которая делается неделю-две - то на сервере комитов не будет, но это не значит, что работа не идёт.
Я не программист, и мало в этом понимаю. Но меня всегда удивляло вот что.
Вот выходит новая версия программы или даже ОС, или новая игра - и делали все это туеву хучу лет, и там багов как блох на бродячей собаке. Ну как так?
Более того, как правило аддоны почти всегда делают нормально работающую программу хуже, чем она была.
Что это?
И такая шняга стала нормой лет 20 как.
Если бы в моей сфере деятельности народ (включая меня) так работал, то после второй, а иногда и первой ошибки вылетел бы с места впереди собственного визга. А тут компании и их сотрудники десятилетиями косячат, и хоть бы хны.
Ты выпускаешь продукт. Работаешь несколько лет. У тебя есть возможность бета-тестинга. И все равно выпускаешь говно, которое потом приходится ещё пару лет допиливать.
Так может, просто этих программистов развелось слишком много? Похоже как минимум половину можно тупо заменить ИИ, и никто не заметит. Будет по прежнему выходит недоделанное говно, потому что ИИ создают и программируют те же самые долбоклюи.
Вот выходит новая версия программы или даже ОС, или новая игра - и делали все это туеву хучу лет, и там багов как блох на бродячей собаке. Ну как так?
Более того, как правило аддоны почти всегда делают нормально работающую программу хуже, чем она была.
Что это?
И такая шняга стала нормой лет 20 как.
Если бы в моей сфере деятельности народ (включая меня) так работал, то после второй, а иногда и первой ошибки вылетел бы с места впереди собственного визга. А тут компании и их сотрудники десятилетиями косячат, и хоть бы хны.
Ты выпускаешь продукт. Работаешь несколько лет. У тебя есть возможность бета-тестинга. И все равно выпускаешь говно, которое потом приходится ещё пару лет допиливать.
Так может, просто этих программистов развелось слишком много? Похоже как минимум половину можно тупо заменить ИИ, и никто не заметит. Будет по прежнему выходит недоделанное говно, потому что ИИ создают и программируют те же самые долбоклюи.
Потому что бета-тестинг это вчерашний день. Крупные разработчики давно его сократили и выкатывают сразу на прод. Клиентов больше, чем бетатестеров, баги отловятся быстрее. А лицензионное соглашение все равно снимает с производителя всякую ответственность за последствия.
Бизнес причины Софт релизят с багами вполне сознательно.
IYKWIM
Все-таки это не сознательно выпускают с багами, только может minor или UI, когда понимают что не успевают фикснуть или боятся регрешион,
А за крупные баги очень даже по шапке дают
А за крупные баги очень даже по шапке дают
Зачем?
Но могу успокоить - ошибки всегда разбиваются по уровню критичности для конечного пользователя. Если где-то на сайте стиль, например, поехал и какой-то текст поменял цвет или там съехал куда, скорее всего такой баг не будут экстренно фиксить, а запланируют в следующий релиз. Если пользователь не может пользоваться какой-либо важной функцией софта - то да, такое в релиз в нормальных конторах не выпустят. Или будет выпущен внеочередной патч уже после релиза.
Софт релизят с багами вполне сознательно.
Жизнь сложнее, чем теория. А принципе три-четыре момента мешают
"Если бы архитекторы строили дома так, как программисты пишут программы, то первый залетевший дятел разрушил бы цивилизацию."
(с) Какой-то из законов Мэрфи
(с) Какой-то из законов Мэрфи
Жизнь сложнее, чем теория. А принципе три-четыре момента мешают
Недостаточный уровень тестирования. Тестируют в принципе все, но уровень тестирования сильно отличается. К тому же правильно написанный код (автоматически) тестировать куда легче.
Говнокод Этим страдают почти все. Неправильно написанный код заставить работать корректно невозможно. Его нельзя нормально поддерживать.
Изменения в требованиях В процессе разработки вносятся изменения, которые вносят хаос на всех уровнях.
Бизнес причины Софт релизят с багами вполне сознательно.
Недостаточный уровень тестирования. Тестируют в принципе все, но уровень тестирования сильно отличается. К тому же правильно написанный код (автоматически) тестировать куда легче.
Говнокод Этим страдают почти все. Неправильно написанный код заставить работать корректно невозможно. Его нельзя нормально поддерживать.
Изменения в требованиях В процессе разработки вносятся изменения, которые вносят хаос на всех уровнях.
Бизнес причины Софт релизят с багами вполне сознательно.
авто отзывают его и либо меняют, либо отдают деньги обратно? Что-то не слышал, чтобы нечто подобное делали софтверные компании.
Я не программист, и мало в этом понимаю. Но меня всегда удивляло вот что. Вот выходит новая версия программы или даже ОС, или новая игра - и делали все это туеву хучу лет, и там багов как блох на бродячей собаке. Ну как так?Более того, как правило аддоны почти всегда делают нормально работающую программу хуже, чем она была. Что это? И такая шняга стала нормой лет 20 как.
Вот выходит новая версия программы или даже ОС, или новая игра - и делали все это туеву хучу лет, и там багов как блох на бродячей собаке. Ну как так?
В бар заходит тестировщик. Заказывает стакан пива. Заказывает два стакана пива. Заказывает миллион стаканов пива. Заказывает ноль стаканов пива. Заказывает минус один стакан пива. Заказывает полтора стакана пива. Заказывает ящерицу в стакане.
В бар заходит первый настоящий посетитель. Спрашивает, где туалет. Бар взрывается.
там багов как блох на бродячей собаке. Ну как так?
а вообще программирование нельзя сравнивать со всем остальним
єто чистое творчество причем абстрактное, мест где может поломаться уйма , все не предвидишь, чем сложнее программа тем больше багов
Что-то не слышал, чтобы нечто подобное делали софтверные компании.
Megathread: Sony/PlayStation will offer full refunds to those who have purchased Cyberpunk. - SIE will also be removing Cyberpunk 2077 from PlayStation Store until further notice.
> Почему компании, которые выпустили некачественный телефон или авто отзывают его и либо меняют, либо отдают деньги обратно? Что-то не слышал, чтобы нечто подобное делали софтверные компании.
Потому что софтверные компании могут выкатить апдейт, который вы можете даже не заметить.
Потому что софтверные компании могут выкатить апдейт, который вы можете даже не заметить.
Я утверждаю, что любая работа прежде всего оценивается по результатам. Право на ошибку, естественно, никто не отменял. Но если таких ошибок море? Причём практически каждый раз? Почему компании, которые выпустили некачественный телефон или авто отзывают его и либо меняют, либо отдают деньги обратно? Что-то не слышал, чтобы нечто подобное делали софтверные компании.
А вот если бы программисты сидели бы на сдельщине... Выпустили нормальный продукт, получили часть прибыли. Выпустили недоделанное говно, сосите хер. Может, тогда меньше говна бы выходило?
А вот если бы программисты сидели бы на сдельщине... Выпустили нормальный продукт, получили часть прибыли. Выпустили недоделанное говно, сосите хер. Может, тогда меньше говна бы выходило?
Ну так вы ж утверждаете, что ИИ плохой, потому что его созданием занимаются программисты, а программисты косячат. Логичный вывод, что созданием ИИ должны заниматься другие профессионалы, которые не косячат.
почему продукт делают несколько лет, проверяют, тестят, а потом после его реализа там куча багов
Разгадка проста: продукт создается людьми.
Подробнее: Законы ненадежности Джилба.
Так создайте нормальный ИИ, чего вы.
Возможно, изрядная часть программистов просто не профессионалы?
Вот объясните, почему продукт делают несколько лет, проверяют, тестят, а потом после его реализа там куча багов, которые, бывают даже гаджет кирпичат? Ой, ошибочка вышла...
Так создайте нормальный ИИ, чего вы.
Мой личный рекорд, примерно 80 строчек кода, 2 недели работы, и премия в размере месячного оклада. 😄
Ты заметил.
Это важно.
Для тебя же.
Это важно.
Для тебя же.
Мой личный рекорд за неделю работы - минус 900 строчек кода. Без какого-либо изменения функциональности модуля. 😄
Совсем недавно убрал штук сто строк из одного модуля.
Запрос, который выполнялся секунд двадцать, стал выполняться меньше, чем за секунду.
Да, мне было очень стыдно, поскольку эти сто строк писались тоже мной.
И знаете, что обидно? Абсолютно никто этого не заметил!
Мой личный рекорд за неделю работы - минус 900 строчек кода. Без какого-либо изменения функциональности модуля. 😄
Мой личный рекорд за неделю работы - минус 900 строчек кода. Без какого-либо изменения функциональности модуля. 😄
минус 900 строчек кода.
Гомо сапиенс."
Мой личный рекорд, примерно 80 строчек кода, 2 недели работы, и премия в размере месячного оклада. 😄
Остальные 42% вносят тривиальные изменения: например, редактируют одну строку или символ Это называется рефакторинг, так то)
Интересно, что мешает работать индийским программистам? Русскоязычные целый день срутся в интернете по украинскому вопросу. Уже лет двадцать как. А индусы? Кто знает ? Ведь не могут они на работе работать!
Именно. У меня сейчас такой пример рядом. У нас тут есть такое как contribution - ну что существенное сделал за год. Помните девушку-менеджера из IT Crowd с её:
I have skill in receiving emails, opening emails, reading emails, writing emails, sending emails...
Вот это тоже самое - он один контрибюшен разделил на 5 мелких шагов и каждый преподносит как отдельное достижение. И ничего, что мы этого уберспеца 6 месяцев ждали, пока он из Индии припрётся (ЕС бюрократия+индийская тоже), и что мы с коллегой его полгода настаскивали по таким вопросам, которые он, судя по его CV, должен был знать наизусть. Если бы от меня зависило - уволил бы нахрен. Специализд...
I have skill in receiving emails, opening emails, reading emails, writing emails, sending emails...
Вот это тоже самое - он один контрибюшен разделил на 5 мелких шагов и каждый преподносит как отдельное достижение. И ничего, что мы этого уберспеца 6 месяцев ждали, пока он из Индии припрётся (ЕС бюрократия+индийская тоже), и что мы с коллегой его полгода настаскивали по таким вопросам, которые он, судя по его CV, должен был знать наизусть. Если бы от меня зависило - уволил бы нахрен. Специализд...
Они очень хорошо умеют играть в корпоративные игры, представлять себя в наилущем свете.
Ох, прямо захотелось в библиотеку.
"Гюльчатай! Открой интерфейс."
Расисты все белые. Ибо не позволяют индусам на себе ездить (piggybacking)
Интересно, кто нибудь читал когда-то, что пишут индусы о русских программистах? 😄
Спросите у индусов как на***бать систему.
Многие страницы "как пройти собеседования в Гугле, Амазоне итд" в помощь.
Они очень хорошо умеют играть в корпоративные игры, представлять себя в наилущем свете.
Многие страницы "как пройти собеседования в Гугле, Амазоне итд" в помощь.
Они очень хорошо умеют играть в корпоративные игры, представлять себя в наилущем свете.
Уровень бюрократии и долбо...зма запредельный
Ютуб однажды подсунул канал одного капитана из торгового флота поведавшего как оно работать с индусами и на индусов. Это п-ц. Уровень бюрократии и долбо...зма запредельный даже по шкале расеянина
А они выясняют чей Кашмир 🤭!
Колониальное прошлое, свадьбы, рождение детей, приезды отьезды родителей и прочие дивали
проанализировав исходный код из закрытых репозиториев Git
Им что, специально дали доступ в закрытые репозитории?
Им что, специально дали доступ в закрытые репозитории?
Github
В приличных конторах всё-таки следят чтоб программисты педалили.
Не оспаривая тезис, что среди нашего брата есть ленивые жопы, таки хочу заметить, что считать коммиты — это не очень хорошая метрика. Разработчик более-менее продвинутого уровня может общаться, составлять ТЗ для июней, решать какие-то вопросы с юзерами, читать резюме и собеседовать, разбираться с архитектурой и делать много чего ещё.
Ну и иногда чтобы внести изменения в одну строчку надо потратить два дня на понять что вообще происходит.
Хотя, повторюсь, лентяи и дармоеды есть, тут не поспоришь.
Не оспаривая тезис, что среди нашего брата есть ленивые жопы, таки хочу заметить, что считать коммиты — это не очень хорошая метрика. Разработчик более-менее продвинутого уровня может общаться, составлять ТЗ для июней, решать какие-то вопросы с юзерами, читать резюме и собеседовать, разбираться с архитектурой и делать много чего ещё.
Ну и иногда чтобы внести изменения в одну строчку надо потратить два дня на понять что вообще происходит.
Хотя, повторюсь, лентяи и дармоеды есть, тут не поспоришь.
ebanoe.it — украинский ресурс.
Чёт лежит. Надеюсь, временно, и с ними всё в порядке.
Чёт лежит. Надеюсь, временно, и с ними всё в порядке.
В Италии есть программисты? Даже удивился.
то он должен инициативы предлагать и питчить.
Но чтоб разработчик, принципал тем более, не создал месяца за три никакой инициативы, не написал ничего… да как, КАК??? У него же есть задачи, разве нет? Как он их закрывает? А если задач ему не ставят, то он должен инициативы предлагать и питчить. А если ничего нет, то просто как?…
Это ты сам, или редактор подсказал?
На широко известном в узких кругах итальянском ресурсе для ойти специалистов это, в общем, расхожее определение для молодых неопытных разработчиков. Оттуда и взял.
составлять ТЗ для июней,
Ну вот искренне не понимаю, как так можно. То есть если он менеджер - то допустим, но менеджер же должен работу команды планировать и координировать, в этом его работа и заключается.
Если поставить себе цель — ничего не делать, то вероятно можно достигнуть желаемого.
Ну вот искренне не понимаю, как так можно. То есть если он менеджер - то допустим, но менеджер же должен работу команды планировать и координировать, в этом его работа и заключается.
Бывает. Если поставить себе цель — ничего не делать, то вероятно можно достигнуть желаемого.
Но даже если искренне болеешь за проект, то случается, что до программизма руки не доходят при всём желании.
Но даже если искренне болеешь за проект, то случается, что до программизма руки не доходят при всём желании.
считать коммиты — это не очень хорошая метрика. Разработчик более-менее продвинутого уровня может общаться, составлять ТЗ
У нас одно всемя производительность QA оценвали по количеству новопроизведённых багов в месяц. Ох уж QA-щики оторвались 😄
Правда потом этого доброго менеджера убрали. Без бонуса.
Правда потом этого доброго менеджера убрали. Без бонуса.
Так это задача QA - баги искать, количество найденных багов - один из критериев оценки их работы
Так считать за минусами дублей, by design, not to be fixed, общее количество реальных багов и соотношение ко всем зафайленым. В QA как раз все просто
Количество закрытых на оценку работы никак не влияло.
А вот кодеры дожны были на эти 90% шума тратить время, чтобы оценить и закрыть.
в смысле, начали, наконец, находить баги?
Ох уж QA-щики оторвались
потом этого доброго менеджера убрали
Так это задача QA - баги искать, количество найденных багов - один из критериев оценки их работы
Из оставшихся "прилежных" 90%, примерно для трети из их количества было бы для общего блага полезнее, если бы они ничего не вносили.
Ещё один тупорылый вариант считать производительность -- по количеству закрытых стори-поинтов в Джире.
Мне как-то на глаза попалась отличная статья о том как менеджмент попросил тим-лида уволить разработчика, который меньше всего стори-поинтов закрывал, дескать, зачем нам он такой малопроизводительный. Тот наотрез отказался, и вот почему.
Да, тот чувак закрывал мало тасок. Иногда вообще ни одной за спринт. Но он активно помогал в решении задач другим членам команды. Постоянно. День за днём. Каждому. И каждый же член команды признавал значимость вклада этого парня.
Вместо того, чтобы непосредственно обеспечивать деливери решений задач, "малопроизводительный" разработчик деливерил всю команду. А его уход неминуемо сказался бы на общей продуктивности.
Но для такого отказа менеджменту нужен не просто ум, нужна определённая мудрость. Которая есть не у всех лидов.
Мне как-то на глаза попалась отличная статья о том как менеджмент попросил тим-лида уволить разработчика, который меньше всего стори-поинтов закрывал, дескать, зачем нам он такой малопроизводительный. Тот наотрез отказался, и вот почему.
Да, тот чувак закрывал мало тасок. Иногда вообще ни одной за спринт. Но он активно помогал в решении задач другим членам команды. Постоянно. День за днём. Каждому. И каждый же член команды признавал значимость вклада этого парня.
Вместо того, чтобы непосредственно обеспечивать деливери решений задач, "малопроизводительный" разработчик деливерил всю команду. А его уход неминуемо сказался бы на общей продуктивности.
Но для такого отказа менеджменту нужен не просто ум, нужна определённая мудрость. Которая есть не у всех лидов.
В этой ситуации надо было тим лида увольнять нафиг. Он очень хреновый тим лид если менеджмент вообще не в курсе чем занимаются люди из его команды. Это он должен был "нарезать" консалтинг сторей тому девелоперу, согласовать эти стори с менеджментом, получить на это апрув и пинать того самого девелопера что бы он регулярно отписывался в сторе чем именно он сегодня занимался, кого консультировал и сколько времени потратил. Менеджмент был бы в экстазе, а тому деву может быть ещё бы и бонус прилетел за такой высокий уровень экспертизы, ноледж шеринг и коллаборацию.
Если мою работу измерять по коммитам, то я сильно отстаю от джунов, которых целыми днями инструктирую и консультирую, а также провожу с ними дебаг и code review, разгребаю их факапы и ошибки в конфигурации. И вообще, нафига применять количественные оценки в такой специфической области? Лучше дрючьте девелоперов за низкий coverage или падение pass rate в очередной регрессии.
Тут сильно зависит от того, как делается ревью. По-хорошему, надо вникнуть в задачу и подумать как ты бы сам ее сделал. Увы, обычно сводится к быстрому просмотру кода на предмет "тут O(n), а можно было O(1) или O(log n), тут нарушается SOLID" etc.
А за хреновый код или коммит сообщения - не дрючите?
И вообще, нафига применять количественные оценки в такой специфической области?.
если у вас
низкий coverage???
Реально?
если у вас программистов дрючат за coverage - то нафиг такую контору
Реально?
если у вас программистов дрючат за coverage - то нафиг такую контору
Лучше дрючьте девелоперов за низкий coverage или падение pass rate в очередной регрессии.
за низкий coverage или падение pass rate в очередной регрессии.
У большого бизнеса сейчас есть намерение прекратить эту удаленную работу и вернуть всех под крылышко менеджеров к кофемашинам и конфзалам. Одна компания за другой принимают такие решения. А люди в большинстве уже привыкли из дома работать. Бонусов много оказалось. Да и переехать многие успели. А нанятые недавно вообще не то что в офисе, в стране офиса никогда не были. Но материалов с удобными цифрами (как в той теме) в медиа встречается все больше. Есть ложь и есть статистика. Ей можно вертеть, как это выгодно заказчику.
Никто особо не хочет возвращать 100% офисный вариант работы.
Amazon kills remote working, tells workers to be in office 5 days a week
Святая наивность, что менеджеры всегда мыслят рационально и никогда не выстрелят себе в ногу.
Восстанавливать офис до полной загрузки - очень дорого, и не факт что имеет смысл.
Из того что я вижу все немного хитрее. Никто особо не хочет возвращать 100% офисный вариант работы. Вот гибридный вариант - это да. 40-60-80% времени удаленно, остальное из офиса. Но тут есть такое дело - за время полной удаленки многие компании просто сократили рабочее пространство в офисах, ну физически нет места для всех сотрудников единовременно. Восстанавливать офис до полной загрузки - очень дорого, и не факт что имеет смысл.
Ха... программисты ни хрена не делают. Аж целых 14%!
Ешкин кот.
Знаю несколько организаций, федеральных, государственных, где ни хрена не делают, и даже не скрывают этого, 80% сотрудников. Т.е. какие то бумажки перекладываются, что то происходит, какая то активность есть, но по сути они ни хрена не делают.
Ешкин кот.
Знаю несколько организаций, федеральных, государственных, где ни хрена не делают, и даже не скрывают этого, 80% сотрудников. Т.е. какие то бумажки перекладываются, что то происходит, какая то активность есть, но по сути они ни хрена не делают.
Таки вы из тех кто найдет "золотое сечение" в размерах стульчака
Таки вы из тех кто найдет "золотое сечение" в размерах стульчака ? 😄
Аж целых 14%!
Совпадениенедумаю.
Знакомый тимлид рассказывал - держат чувака в возрасте в штате по сути на должности эксперта, задачами он не загружен, кроме него есть кому кодить, но иногда возникают такие вопросы, которые решить может он и только он и достаточно быстро.
Как он сказал, что-то типа - он повышает уровень компетентности нашей команды.
Так что все эти исследования из серии - "британские ученые", жизнь - она намного сложнее.
Как он сказал, что-то типа - он повышает уровень компетентности нашей команды.
Так что все эти исследования из серии - "британские ученые", жизнь - она намного сложнее.
если задачи поставлены, то и коммиты должны быть (раз в месяц уж точно).
А вообще есть такой анекдот:
- Как только из параметра делают KPI, он перестает иметь отношение к реальной жизни.
- О, как это верно. У нас накопилась куча бессмысленных KPI, давайте их отменим!
(через месяц)
- В эту итерацию мы отменили на 20% больше бессмысленных KPI, чем в прошлую!
не, исследование интересное, но, кмк, скорее показывает процент бесполезных отделов\отдельчиков\командочек, ибо во всех крупных конторах есть системы ведения проектов а-ля agile и т.п., то бишь, если задачи поставлены, то и коммиты должны быть (раз в месяц уж точно).
еще есть возможность, что анализировали не все репозитарии, типа пилит человек свою задачу в своем локальном репозитарии, а потом подмёрживает сорцы в глобальный.
еще есть возможность, что анализировали не все репозитарии, типа пилит человек свою задачу в своем локальном репозитарии, а потом подмёрживает сорцы в глобальный.
"британские ученые",
Станфорд в США.
Станфорд в США.
и еще 69% против политики любого правительства Израиля?
Конкретно в Станфорде беспорядков не видел. Если ты про Колумбию, то там 1% был против политики теперешнего правительства Израиля.
Стэнфорд, это которые за Газа против Израиля? 😉
Станфорд в США.
Станфорд в США.
Вы не путайте разработчиков и методистов.
"британские ученые",
Вы не путайте разработчиков и методистов.
Считать KPI по количеству коммитов или количеству строчек кода - ежики кололись, плакали, но продолжали жрать этот кактус.
Лет 20 назад в одной крупной немецкой компании один добрый менеджер предложил гениальную идею (шокирующую своей новизной) как посчитать производительность девелоперов. А давайте, говорит, будем считать сколько строчек кода они в день барабанят. А давайте, весело отозвались топ менеджеры (и не замедлительно выписали доброму менеджеру, нет, не в бубен, а довольно крупный бонус за рац. предложение). Что на это сказали разработчики? А ничего не сказали, ухмыльнулись и давай развлекаться CTRL+C - CTRL+V и так весь день. В конце месяца посчитали, прослезились от умиления и осознания как все тяжело и усердно работают и всем выписали, нет, опять не в бубен, а бонусы. И так продолжалось какое то время пока на устройстве (а проект был под эмбеддед устройство где ресурсы ограничены) закончилось место и бинарь в него уже никак не лез. И тут топ менеджмент начала подозревать, что находится на пороге грандиозного шухера. Но появился еще один добрый менеджер и сказал, а давайте мы в Украину зааутсорсим задачи по оптимизации кода, мол слышал там ребята толковые и стоят крепко дешевше чем наши родные немецкие парни. А давайте, радостно отозвался топ менеджер и незамедлительно выписал, опять нет, не в бубен, а бонус этому доброму менеджеру. Вот так проект попал нашей команде. Нас спросили можете ли хоть за пол года что то с этим сделать? Мы ответили - можем за пол года, а вот за год - не справимся.. Надо бюджет расширять. В общем сделали за три месяца и нам выписали .... нет, не угадали, не в бубен, а бонусы.
Что бизнес хотел? Очевидно, улучшить производительность труда своих разработчиков. А что получил по итогу?
Лет 20 назад в одной крупной немецкой компании один добрый менеджер предложил гениальную идею (шокирующую своей новизной) как посчитать производительность девелоперов. А давайте, говорит, будем считать сколько строчек кода они в день барабанят. А давайте, весело отозвались топ менеджеры (и не замедлительно выписали доброму менеджеру, нет, не в бубен, а довольно крупный бонус за рац. предложение). Что на это сказали разработчики? А ничего не сказали, ухмыльнулись и давай развлекаться CTRL+C - CTRL+V и так весь день. В конце месяца посчитали, прослезились от умиления и осознания как все тяжело и усердно работают и всем выписали, нет, опять не в бубен, а бонусы. И так продолжалось какое то время пока на устройстве (а проект был под эмбеддед устройство где ресурсы ограничены) закончилось место и бинарь в него уже никак не лез. И тут топ менеджмент начала подозревать, что находится на пороге грандиозного шухера. Но появился еще один добрый менеджер и сказал, а давайте мы в Украину зааутсорсим задачи по оптимизации кода, мол слышал там ребята толковые и стоят крепко дешевше чем наши родные немецкие парни. А давайте, радостно отозвался топ менеджер и незамедлительно выписал, опять нет, не в бубен, а бонус этому доброму менеджеру. Вот так проект попал нашей команде. Нас спросили можете ли хоть за пол года что то с этим сделать? Мы ответили - можем за пол года, а вот за год - не справимся.. Надо бюджет расширять. В общем сделали за три месяца и нам выписали .... нет, не угадали, не в бубен, а бонусы.
Что бизнес хотел? Очевидно, улучшить производительность труда своих разработчиков. А что получил по итогу?
Классика.
Я в предыдущей инкарации прожил через несколько "оптимизаций расходов" в одном ныне несуществующем банке. Поскольку под "оптимизацией", без исключения, понимается сокращение кадров банк поручал ЖОРАМ и ЛОРАМ, сокращались только работающие и неудобные СУКи. И как неизбежен восход солнца уторм, так ровно через пол года после сокращения штат банка удваивался, просто чтоб поддержать производителность на том же уровне.
Я в предыдущей инкарации прожил через несколько "оптимизаций расходов" в одном ныне несуществующем банке. Поскольку под "оптимизацией", без исключения, понимается сокращение кадров банк поручал ЖОРАМ и ЛОРАМ, сокращались только работающие и неудобные СУКи. И как неизбежен восход солнца уторм, так ровно через пол года после сокращения штат банка удваивался, просто чтоб поддержать производителность на том же уровне.
Опять же, так будет если бизнес рационален. А чаще получается что не очень. Обычно старается - но получается не лучше чем рациональность людей в нем занятых. Если посмотреть на список когнитивных искажений (оцените хотя бы его размер на вики) - то, думаете, у бизнеса будет тенденция их скорее исправлять... или усугублять? Тут вон, как показали нобелевские лауреаты по економике, человек в своей собственной голове не особо может рацио вывести - а тут и людей много, и у них запутанные отношения, и общий шум высок. Так что сделанный вами проект (отдельный вам респект) - они вполне могут занести себе в плюсы. Сам удивляюсь как мы (человечество) еще не схлопнулись с таким подходом.
Кстати, если что - я как вы. Программист, тащу такой вот аутсорснутый в Украину проект. Тоже все счастливы.
Кстати, если что - я как вы. Программист, тащу такой вот аутсорснутый в Украину проект. Тоже все счастливы.
Врядли бизнес хотел увеличения расходов на разработку аутсорся проект на удаленную команду, которая, по сути, сделала двойную работу. Нового функционала не появилось, устранялись только проблемы, которые были вызваны дуростью местного менеджмента.
Что бизнес хотел? Очевидно, улучшить производительность труда своих разработчиков.
А что получил по итогу?
Вот в таком офисе - чья хотелка будет совпадать с "хотелкой бизнеса"?
И что, меньше 3 коммитов в месяц - это уже ничего не делать? Ну офигеть теперь.
Три коммита в день - это нормально. Хотя и не всегда возможно
Три коммита в месяц - это странно
Три коммита в месяц - это странно
Ну я по такому принципу и работаю вообще-то 😅
Но очень напрягает и расстраивает бездельничанье. Так что большая часть усилий уходит именно на переживания по этому поводу.
Но очень напрягает и расстраивает бездельничанье. Так что большая часть усилий уходит именно на переживания по этому поводу.
Это шож получается, целую среду работать?! (с) анкедот
Здесь мерилом работы считают усталость.
По коммитам считать - такое себе.
Но как база потянет.
Да и корректно выглядит: в офисе работают лучше.
Но как база потянет.
Да и корректно выглядит: в офисе работают лучше.
Потому что дома есть другие дела и никто тебя не контролирует, даже морально
Потому что дома есть другие дела и никто тебя не контролирует, даже морально
В общем, везде хорошо. Я лично не заметил разницы между производительностью, она больше от интереса зависит, чем от местонахождения. И да, дома не тратится час на дорогу.
Кофе пить, новости читать, с коллегами болтать. То же самое, что и дома, но плюс личное общение.
Отнюдь. В офисе просто нечего делать, кроме работы.
Да и корректно выглядит: в офисе работают лучше
