nozd up

Начнем с того, что мидл должен знать как минимум то же, что знает джун.

Для джуна это систематческие знания CLR и c#. Лучше всего прочитать и понять CLR via C# Джеффри Рихтера. Я считаю - это минимум.

Джун находится на уровне неосознанной неосведомленности. Это значит, что за ним нужно присматривать.
Джун может даже не знать, как задать нужный вопрос. Если от человека в проекте больше вопросов, чем ответов - это джун.

Мидл отличается от джуна практическими навыками и опытом. Это самостоятельное решение прикладных задачь и навыки командной работы. Мидл находится на уровне осознанной неосведомленности. За ним присмотр не нужен - он сам умеет определять границы своей компетентности. Для мидла количество вопросов примерно равно количеству ответов.

Сеньор отличается от мидла тем, что способен самостоятельно реализовывать проекты с нуля и до feature complete, включая налаживание инфраструктуры разработки и управление проектом, обслуживание приложения в производстве.
Сеньор может обучать других, не говоря уже о том, что эффективно решает более сложные задачи. Сеньор находит системные решения. Если сеньор не может предложить решение задачи, то, скорее всего, человечество еще эту задачу не решило. Для сеньора количество ответов сильно превышает количество вопросов. Сеньор иногда делает вещи, которые причиняют непоправимую пользу не только в рамках проекта, но и всему человечеству, такие как хорошие опенсорсные фреймворки.

Выполните в консоли monitorEvents(document.body); Увидите все события по мере их появления. Если надо фильтровать - второй аргумент для этой функции: monitorEvents(document.body, 'click'); - покажет все клики.

Архитектор - в первую очередь опыт работы, в идеале в разных проектах, чтобы понимать на практике разницу между реализацией разных SDLC.

Название Waterfall или Scrum - это просто названия без конкретной реализации. Можно реализовать отличный Waterfall и все будут довольны, можно реализовать ужасный Scrum и все развалится. Поэтому опыт разных проектов помогает увидеть именно разные реализации.

Архитектор, бизнес-аналитик и менеджер - три звена, которые создают основу работы проекта, каждый со своей стороны.
Бизнес-аналитик - должен максимально разбираться в бизнесе заказчика, чтобы понимать значение требований и переводить их для исполнителей.
Архитектор - должен как минимум немного разбираться в бизнесе, но его основная задача - решить как воплощать требования бизнеса. Определять железо, технологии, требования. Говорить, что "вот для этого нужно использовать 10 этого и 20 этого, и использовать вот такие языки, библиотеки, платные решения". Техническое hi-level видение проекта.
Менеджер - по согласованию с бизнес-аналитиком и архитектором должен решать кадровые вопросы. Количество людей, качество людей, работу команды, тайминги, офис и оборудование - все денежные вопросы. Отчеты. Договариваться, убеждать заказчика о ценах и сроках. Выбивать новые задачи и развивать проект. Следить за настроением в команде.

Переход программист-архитектор не всегда последователен. Он должен быть инициирован программистом.

Программист может остаться просто сеньор программистом, может стать тим-лидом, тратя часть времени на менджмент команды но все-равно основную часть времени оставляя на кодинг.

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

я бы для начала почитал про чудо-команду EXPLAIN

Да, программист - не так романтично на деле, как кажется)
Потому что, в отличии от всяких мечтаний, в реале вопрос завязан на деньги, а деньги - на время.
Программист работает на заказчика, заказчику нужно быстро и дешево - отсюда готовые решения и костыли сейчас, с прицелом разобрать это потом (но потом тоже костыли)
Поначалу все это очень напрягает и срывает башню - нас учили не такому, нас учили стремиться к простому и оптимальному коду, а везде вокруг накручивают дичайшие костыли, и это жесть, но...
Со временем понимаешь, что лучше сейчас быстро сделать костыль, и забыть об этом, возможно навсегда, чем потратить времени в 3-4 раза больше, но сделать по канонам... Просто у программиста нет столько времени...
В конце концов в реальности работа программиста не так сложна, и во многом не так красива, как ожидается - по большей части это рутина и разгребание чужого страшного кода, отладка и ваяние своего страшного кода, сожаление о том, что не было возможности сделать хорошо, и радость, когда попадается что-то интересное, или то, что сделал хорошо, качественно
Как и на любой работе, есть свои светлые и темные стороны. И деньги не так легко достаются - программист за них щедро платит нервами. Как и врач, и любой другой специалист

Значит так, берем толстую тетрадь, ручку и пишем фразу "Статические методы не имеют отношения к ООП" до тех пор, пока не запомним это на всю жизнь.
Суть объектно ориентированного программирование, как понятно из названия, заключается в том, что должен существовать объект. Статика существует не в контексте объекта, а в контексте класса! Из этого вытекает то, что на протяжении всего жизненного цикла вашего кода будет существовать лишь одно глобальное состояние статических членов класса.

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

Есть ли у статического варианта какие-то подводные камни

Большое количество. При чем, не таких уж и подводных. Из-за того, что статика глобальна, она плохо поддается тестированию, ее нельзя замокать. Глобальное состояние плохо поддается отладке. Отсутствует возможность подменить реализацию, так как это позволяют сделать объекты.

1. Ну, `List` не потокобезопасен. Для избежания Kernel-mode constructs (`lock` и пр.) можно попробовать потокобезопасные ConcurrentQueue или ConcurrentStack в System.Collections.Concurrent, если заполнение до чтения (а не вовремя). Наполняете, вызываете GetEnumerable, который делает снэпшот коллекции, сравниваете. Чтение должно происходить без блокировки.

2. BlockingCollection для проблемы producer-consumer, когда одновременно чтение и запись. Я так понял это не входит в задачу.

3. Если вы не изменяете, то и блокировать не нужно. Вне зависимости от reference или value type. (Конечно, через стэк лучше, если изменяете. Тогда копия для каждого потока своя.)

По теме можно Рихтера почитать, CLR via C#, 10 глава, Asynchronous Synchronization и The Concurrent Collection Classes