Херовимчик wrote: ↑02 Jan 2022 04:49
Давайте все же разделять идею/подход от частных (неудачных) способов исполнения.
Это вполне известный факт, что производительность хорошей команды в разы превышает сумме производительности каждого члена команды. Взять Хрюнделя - у него нет слаженной команды, каждый сам за себя и производительность меняется на индивидуальном уровне. Прибытие или убытия бойца он влияет на производительность остальных членов команды.
Отдельные случаи неудачного парного программирования тоже сложно натягивать на подход в целом. Первый блин может быть комом, не все люди «кликают» друг с другом и т.д. Это тоже нужно делать с умом, а не брать первого попавшегося джуна и айда его учить (это кстати к менторству мало имеет отношение, менторы это вообще о другом).
Всем известный multiplier или 10х инженер, условно, не закрывает в 10 раз больше тикетов чем его коллега. Сеньор инжинер грамотно менторит джуниоров (так чтобы они росли и учились думать, а не просто как мартышки поворяли), задает тон для других Сеньоров (хорошее сопровождение кода, юнит тесты, да хоть комментарии в коде!), вкладывается в тулы для всей команды. Да даже банальный рефакторинг освободит кучу ресурсов у всей команды. По отдельности это все мелочи, но из каждой мелочи складываемся та самая engineering culture в команде. И когда в неё вкладываются толковые люди, производительность вырастает у всех
Эх, ещё все бы менеджеры умели считать и понимать эти самые комменты в пул риквестах и прочие вещи.
Идея понятна. А исполнение всегда интересно посмотреть. Помнится и вы здесь спрашивали, как проходит pull request reviews у остальных.
Так что любой подход имеют и плюсы и минусы и сторонников и противников.
Прекрасно помню, как человек ушедший из гугла в нетфликс рассказывал, что для него это небо и земля. Мол в гугле на пул риквесте так мозг выносили и убивали любую инициативу, если не понимали ее. Ну и в коде мол муха не пролетит да. Но зато, говорил, в Нетфликсе его наняли как эксперта, дали продукт, и он там царь и бог. Сделал все по уму? Может потчевать на лаврах. Падает сервис? Будут фиксить с овертаймами, но чисто свои косяки.
Тут уже кому что, во втором случае например нетфликс может выбросить человека на улицу, как Хрюндель. Кстати на этот момент Хрюндель собственно и рефлексанул. Пока нетфликс существует. Как и компании с другим подходом.
Пс. Ну и я не понял, что вы хотели сказать таки. «Прибытием или убытием бойца, он влияет на остальных членов команды». А как ещё? Если убытие бойца ни на что не влияет, то он был лишним. Явно лишним. В корпорациях такое нередкость. Как по мне, в нормальной ситуации команда должна быть способна перераспределить нагрузку, но либо до найма, либо боец был лишним. Не особо понимаю, как красивый код может решить проблему нехватки людей. Причём опять же если вернуться к примеру с нетфликсом, то для одного чела красивым код будет тот, который он написал
Точно также встречал немало воин разных schools of thoughts. Например в swift можно писать интерфейсы и реализацию как в одном файле, так и в разных. Если у вас в коде один интерфейс реализует несколько классов, то логично, что сам интерфейс лучше положить в отдельный файл. И каждый класс в личный фаил. Если этого нет и наврятли планируется. То держите интерфейс и реализацию в одном файле, чтобы не прыгать по файлам, когда читаете код. Но были другие товарищи, которые считали, что интерфейс всегда должен лежать в отдельном файле. И вот очень забавно наблюдать как люди, занимаясь красотой, туда сюда это дело меняли, ведь архитекторов не один человек в корпе. И в то же время менеджеры, давшие более сложный вопрос архитектору занятому восстановлением справедливости, рефлексовали и просили сениоров тоже посмотреть, почему такой то вопрос не решён, создавалась ситуация, когда приходилось лезть сениору в огород архитектора, который этому был не совсем рад. Скорее демотивирован. Тут можно петь о том, что архитектор должен быть рад взаимовыручке. По стилю должны составить правила и придерживаться им. Но с правилами, во первых однозначного ответа нет, во вторых, так постепенно создаются рамки, убивающие инициативу.
Но собственно поэтому в Америке так развита культура стартапов. Которыми Хрюндель с его слов и занимается. Очень удобно отдавать стартапам эксперименты на откуп без всей этой корп бюрократии, ограничительных рамок спущенных сверху и раздутых команд. А вот если эксперимент заканчивается успехом, то они быстро превращают это в корп с другой командой
Если от ухода кого-то КПД команды не страдает, то или он действительно там был не нужен, либо команды нет вообще (просто группа независимых контрибьютеров) 
пожалуй единственный плюс WFH