O
А ты об этом никогда не говоришь:)
Size: a a a
2021 March 09
A
Не нужно то да. А если хочется?:)
раньше в польше не было проблем с этим
O
раньше в польше не было проблем с этим
Я в американской компании. В cdproj думаю бьют, я как то общался с ними, они прям грустные были и очень напряжённые.
O
Но вообще ты идеалист конечно. Твои методы классные, но всегда надо иметь в виду правило 0 - они действуют только на хороших специалистов, которые от них становятся еще лучше.
Мне кажется у большинства прям болит в случае полного непонимания субъектами ситуации. И вот тут уже все становится на порядки сложнее.
O
Ну то есть они из этой Борды сделают любые выводы, кроме нужных.
O
Хотя визуализация конечно важна и идея то сама по себе огонь:)
SS
не нужно никого бить. нужно ограничить фантазию рамками интерфейса и добавить тулинг в пайплайн для оценки качества
пока тулинг не фейлит мерж на него никто смотреть не будет
IV
Но вообще ты идеалист конечно. Твои методы классные, но всегда надо иметь в виду правило 0 - они действуют только на хороших специалистов, которые от них становятся еще лучше.
правила работают для всех - хорошего специалиста еще нужно создать.
джунов и миддлов в команде больше чем сеньоров и именно поэтому так заморачиваюсь всем что связано с dev productivity
джунов и миддлов в команде больше чем сеньоров и именно поэтому так заморачиваюсь всем что связано с dev productivity
O
правила работают для всех - хорошего специалиста еще нужно создать.
джунов и миддлов в команде больше чем сеньоров и именно поэтому так заморачиваюсь всем что связано с dev productivity
джунов и миддлов в команде больше чем сеньоров и именно поэтому так заморачиваюсь всем что связано с dev productivity
Джун != плохой специалист.
A
пока тулинг не фейлит мерж на него никто смотреть не будет
у игоря как раз была противоположная история недавно
O
Если что, в думаю твоя выборка просто в целом лучше средней по людям. Может даже сильно лучше. И уж точно фатально лучше «тяжелой ситуации».
O
Всмысле я у этому все написал, в не к методам самим по себе.
IV
нас и берут на работу чтобы тяжелых ситуаций не было
VI
пока тулинг не фейлит мерж на него никто смотреть не будет
а когда зафейлит - придут с вопросом как это скипнуть потому что деплой блочит )
O
нас и берут на работу чтобы тяжелых ситуаций не было
Поэтому вы крутые)
SS
а когда зафейлит - придут с вопросом как это скипнуть потому что деплой блочит )
вот именно. я вчера смотрел презентацию фейсбука, как они перфоманс трекают, там все очень круто, но они вообще не объяснили, что собсно происходит, когда находят регрессию. разработчик просто скажет - а мне надо и все 😂 то же самое с этими метриками
ИМ
нас и берут на работу чтобы тяжелых ситуаций не было
блин вот только как показывает практика, некоторые берут но не понимают зачем =)
IV
а когда зафейлит - придут с вопросом как это скипнуть потому что деплой блочит )
у нас так - когда sonar не пропускает через quality gate, а деплой блочит, то нужно подойти к специально обученному человеку и попросить сделать исключение. затем специально обученный человек вносит новую запись в расшаренный spreadsheet который называется TECHNICAL DEBT (описание проблемы + риски и их impact) и нажимает на кнопку “skip quality check”.
SS
у нас так - когда sonar не пропускает через quality gate, а деплой блочит, то нужно подойти к специально обученному человеку и попросить сделать исключение. затем специально обученный человек вносит новую запись в расшаренный spreadsheet который называется TECHNICAL DEBT (описание проблемы + риски и их impact) и нажимает на кнопку “skip quality check”.
а дальше?
DS
у нас так - когда sonar не пропускает через quality gate, а деплой блочит, то нужно подойти к специально обученному человеку и попросить сделать исключение. затем специально обученный человек вносит новую запись в расшаренный spreadsheet который называется TECHNICAL DEBT (описание проблемы + риски и их impact) и нажимает на кнопку “skip quality check”.
главное, чтобы потом при аудите эти исключения имели обоснования