Адрес для входа в РФ: exler.wiki
Программеры филонят
27.11.2024 11:42
6244
Комментарии (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. Около тысячи строчек кода + несколько тысяч строк мок-данных.
А потом вы будете спрашивать, почему софт превращается в дерьмо...
Тысяча строк кода в день. 125 строк в час, две строки в минуту. Чуваку думать некогда, он код педалит.
Несколько тысяч строк мок-данных. Ну тут ваще. Мало того, что мок, за который в приличных фирмах стреляют в голову, так еще и несколько тысяч.
Короче, у него еще, жена - модель, яхта океанского класса и три приватных джета
Тысяча строк кода в день. 125 строк в час, две строки в минуту. Чуваку думать некогда, он код педалит.
Несколько тысяч строк мок-данных. Ну тут ваще. Мало того, что мок, за который в приличных фирмах стреляют в голову, так еще и несколько тысяч.
Короче, у него еще, жена - модель, яхта океанского класса и три приватных джета
Не воспримите за наезд, но в какой это области в день 1000 строк кода?
У меня за вчера где-то коммитов 20. Около тысячи строчек кода + несколько тысяч строк мок-данных.
Не воспримите за наезд, но в какой это области в день 1000 строк кода?
Заменил все табы на пробелы? Так и миллион строк кода можно за раз поменять.
Коммитов двадцать - это потому самому было лень код запускать, и тестировал на CI, а оно всё падало и падало?
Ну, осуждаю, но бывает. Хоть засквошил потом?
Ну, осуждаю, но бывает. Хоть засквошил потом?
Коммитов двадцать - это потому самому было лень код запускать, и тестировал на CI, а оно всё падало и падало?
У меня есть уникумы, которые коммитят, не проверяя даже на уровне "компилится оно или нет". Зато дешёвые, что руководство и ценит.
только 14% инженеров-программистов, работающих удаленно, ни хрена не делают. Я был уверен, что их заметно больше. Также исследователи выяснили, что 9% работающих одновременно удаленно и в офисе ни черта не делают, а в офисе ни черта не делают 6%.
Остальные — умные. Один раз автоматизировал удаление/добавление всех точек с запятой в питоновом коде, и каждый день кроном запускаешь. Можно хоть каждый час.
Остальные 42% вносят тривиальные изменения: например, редактируют одну строку или символ, делая вид, что работают.
Из человеколюбия.
Его ж разорвёт в бане из-за такой темы.
Присоединяюсь к петиции! Хлеба и зрелищ!
Free Pafnustain!
Его ж разорвёт в бане
Его ж разорвёт в бане
из сотен крупных IT-компаний, проанализировав исходный код из закрытых репозиториев Git
Может метаданные получили?
Если из метаданных можно наковырять количество и объем коммитов с привязкой к организации, то это закрытость уровня "а в этом женском туалете у нас стены нет, пойдёмте дальше".
а как они задачи закривают?
бред какой-то...
бред какой-то...
а как они задачи закривают?
а, то есть туда в таску - релиз можно не прикреплять?
а я не знал...
а я не знал...
Проверил, из моих 15 разрабов коммитили все за последний месяц (тьфу-тьфу, постучим по дереву)
которая количественно оценила работоспособность более 50 тысяч разработчиков программного обеспечения из сотен крупных IT-компаний, проанализировав исходный код из закрытых репозиториев Git.
Каким макаром какие-то там сторонние исследователи получили доступ к закрытым репам "сотен крупных IT-компаний"?
С согласия этих компаний?
"Закрытые репозитории" не просто так же закрыты.
А те аж бегом побегли открывать доступ незнамо кому, к своим сорцам, да. 😄"Закрытые репозитории" не просто так же закрыты.
Секретное за физический пределы офиса не должно попадать.
Пойду сделаю пару коммитов. И проверю почту заодно
Вот прямо сейчас у меня идёт третий день попыток заставить работать одну функцию, которая в идеальной среде укладывается в две строки кода. А под CMS - не работает, собака женского пола.
Вот я вокруг этих двух строк разные варианты и пробую. По мнению исследователей из Стэнфордского университета я - бездельник?
Вот я вокруг этих двух строк разные варианты и пробую. По мнению исследователей из Стэнфордского университета я - бездельник?
Потому индусы и пишут простыни кода, что оценивают их безмозглые менеджеры.
Когда последний раз писал курсовую (1984 год) преподаватель задал вопрос "почему вы используете простой перебор со сравнением, а не циклы?"
Я сказал что-то вроде "потому что так заработало с первого раза, а у коллеги, с его циклами, нет".
Я сказал что-то вроде "потому что так заработало с первого раза, а у коллеги, с его циклами, нет".
К сожалению, с менеджерами я знаком лучше, чем с творчеством "индусов". Так что верю 😄
За простыни кода нужно карать.
Ну, если исследователи из Стэнфордского университета меряют работоспособность "индусскими" параметрами, то конечно, они же ученые.
Вот если ты стучишь по клаве со скоростю света и комитишь как не в себя, то ты значит продуктивный работник. "Но в основном фигня какая-то получается" (с) анекдот
Вот если ты стучишь по клаве со скоростю света и комитишь как не в себя, то ты значит продуктивный работник. "Но в основном фигня какая-то получается" (с) анекдот
Обожаю фильмы про хакеров, которые с огромной скоростью клавиатурят.
А на экране ползут красивые строчки комментариев...
А на экране ползут красивые строчки комментариев...
Я один раз прикололся. Написал программку, которая перехватывает нажатия клавиш и вместо них впендюривает свои. Включил, когда докладывал об успехах своей команды, и притворился, что гугль-докс съел заранее подготовленную презентацию, и что я её вот прям щаз набью заново. После чего молотил по клавишам, ни разу не коснувшись пробела.
Дело началось проще. До меня наш производственный процесс выглядел следующим образом: с утра мы садились и играли в сику, на деньги (вы умеете играть в сику?). Так. Потом вставали, разматывали барабан с кабелем и кабель укладывали под землю. А потом – известное дело: садились, и каждый по-своему убивал свой досуг, ведь все-таки у каждого своя мечта и свой темперамент: один – вермут пил, другой, кто попроще – одеколон «Свежесть», а кто с претензией – пил коньяк в международном аэропорту Шереметьево. И ложились спать.
А наутро так: садились и пили вермут. Потом вставали и вчерашний кабель вытаскивали из-под земли и выбрасывали, потому что он уже весь мокрый был, конечно. А потом – что же? – потом садились играть в сику, на деньги. Так и ложились спать, не доиграв.
Рано утром уже будили друг друга: «Лёха! Вставай в сику играть!» «Стасик, вставай доигрывать вчерашнюю сику!» Вставали, доигрывали в сику. А потом – ни свет, ни заря, ни «Свежести» не попив, ни вермуту, хватали барабан с кабелем и начинали его разматывать, чтоб он до завтра отмок и пришел в негодность. А потом – каждый за свой досуг, потому что у каждого свои идеалы. И так все сначала.
Став бригадиром, я упростил этот процесс до мыслимого предела. Теперь мы делали вот как: один день играли в сику, другой – пили вермут, на третий день – опять в сику, на четвертый – опять вермут. А тот, кто с интеллектом, – тот и вовсе пропал в аэропорту Шереметьево: сидел и коньяк пил. Барабан мы, конечно, и пальцем не трогали, – да если б я и предложил барабан тронуть, они все рассмеялись бы, как боги, потом били бы меня кулаками по лицу, ну а потом разошлись бы: кто в сику играть, на деньги, кто вермут пить, а кто «Свежесть».
А наутро так: садились и пили вермут. Потом вставали и вчерашний кабель вытаскивали из-под земли и выбрасывали, потому что он уже весь мокрый был, конечно. А потом – что же? – потом садились играть в сику, на деньги. Так и ложились спать, не доиграв.
Рано утром уже будили друг друга: «Лёха! Вставай в сику играть!» «Стасик, вставай доигрывать вчерашнюю сику!» Вставали, доигрывали в сику. А потом – ни свет, ни заря, ни «Свежести» не попив, ни вермуту, хватали барабан с кабелем и начинали его разматывать, чтоб он до завтра отмок и пришел в негодность. А потом – каждый за свой досуг, потому что у каждого свои идеалы. И так все сначала.
Став бригадиром, я упростил этот процесс до мыслимого предела. Теперь мы делали вот как: один день играли в сику, другой – пили вермут, на третий день – опять в сику, на четвертый – опять вермут. А тот, кто с интеллектом, – тот и вовсе пропал в аэропорту Шереметьево: сидел и коньяк пил. Барабан мы, конечно, и пальцем не трогали, – да если б я и предложил барабан тронуть, они все рассмеялись бы, как боги, потом били бы меня кулаками по лицу, ну а потом разошлись бы: кто в сику играть, на деньги, кто вермут пить, а кто «Свежесть».
Москва—Петушки
Поэма
На предыдущем проекте в огромной и очень кривой системе от HP не раз бывало, что приходится 1-2 дня поискать, где всё же ошибка, а потом парой строк исправить. Или исправляешь по нормальному системную функцию, а потом весело ищешь и правишь в миллионе мест, где она использовалась... И это всё занимает время, хотя и не очень много - но за неделю ты сделал всего 1 задачу с 1 коммитом, в котором несколько десятков строк...
Я как то пару дней потратил чтоб найти и отредактировать одну строку, более того один символ.
Или наоборот - находится быстро, символов для правки много, но времени занимает дофигища, с учетом тестирования.
А коммит один.
А коммит один.
Или вообще находишь и чинишь с помощью созвонов и емейлов без коммитов ))
И иногда это пробел 😺
И иногда это пробел 😺
Остальные 42% вносят тривиальные изменения: например, редактируют одну строку или символ, делая вид, что работают.
Я пишу, но комичу локально в основном. А пушу время от времени, когда уже почти всё готово. Если какая-то большая задача, которая делается неделю-две - то на сервере комитов не будет, но это не значит, что работа не идёт.
Те же джуны часто переделывают по 5 раз одно и тоже - и там в день просто куча коммитов. Вот они, получается, супер работники...
У нас просто есть план на квартал и он разбивается на спринты. Ставятся задачи в спринты - если выполняешь, то всё отлично. И неважно сколько там коммитов/строк кода/времени - хочешь ночью работай а днём на паре созвонов побудь (время созвонов, кстати, в тайм трекере не учитывается... Надо его раскидывать на задачи), и занимайся своими делами, если тебе так удобно.
Те же джуны часто переделывают по 5 раз одно и тоже - и там в день просто куча коммитов. Вот они, получается, супер работники...
У нас просто есть план на квартал и он разбивается на спринты. Ставятся задачи в спринты - если выполняешь, то всё отлично. И неважно сколько там коммитов/строк кода/времени - хочешь ночью работай а днём на паре созвонов побудь (время созвонов, кстати, в тайм трекере не учитывается... Надо его раскидывать на задачи), и занимайся своими делами, если тебе так удобно.
Если какая-то большая задача, которая делается неделю-две - то на сервере комитов не будет, но это не значит, что работа не идёт.
Когда разрабов мало, и каждый делает строго свою задачу, то там не сильно принципиально. Как один из вариантов бэкапа - согласен, но одна ветка не всегда критично + бэкапы локально делаются
A Nightmare… IMO
«Обычно» рабочий день 6.5 часов на sprint tasks, остальное время на standups, planning, retrospectives, etc. При этом не нужно «раскидывать» ceremonies на задачи.
«Обычно» рабочий день 6.5 часов на sprint tasks, остальное время на standups, planning, retrospectives, etc. При этом не нужно «раскидывать» ceremonies на задачи.
planning, retrospectives, etc
Я не программист, и мало в этом понимаю. Но меня всегда удивляло вот что.
Вот выходит новая версия программы или даже ОС, или новая игра - и делали все это туеву хучу лет, и там багов как блох на бродячей собаке. Ну как так?
Более того, как правило аддоны почти всегда делают нормально работающую программу хуже, чем она была.
Что это?
И такая шняга стала нормой лет 20 как.
Если бы в моей сфере деятельности народ (включая меня) так работал, то после второй, а иногда и первой ошибки вылетел бы с места впереди собственного визга. А тут компании и их сотрудники десятилетиями косячат, и хоть бы хны.
Ты выпускаешь продукт. Работаешь несколько лет. У тебя есть возможность бета-тестинга. И все равно выпускаешь говно, которое потом приходится ещё пару лет допиливать.
Так может, просто этих программистов развелось слишком много? Похоже как минимум половину можно тупо заменить ИИ, и никто не заметит. Будет по прежнему выходит недоделанное говно, потому что ИИ создают и программируют те же самые долбоклюи.
Вот выходит новая версия программы или даже ОС, или новая игра - и делали все это туеву хучу лет, и там багов как блох на бродячей собаке. Ну как так?
Более того, как правило аддоны почти всегда делают нормально работающую программу хуже, чем она была.
Что это?
И такая шняга стала нормой лет 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.
там багов как блох на бродячей собаке. Ну как так?
а вообще программирование нельзя сравнивать со всем остальним
єто чистое творчество причем абстрактное, мест где может поломаться уйма , все не предвидишь, чем сложнее программа тем больше багов
Вот выходит новая версия программы или даже ОС, или новая игра - и делали все это туеву хучу лет, и там багов как блох на бродячей собаке. Ну как так?
В бар заходит тестировщик. Заказывает стакан пива. Заказывает два стакана пива. Заказывает миллион стаканов пива. Заказывает ноль стаканов пива. Заказывает минус один стакан пива. Заказывает полтора стакана пива. Заказывает ящерицу в стакане.
В бар заходит первый настоящий посетитель. Спрашивает, где туалет. Бар взрывается.
Я не программист, и мало в этом понимаю. Но меня всегда удивляло вот что. Вот выходит новая версия программы или даже ОС, или новая игра - и делали все это туеву хучу лет, и там багов как блох на бродячей собаке. Ну как так?Более того, как правило аддоны почти всегда делают нормально работающую программу хуже, чем она была. Что это? И такая шняга стала нормой лет 20 как.
авто отзывают его и либо меняют, либо отдают деньги обратно? Что-то не слышал, чтобы нечто подобное делали софтверные компании.
Жизнь сложнее, чем теория. А принципе три-четыре момента мешают
Недостаточный уровень тестирования. Тестируют в принципе все, но уровень тестирования сильно отличается. К тому же правильно написанный код (автоматически) тестировать куда легче.
Говнокод Этим страдают почти все. Неправильно написанный код заставить работать корректно невозможно. Его нельзя нормально поддерживать.
Изменения в требованиях В процессе разработки вносятся изменения, которые вносят хаос на всех уровнях.
Бизнес причины Софт релизят с багами вполне сознательно.
Недостаточный уровень тестирования. Тестируют в принципе все, но уровень тестирования сильно отличается. К тому же правильно написанный код (автоматически) тестировать куда легче.
Говнокод Этим страдают почти все. Неправильно написанный код заставить работать корректно невозможно. Его нельзя нормально поддерживать.
Изменения в требованиях В процессе разработки вносятся изменения, которые вносят хаос на всех уровнях.
Бизнес причины Софт релизят с багами вполне сознательно.
"Если бы архитекторы строили дома так, как программисты пишут программы, то первый залетевший дятел разрушил бы цивилизацию."
(с) Какой-то из законов Мэрфи
(с) Какой-то из законов Мэрфи
Жизнь сложнее, чем теория. А принципе три-четыре момента мешают
Софт релизят с багами вполне сознательно.
Зачем?
Но могу успокоить - ошибки всегда разбиваются по уровню критичности для конечного пользователя. Если где-то на сайте стиль, например, поехал и какой-то текст поменял цвет или там съехал куда, скорее всего такой баг не будут экстренно фиксить, а запланируют в следующий релиз. Если пользователь не может пользоваться какой-либо важной функцией софта - то да, такое в релиз в нормальных конторах не выпустят. Или будет выпущен внеочередной патч уже после релиза.
Все-таки это не сознательно выпускают с багами, только может minor или UI, когда понимают что не успевают фикснуть или боятся регрешион,
А за крупные баги очень даже по шапке дают
А за крупные баги очень даже по шапке дают
Бизнес причины Софт релизят с багами вполне сознательно.
IYKWIM
Потому что бета-тестинг это вчерашний день. Крупные разработчики давно его сократили и выкатывают сразу на прод. Клиентов больше, чем бетатестеров, баги отловятся быстрее. А лицензионное соглашение все равно снимает с производителя всякую ответственность за последствия.
Мой личный рекорд, примерно 80 строчек кода, 2 недели работы, и премия в размере месячного оклада. 😄
Мой личный рекорд, примерно 80 строчек кода, 2 недели работы, и премия в размере месячного оклада. 😄
минус 900 строчек кода.
Гомо сапиенс."
Мой личный рекорд за неделю работы - минус 900 строчек кода. Без какого-либо изменения функциональности модуля. 😄
Мой личный рекорд за неделю работы - минус 900 строчек кода. Без какого-либо изменения функциональности модуля. 😄
Мой личный рекорд за неделю работы - минус 900 строчек кода. Без какого-либо изменения функциональности модуля. 😄
Совсем недавно убрал штук сто строк из одного модуля.
Запрос, который выполнялся секунд двадцать, стал выполняться меньше, чем за секунду.
Да, мне было очень стыдно, поскольку эти сто строк писались тоже мной.
И знаете, что обидно? Абсолютно никто этого не заметил!
Ты заметил.
Это важно.
Для тебя же.
Это важно.
Для тебя же.
Остальные 42% вносят тривиальные изменения: например, редактируют одну строку или символ Это называется рефакторинг, так то)
Интересно, что мешает работать индийским программистам? Русскоязычные целый день срутся в интернете по украинскому вопросу. Уже лет двадцать как. А индусы? Кто знает ? Ведь не могут они на работе работать!
Колониальное прошлое, свадьбы, рождение детей, приезды отьезды родителей и прочие дивали
А они выясняют чей Кашмир 🤭!
Ютуб однажды подсунул канал одного капитана из торгового флота поведавшего как оно работать с индусами и на индусов. Это п-ц. Уровень бюрократии и долбо...зма запредельный даже по шкале расеянина
Уровень бюрократии и долбо...зма запредельный
Спросите у индусов как на***бать систему.
Многие страницы "как пройти собеседования в Гугле, Амазоне итд" в помощь.
Они очень хорошо умеют играть в корпоративные игры, представлять себя в наилущем свете.
Многие страницы "как пройти собеседования в Гугле, Амазоне итд" в помощь.
Они очень хорошо умеют играть в корпоративные игры, представлять себя в наилущем свете.
Интересно, кто нибудь читал когда-то, что пишут индусы о русских программистах? 😄
Расисты все белые. Ибо не позволяют индусам на себе ездить (piggybacking)
"Гюльчатай! Открой интерфейс."
Ох, прямо захотелось в библиотеку.
Они очень хорошо умеют играть в корпоративные игры, представлять себя в наилущем свете.
Именно. У меня сейчас такой пример рядом. У нас тут есть такое как 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, должен был знать наизусть. Если бы от меня зависило - уволил бы нахрен. Специализд...
проанализировав исходный код из закрытых репозиториев Git
Им что, специально дали доступ в закрытые репозитории?
Им что, специально дали доступ в закрытые репозитории?
Github
В приличных конторах всё-таки следят чтоб программисты педалили.
Не оспаривая тезис, что среди нашего брата есть ленивые жопы, таки хочу заметить, что считать коммиты — это не очень хорошая метрика. Разработчик более-менее продвинутого уровня может общаться, составлять ТЗ для июней, решать какие-то вопросы с юзерами, читать резюме и собеседовать, разбираться с архитектурой и делать много чего ещё.
Ну и иногда чтобы внести изменения в одну строчку надо потратить два дня на понять что вообще происходит.
Хотя, повторюсь, лентяи и дармоеды есть, тут не поспоришь.
Не оспаривая тезис, что среди нашего брата есть ленивые жопы, таки хочу заметить, что считать коммиты — это не очень хорошая метрика. Разработчик более-менее продвинутого уровня может общаться, составлять ТЗ для июней, решать какие-то вопросы с юзерами, читать резюме и собеседовать, разбираться с архитектурой и делать много чего ещё.
Ну и иногда чтобы внести изменения в одну строчку надо потратить два дня на понять что вообще происходит.
Хотя, повторюсь, лентяи и дармоеды есть, тут не поспоришь.
считать коммиты — это не очень хорошая метрика. Разработчик более-менее продвинутого уровня может общаться, составлять ТЗ
Бывает. Если поставить себе цель — ничего не делать, то вероятно можно достигнуть желаемого.
Но даже если искренне болеешь за проект, то случается, что до программизма руки не доходят при всём желании.
Но даже если искренне болеешь за проект, то случается, что до программизма руки не доходят при всём желании.
Ну вот искренне не понимаю, как так можно. То есть если он менеджер - то допустим, но менеджер же должен работу команды планировать и координировать, в этом его работа и заключается.
Если поставить себе цель — ничего не делать, то вероятно можно достигнуть желаемого.
Ну вот искренне не понимаю, как так можно. То есть если он менеджер - то допустим, но менеджер же должен работу команды планировать и координировать, в этом его работа и заключается.
составлять ТЗ для июней,
Это ты сам, или редактор подсказал?
На широко известном в узких кругах итальянском ресурсе для ойти специалистов это, в общем, расхожее определение для молодых неопытных разработчиков. Оттуда и взял.
Но чтоб разработчик, принципал тем более, не создал месяца за три никакой инициативы, не написал ничего… да как, КАК??? У него же есть задачи, разве нет? Как он их закрывает? А если задач ему не ставят, то он должен инициативы предлагать и питчить. А если ничего нет, то просто как?…
то он должен инициативы предлагать и питчить.
В Италии есть программисты? Даже удивился.
ebanoe.it — украинский ресурс.
Чёт лежит. Надеюсь, временно, и с ними всё в порядке.
Чёт лежит. Надеюсь, временно, и с ними всё в порядке.
У нас одно всемя производительность QA оценвали по количеству новопроизведённых багов в месяц. Ох уж QA-щики оторвались 😄
Правда потом этого доброго менеджера убрали. Без бонуса.
Правда потом этого доброго менеджера убрали. Без бонуса.
Так это задача QA - баги искать, количество найденных багов - один из критериев оценки их работы
Ох уж QA-щики оторвались
потом этого доброго менеджера убрали
в смысле, начали, наконец, находить баги?
Количество закрытых на оценку работы никак не влияло.
А вот кодеры дожны были на эти 90% шума тратить время, чтобы оценить и закрыть.
Так считать за минусами дублей, by design, not to be fixed, общее количество реальных багов и соотношение ко всем зафайленым. В QA как раз все просто
Так это задача QA - баги искать, количество найденных багов - один из критериев оценки их работы
Из оставшихся "прилежных" 90%, примерно для трети из их количества было бы для общего блага полезнее, если бы они ничего не вносили.
Ещё один тупорылый вариант считать производительность -- по количеству закрытых стори-поинтов в Джире.
Мне как-то на глаза попалась отличная статья о том как менеджмент попросил тим-лида уволить разработчика, который меньше всего стори-поинтов закрывал, дескать, зачем нам он такой малопроизводительный. Тот наотрез отказался, и вот почему.
Да, тот чувак закрывал мало тасок. Иногда вообще ни одной за спринт. Но он активно помогал в решении задач другим членам команды. Постоянно. День за днём. Каждому. И каждый же член команды признавал значимость вклада этого парня.
Вместо того, чтобы непосредственно обеспечивать деливери решений задач, "малопроизводительный" разработчик деливерил всю команду. А его уход неминуемо сказался бы на общей продуктивности.
Но для такого отказа менеджменту нужен не просто ум, нужна определённая мудрость. Которая есть не у всех лидов.
Мне как-то на глаза попалась отличная статья о том как менеджмент попросил тим-лида уволить разработчика, который меньше всего стори-поинтов закрывал, дескать, зачем нам он такой малопроизводительный. Тот наотрез отказался, и вот почему.
Да, тот чувак закрывал мало тасок. Иногда вообще ни одной за спринт. Но он активно помогал в решении задач другим членам команды. Постоянно. День за днём. Каждому. И каждый же член команды признавал значимость вклада этого парня.
Вместо того, чтобы непосредственно обеспечивать деливери решений задач, "малопроизводительный" разработчик деливерил всю команду. А его уход неминуемо сказался бы на общей продуктивности.
Но для такого отказа менеджменту нужен не просто ум, нужна определённая мудрость. Которая есть не у всех лидов.
В этой ситуации надо было тим лида увольнять нафиг. Он очень хреновый тим лид если менеджмент вообще не в курсе чем занимаются люди из его команды. Это он должен был "нарезать" консалтинг сторей тому девелоперу, согласовать эти стори с менеджментом, получить на это апрув и пинать того самого девелопера что бы он регулярно отписывался в сторе чем именно он сегодня занимался, кого консультировал и сколько времени потратил. Менеджмент был бы в экстазе, а тому деву может быть ещё бы и бонус прилетел за такой высокий уровень экспертизы, ноледж шеринг и коллаборацию.
Если мою работу измерять по коммитам, то я сильно отстаю от джунов, которых целыми днями инструктирую и консультирую, а также провожу с ними дебаг и code review, разгребаю их факапы и ошибки в конфигурации. И вообще, нафига применять количественные оценки в такой специфической области? Лучше дрючьте девелоперов за низкий coverage или падение pass rate в очередной регрессии.
за низкий coverage или падение pass rate в очередной регрессии.
Лучше дрючьте девелоперов за низкий coverage или падение pass rate в очередной регрессии.
низкий coverage???
Реально?
если у вас программистов дрючат за coverage - то нафиг такую контору
Реально?
если у вас программистов дрючат за coverage - то нафиг такую контору
если у вас
И вообще, нафига применять количественные оценки в такой специфической области?.
А за хреновый код или коммит сообщения - не дрючите?
Тут сильно зависит от того, как делается ревью. По-хорошему, надо вникнуть в задачу и подумать как ты бы сам ее сделал. Увы, обычно сводится к быстрому просмотру кода на предмет "тут O(n), а можно было O(1) или O(log n), тут нарушается SOLID" etc.
У большого бизнеса сейчас есть намерение прекратить эту удаленную работу и вернуть всех под крылышко менеджеров к кофемашинам и конфзалам. Одна компания за другой принимают такие решения. А люди в большинстве уже привыкли из дома работать. Бонусов много оказалось. Да и переехать многие успели. А нанятые недавно вообще не то что в офисе, в стране офиса никогда не были. Но материалов с удобными цифрами (как в той теме) в медиа встречается все больше. Есть ложь и есть статистика. Ей можно вертеть, как это выгодно заказчику.
Из того что я вижу все немного хитрее. Никто особо не хочет возвращать 100% офисный вариант работы. Вот гибридный вариант - это да. 40-60-80% времени удаленно, остальное из офиса. Но тут есть такое дело - за время полной удаленки многие компании просто сократили рабочее пространство в офисах, ну физически нет места для всех сотрудников единовременно. Восстанавливать офис до полной загрузки - очень дорого, и не факт что имеет смысл.
Восстанавливать офис до полной загрузки - очень дорого, и не факт что имеет смысл.
Святая наивность, что менеджеры всегда мыслят рационально и никогда не выстрелят себе в ногу.
Никто особо не хочет возвращать 100% офисный вариант работы.
Amazon kills remote working, tells workers to be in office 5 days a week
Ха... программисты ни хрена не делают. Аж целых 14%!
Ешкин кот.
Знаю несколько организаций, федеральных, государственных, где ни хрена не делают, и даже не скрывают этого, 80% сотрудников. Т.е. какие то бумажки перекладываются, что то происходит, какая то активность есть, но по сути они ни хрена не делают.
Ешкин кот.
Знаю несколько организаций, федеральных, государственных, где ни хрена не делают, и даже не скрывают этого, 80% сотрудников. Т.е. какие то бумажки перекладываются, что то происходит, какая то активность есть, но по сути они ни хрена не делают.
Аж целых 14%!
Совпадениенедумаю.
Таки вы из тех кто найдет "золотое сечение" в размерах стульчака ? 😄
Таки вы из тех кто найдет "золотое сечение" в размерах стульчака
Знакомый тимлид рассказывал - держат чувака в возрасте в штате по сути на должности эксперта, задачами он не загружен, кроме него есть кому кодить, но иногда возникают такие вопросы, которые решить может он и только он и достаточно быстро.
Как он сказал, что-то типа - он повышает уровень компетентности нашей команды.
Так что все эти исследования из серии - "британские ученые", жизнь - она намного сложнее.
Как он сказал, что-то типа - он повышает уровень компетентности нашей команды.
Так что все эти исследования из серии - "британские ученые", жизнь - она намного сложнее.
Вы не путайте разработчиков и методистов.
"британские ученые",
Вы не путайте разработчиков и методистов.
Станфорд в США.
Станфорд в США.
Стэнфорд, это которые за Газа против Израиля? 😉
Конкретно в Станфорде беспорядков не видел. Если ты про Колумбию, то там 1% был против политики теперешнего правительства Израиля.
и еще 69% против политики любого правительства Израиля?
"британские ученые",
Станфорд в США.
Станфорд в США.
не, исследование интересное, но, кмк, скорее показывает процент бесполезных отделов\отдельчиков\командочек, ибо во всех крупных конторах есть системы ведения проектов а-ля agile и т.п., то бишь, если задачи поставлены, то и коммиты должны быть (раз в месяц уж точно).
еще есть возможность, что анализировали не все репозитарии, типа пилит человек свою задачу в своем локальном репозитарии, а потом подмёрживает сорцы в глобальный.
еще есть возможность, что анализировали не все репозитарии, типа пилит человек свою задачу в своем локальном репозитарии, а потом подмёрживает сорцы в глобальный.
если задачи поставлены, то и коммиты должны быть (раз в месяц уж точно).
А вообще есть такой анекдот:
- Как только из параметра делают KPI, он перестает иметь отношение к реальной жизни.
- О, как это верно. У нас накопилась куча бессмысленных KPI, давайте их отменим!
(через месяц)
- В эту итерацию мы отменили на 20% больше бессмысленных KPI, чем в прошлую!
Считать KPI по количеству коммитов или количеству строчек кода - ежики кололись, плакали, но продолжали жрать этот кактус.
Лет 20 назад в одной крупной немецкой компании один добрый менеджер предложил гениальную идею (шокирующую своей новизной) как посчитать производительность девелоперов. А давайте, говорит, будем считать сколько строчек кода они в день барабанят. А давайте, весело отозвались топ менеджеры (и не замедлительно выписали доброму менеджеру, нет, не в бубен, а довольно крупный бонус за рац. предложение). Что на это сказали разработчики? А ничего не сказали, ухмыльнулись и давай развлекаться CTRL+C - CTRL+V и так весь день. В конце месяца посчитали, прослезились от умиления и осознания как все тяжело и усердно работают и всем выписали, нет, опять не в бубен, а бонусы. И так продолжалось какое то время пока на устройстве (а проект был под эмбеддед устройство где ресурсы ограничены) закончилось место и бинарь в него уже никак не лез. И тут топ менеджмент начала подозревать, что находится на пороге грандиозного шухера. Но появился еще один добрый менеджер и сказал, а давайте мы в Украину зааутсорсим задачи по оптимизации кода, мол слышал там ребята толковые и стоят крепко дешевше чем наши родные немецкие парни. А давайте, радостно отозвался топ менеджер и незамедлительно выписал, опять нет, не в бубен, а бонус этому доброму менеджеру. Вот так проект попал нашей команде. Нас спросили можете ли хоть за пол года что то с этим сделать? Мы ответили - можем за пол года, а вот за год - не справимся.. Надо бюджет расширять. В общем сделали за три месяца и нам выписали .... нет, не угадали, не в бубен, а бонусы.
Что бизнес хотел? Очевидно, улучшить производительность труда своих разработчиков. А что получил по итогу?
Лет 20 назад в одной крупной немецкой компании один добрый менеджер предложил гениальную идею (шокирующую своей новизной) как посчитать производительность девелоперов. А давайте, говорит, будем считать сколько строчек кода они в день барабанят. А давайте, весело отозвались топ менеджеры (и не замедлительно выписали доброму менеджеру, нет, не в бубен, а довольно крупный бонус за рац. предложение). Что на это сказали разработчики? А ничего не сказали, ухмыльнулись и давай развлекаться CTRL+C - CTRL+V и так весь день. В конце месяца посчитали, прослезились от умиления и осознания как все тяжело и усердно работают и всем выписали, нет, опять не в бубен, а бонусы. И так продолжалось какое то время пока на устройстве (а проект был под эмбеддед устройство где ресурсы ограничены) закончилось место и бинарь в него уже никак не лез. И тут топ менеджмент начала подозревать, что находится на пороге грандиозного шухера. Но появился еще один добрый менеджер и сказал, а давайте мы в Украину зааутсорсим задачи по оптимизации кода, мол слышал там ребята толковые и стоят крепко дешевше чем наши родные немецкие парни. А давайте, радостно отозвался топ менеджер и незамедлительно выписал, опять нет, не в бубен, а бонус этому доброму менеджеру. Вот так проект попал нашей команде. Нас спросили можете ли хоть за пол года что то с этим сделать? Мы ответили - можем за пол года, а вот за год - не справимся.. Надо бюджет расширять. В общем сделали за три месяца и нам выписали .... нет, не угадали, не в бубен, а бонусы.
Что бизнес хотел? Очевидно, улучшить производительность труда своих разработчиков. А что получил по итогу?
Что бизнес хотел? Очевидно, улучшить производительность труда своих разработчиков.
А что получил по итогу?
Вот в таком офисе - чья хотелка будет совпадать с "хотелкой бизнеса"?
Врядли бизнес хотел увеличения расходов на разработку аутсорся проект на удаленную команду, которая, по сути, сделала двойную работу. Нового функционала не появилось, устранялись только проблемы, которые были вызваны дуростью местного менеджмента.
Опять же, так будет если бизнес рационален. А чаще получается что не очень. Обычно старается - но получается не лучше чем рациональность людей в нем занятых. Если посмотреть на список когнитивных искажений (оцените хотя бы его размер на вики) - то, думаете, у бизнеса будет тенденция их скорее исправлять... или усугублять? Тут вон, как показали нобелевские лауреаты по економике, человек в своей собственной голове не особо может рацио вывести - а тут и людей много, и у них запутанные отношения, и общий шум высок. Так что сделанный вами проект (отдельный вам респект) - они вполне могут занести себе в плюсы. Сам удивляюсь как мы (человечество) еще не схлопнулись с таким подходом.
Кстати, если что - я как вы. Программист, тащу такой вот аутсорснутый в Украину проект. Тоже все счастливы.
Кстати, если что - я как вы. Программист, тащу такой вот аутсорснутый в Украину проект. Тоже все счастливы.
Классика.
Я в предыдущей инкарации прожил через несколько "оптимизаций расходов" в одном ныне несуществующем банке. Поскольку под "оптимизацией", без исключения, понимается сокращение кадров банк поручал ЖОРАМ и ЛОРАМ, сокращались только работающие и неудобные СУКи. И как неизбежен восход солнца уторм, так ровно через пол года после сокращения штат банка удваивался, просто чтоб поддержать производителность на том же уровне.
Я в предыдущей инкарации прожил через несколько "оптимизаций расходов" в одном ныне несуществующем банке. Поскольку под "оптимизацией", без исключения, понимается сокращение кадров банк поручал ЖОРАМ и ЛОРАМ, сокращались только работающие и неудобные СУКи. И как неизбежен восход солнца уторм, так ровно через пол года после сокращения штат банка удваивался, просто чтоб поддержать производителность на том же уровне.
И что, меньше 3 коммитов в месяц - это уже ничего не делать? Ну офигеть теперь.
Это шож получается, целую среду работать?! (с) анкедот
Ну я по такому принципу и работаю вообще-то 😅
Но очень напрягает и расстраивает бездельничанье. Так что большая часть усилий уходит именно на переживания по этому поводу.
Но очень напрягает и расстраивает бездельничанье. Так что большая часть усилий уходит именно на переживания по этому поводу.
Три коммита в день - это нормально. Хотя и не всегда возможно
Три коммита в месяц - это странно
Три коммита в месяц - это странно
Здесь мерилом работы считают усталость.
По коммитам считать - такое себе.
Но как база потянет.
Да и корректно выглядит: в офисе работают лучше.
Но как база потянет.
Да и корректно выглядит: в офисе работают лучше.
Да и корректно выглядит: в офисе работают лучше
Отнюдь. В офисе просто нечего делать, кроме работы.
Кофе пить, новости читать, с коллегами болтать. То же самое, что и дома, но плюс личное общение.
В общем, везде хорошо. Я лично не заметил разницы между производительностью, она больше от интереса зависит, чем от местонахождения. И да, дома не тратится час на дорогу.
Потому что дома есть другие дела и никто тебя не контролирует, даже морально
Потому что дома есть другие дела и никто тебя не контролирует, даже морально
Теги
Информация
Что ещё почитать
