Ну ок, т.е. была/есть цель - стать мидлом. Но нужен еще план как достичь этой цели. Я бы даже сказал чек-лист. Так будет проще и нагляднее. Например, список тем/технологий, которые надо изучить/пощупать.
Есть такое?

Да это все условно, и везде по своему. В каких то конторах есть грейды, кипиай и прочая шляпа.

Мне кажется, такой чек-лист может быть:
1. Совпадает ли запланированное время/прогноз/оценка задачи (фичи) с результатом?
1.1 Или совпадает порядок произведенной оценки с результатом (два часа вместо часа - совпадает, день вместо часа - не совпадет)?

2. Срочный поиск бага в прод среде - удается ли переключиться с текущей задачи на это?
Найти проблему (смотреть большие файлы логов, на тестовом стенде воспроизвести или локально, аналитически в IDE, если прод среда прям уникальная)?
Приходилось ли искать? Приходилось ли потом деплоить фикс?

2.1 Что делать, если после релиза вашего сервиса проблемы - должно работать, но не работает, не должно работать, но работает? ))

3. Релизы, ветки - есть понимание, как готовятся релизы, какая методология используется для веток?
3.2 Удается ли делать хорошие чистые коммиты, без докоммичевания :)

4. В некоторых непонятных ситуациях лучше залезть в исходный код фреймворка, вместо того, чтобы гуглить, согласны? Лазили туда?

5. Знаете как на текущей работе с нуля оформить новый проект/модуль/сервис - кому что написать, коллегам, админам, devops, завести репозитории,
запушить заготовку проекта, выдать/получить права, завести страничку в конфлюенс

Неа, ибо я не очень понимаю что ДОЛЖЕН знать миддл

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

Пойдёт и спросит, достучится до бизнеса. Пошарит в бэклоге. Займётся рефакторингом, который давно откладывал. Таски всегда найдутся. Другой вопрос, что какую-нибудь дичь дадут.
В крайнем случае всегда можно поискать интересные таски в другой компании, если в этой всё так плохо 😉
Вообще какое-то инфантильное представление о работе программиста. Как будто это машина какая-то и софт скиллы мама с собой на работу не положила.

Там в оригинале написано, что Сеньеру вообще ничего говорить не надо, я про это. Ходить и достукиваться это не проблема программиста в нормальной компании, скорее бизнес аналитика, куда ты пойдешь если ты заказчика фичи не знаешь даже? На деревнью к дедушке? Софт скиллы это сказочки для около IT тусовочки, понятно что любой нормальный человек может коммуницировать в рабочем процессе с остальными участниками процесса. Если этого нет - то скорее всего это тяжелая форма аутизма и получить работу с таким заболеванием врядли возможно.

Наверняка выше уже ответили, но код ревью — это не только и не столько контроль, но и знакомство с кодом всех участников. Это на самом деле основная цель в командах больше 2-3 человек.

Там в оригинале сарказм если что. А ты его похоже не различил и бомбишь тут)
И не надо со мной спорить про процессы в компаниях. Они разные бывают, да и критерии нормальности у каждого свои.

Не, ну конечно с 20 летнии школьником какие могут быть споры.

Ну там контроль скажем чисто психологический, что человек зная, что кто-то обязательно посмотрит не станет гнать откровенную лажу. А так абсолютно верно это инструмент вовлечения остальных разработчиков в эволюцию кода. Ну так почестному, в команде из хотя бы 10 человек, прямо каждый станет смотреть, что там сосед накоммитил? Думаю, что нет 😁

А ты далеко пойдёшь 🤠
Успехов там!

ну для вовлечения других разработчиков в код есть другие инструменты. Просто можно давать задачи из разных областей. Например, Петя писал админку, а Вася апи для внешних партнеров. Когда поступают задачи по админке — даем их Васе, а Пете задачи по апи. Все довольны, знают код проекта.

если код писался без ревью, то могут быть недовольны

В школостартапах так и есть

ревью делает старший разработчик/лид у кого эта опция прописана в должностных обязанностях

в школостартапах как раз скрам и отсутсвие иерархии. Так как в большинстве случаев задача таких стартапов освоить бюджет а не выпустить мвп

Понятно

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

Поясню, если Петя шарит в финансах то садить его на таски Васи который шарит в биг дата это не комильфо. Это как проктолога отправить на пару недель на место дантиста. Ну так тепо чтобы не расслабляйся.

Тут согласен совершенно.

Но также провести ревью кода того чувака  который шарит в чем то сложном может только тот, кто в этом разбирается. Но бывают задачи не сильно сложные/спецефические, просто из разных областей проекта. Тут как раз смена направления может помочь.