Size: a a a

Teamlead Bootcamp

2021 June 02

PD

Phil Delgyado in Teamlead Bootcamp
А при чем тут нетфликс?
Миграции - это штука, которую нужно упомянуть в design review. И все.
Реализуется обычно как пара строчек на flyway, но иногда - сложнее. Иногда - много сложнее и надо эксплуатации рассказать.
источник

S

Sergey in Teamlead Bootcamp
Миграции чего? Рдбмс?
источник

PD

Phil Delgyado in Teamlead Bootcamp
Любых db, почему только реляционных?
источник

S

Sergey in Teamlead Bootcamp
Понял, не знал
источник

PD

Phil Delgyado in Teamlead Bootcamp
Ну, стандартная штука, была коллекция, стал кортеж. Тут уже не просто "колонку пустую добавить", тут нужно данные перетряхнуть.
И такие штуки надо уметь делать кусочками (один запрос упадет по памяти и заблокирует все нафиг), следить за их статусом, проверять полноту, учитывать сервисам и т.п.
Для rdbms есть liquidbase и flyway, для nosql надо свое обычно писать.
Впрочем, у flyway куча ограничений, так что все равно лучше свое писать.
источник

PD

Phil Delgyado in Teamlead Bootcamp
Ну и вот если человек пишет свои первые 20 tech design - ему нужно на что-то опираться  и тут чеклисты - очень помогают.
Как и примеры (надо будет добавить в доклад, кстати) "хорошего" и "плохого".
источник

PD

Phil Delgyado in Teamlead Bootcamp
Разработчик вообще должен думать только над важным.
Все, что можно убрать в инструкции, чеклисты, автоматизацию - должно быть туда убрано.
источник

S

Sergey in Teamlead Bootcamp
+
источник

S

Sergey in Teamlead Bootcamp
Кстати, как относишься к кросс командному ревью? Меряешь как-то процесс ревью в своей команде/командах? Если да, то какими линейками?
источник

PD

Phil Delgyado in Teamlead Bootcamp
Это разные вопросы.
1. Я вообще плохо отношусь к обязательному code review, это как раз про "заставлять программиста думать про неважные вещи".
Кросс-командное - тут тоже не нужное
2. Иногда (часто) полезно кросс-командное review-on-demand или seagull-review (например кого-то из старших членов гильдии)
3. review процессов вне команды смысла обычно не имеет, так как процессы выстраданы конкретной командой.
Тут скорее коучинг лидов имеет смысл, им занимаюсь время от времени, как у себя в компании, так и в других компаниях.
источник

PD

Phil Delgyado in Teamlead Bootcamp
Линейки и метрики в разработке - обычно приносят больше вреда, нежели пользы.
То, что можно очевидно померить деньгами - меряю (кстати, на CodeFest был хороший доклад Виталия Шароватова про TЭО, советую послушать), что нельзя - ну и нафиг
источник

S

Sergey in Teamlead Bootcamp
Есть вот ещё такой вопрос наболевший у меня, если не сложно - буду рад послушать твой алгоритм действий

https://t.me/tlbootcamp/26896
источник

PD

Phil Delgyado in Teamlead Bootcamp
Это к Виктору, скорее.
Но, классический первый вопрос - "а что такое лоуперформер и как ты это определил"?
источник

S

Sergey in Teamlead Bootcamp
А после коучинга лиды всё равно занимаются 3-м пунктом
По поводу линеек не согласен, могут быть выбраны не те линейки, просто
источник

PD

Phil Delgyado in Teamlead Bootcamp
А зачем им ревьюить процессы друг друга? Советовать -да. Обмениваться личным опытом или обсуждать проблемы - да. Но это скорее про работу гильдии, нежели про review
источник

PD

Phil Delgyado in Teamlead Bootcamp
Я еще не видел ни одной приличной линейки. Хотя показывали мне много разных.
источник

PD

Phil Delgyado in Teamlead Bootcamp
Я вот не смог найти никаких обоснований этой модели, честно говоря.
И ее смысл мне не очевиден (как и большей части "моделей" в менеджменте - которые не модели, а в лучшем случае классификации)
источник

S

Sergey in Teamlead Bootcamp
Хороший вопрос, в моём понимании лоуперформер - человек, который выполняя схожий тип задачи/работая в этом домене и постепенно аккумулирует экспертизу выполняет задачи с такой же скоростью/качеством или даже хуже. Это трудно заметить на этапе формирования и стабилизации команды, но становится отчётливо видно при переходе команды в режим мустанга и выпаданию этого человека из колеи.
источник

PD

Phil Delgyado in Teamlead Bootcamp
Тут дофига причин.
От "ему не хочется работать в этой команде", "ему не хочется работать в режиме мустанга" до "выгорел".
А дальше - разные варианты
1) иногда производительность - не самое важное свойство. У меня в одной команде был очень слабый разработчик (и без роста), но он очень хорошо влиял на всю команду (коммуникации, шутки и т.п.) - и полностью окупал свою зарплату.
2) иногда рост - не важное свойство. У меня был сотрудник, который не рос, но был готов писать отчеты (которые прочим писать было лень, слишком одинаковые). Он это делал медленно и не очень качественно, но зато я мог переключать ресурсы других разработчиков на другие задачи и не давать им "демотивирующие" задачи.
3) иногда более медленный рост демотивирует прочую команду - и тогда надо расставаться.

Вообще покрути команду в разных срезах, посмотри, как можно получить эффект от конкретного сотрудника. Если никак, найм будет эффективнее и окупиться с учетом онбординга и мотивационных факторов - то прощайся.
источник

PD

Phil Delgyado in Teamlead Bootcamp
Но ты, кстати, ругаешься не на производительность, а на медленный рост этой производительности )
Это довольно высокие требования, за них изрядно доплачивают...
источник