Как по мне проблема не в слове «Senior», а в слове «программист».
В реальной инженерии специализация выше и она не вызывает недопонимания, вот наиболее распространённые роли в инженерном проекте:
есть «Главные инженер проекта» или «Системный инженер», который отвечает за целостность проекта;
есть «Архитектор» или «Дизайнер (Design)», который создаёт общее видение проекта, он отвечает за такие требования, как «мост вписался в архитектуру города», «оборудование было удобным», «в этом доме люди хоте ли бы жить»;
есть узкие специалисты, «Проектировщики», «Конструктора», «Технологи», «Сметчики», которые разработают вам варианты реализаций в соответствии с требованиями и посчитают стоимость.
Почему в вашем мировоззрении всё упростилось до программист? Почему Вы в таком окружении, где всё упростилось до программиста?
Повесьте сами себе лычку которая вам подходит: Backend C# Programmer Expert или Professional Backend C# Coder.
Только реальность не поменяется.
Цикл разработки всё равно будет начинаться со стадии разработки требований, кто-то должен уметь в инженерию требований.
В сложный системах всё равно кто-то должен удерживать целостность архитектуры.
Без специалистов, которые могут написать эффективный, поддерживаемый, надёжный код, шансы закончить большой проект стремятся к нулю.
Без специалистов, которые могут обеспечить надёжную инфраструктуру, сконфигурировать сети, спроектировать базы данных, шансы проекта работать стремятся к нулю.
Без специалистов, которые создадут удобный пользовательский интерфейс, шансы, что кто-то будет пользоваться созданным продуктом, стремятся к нулю.
Как человек может не понимать, сколько специальностей нужно задействовать, чтобы ему построили загородный дом, так и отдельно взятые руководители в бизнесе могут не понимать сколько специальностей нужно задействовать, чтобы обеспечить им ИТ-систему.
Мир на столько большой и разнообразный, что переживать, что где-то он не такой как Вам нравится, это упускать время на поиск своего идеала.
Егор Бугаенко пытается пошатнуть это «по-другому никогда не будет» с помощью проекта 0crat.com
Так как IT большое и разное, то, мне кажется, будут иметь место много разных процессов найма и работы, и индустрии ещё есть что попробовать.
В видео докладе есть важная оговорка, типа «было бы круто, если бы была возможность пустить всех пришедших в бой, и потом оставить только тех, кто „коммитит“. так как такой возможности нету, то вот так вот...»
слишком тонко =)
явно выдвать мысль о «не смешивать автора и его идеи» и через мгновение показывать, как человек перенес критику идеи и взгляда на вещи в личное оскорбление.
Есть такая дисциплина System Engineering, описывает практики для «больших и сложных проектов», за ней стоит организация INCOSE, она выпускает handbook, в котором можно почерпнуть много интересных техник/методик/идей/подходов. И всё из разряда «здравого смысла» =)
Меня лично интересует версия для C#.
В какой-то мере было бы достаточно сервиса: ввел в форму открытый репозиторий, получил на почту отчет об анализе.
Или в виде дополнения/расширения/плагина к Jenkins/Travis/Azure DevOps.
В реальной инженерии специализация выше и она не вызывает недопонимания, вот наиболее распространённые роли в инженерном проекте:
есть «Главные инженер проекта» или «Системный инженер», который отвечает за целостность проекта;
есть «Архитектор» или «Дизайнер (Design)», который создаёт общее видение проекта, он отвечает за такие требования, как «мост вписался в архитектуру города», «оборудование было удобным», «в этом доме люди хоте ли бы жить»;
есть узкие специалисты, «Проектировщики», «Конструктора», «Технологи», «Сметчики», которые разработают вам варианты реализаций в соответствии с требованиями и посчитают стоимость.
Почему в вашем мировоззрении всё упростилось до программист? Почему Вы в таком окружении, где всё упростилось до программиста?
Повесьте сами себе лычку которая вам подходит: Backend C# Programmer Expert или Professional Backend C# Coder.
Только реальность не поменяется.
Цикл разработки всё равно будет начинаться со стадии разработки требований, кто-то должен уметь в инженерию требований.
В сложный системах всё равно кто-то должен удерживать целостность архитектуры.
Без специалистов, которые могут написать эффективный, поддерживаемый, надёжный код, шансы закончить большой проект стремятся к нулю.
Без специалистов, которые могут обеспечить надёжную инфраструктуру, сконфигурировать сети, спроектировать базы данных, шансы проекта работать стремятся к нулю.
Без специалистов, которые создадут удобный пользовательский интерфейс, шансы, что кто-то будет пользоваться созданным продуктом, стремятся к нулю.
Как человек может не понимать, сколько специальностей нужно задействовать, чтобы ему построили загородный дом, так и отдельно взятые руководители в бизнесе могут не понимать сколько специальностей нужно задействовать, чтобы обеспечить им ИТ-систему.
Мир на столько большой и разнообразный, что переживать, что где-то он не такой как Вам нравится, это упускать время на поиск своего идеала.
Так как IT большое и разное, то, мне кажется, будут иметь место много разных процессов найма и работы, и индустрии ещё есть что попробовать.
явно выдвать мысль о «не смешивать автора и его идеи» и через мгновение показывать, как человек перенес критику идеи и взгляда на вещи в личное оскорбление.
В какой-то мере было бы достаточно сервиса: ввел в форму открытый репозиторий, получил на почту отчет об анализе.
Или в виде дополнения/расширения/плагина к Jenkins/Travis/Azure DevOps.