Comments 82
В моём уютном мирке бэкенд программистов отдельно взятой компании, получилось, что сеньор - это человек, которому можно доверить задачи уровня проекта. Он сам вытянет нужные знания, пнёт нужных людей (типа аналитика), согласует с заинтересованных лицами (в рамках договорённостей) и доведёт задачу до завершения так, что не придётся переделывать.
Грубо говоря сеньор - это мидл + софт скилы + умение делать проекты.
В наших болотах сеньор - это нечто условное. Ибо штатное расписание имеет немного больше градаций - разработчик - старший разработчик - ведущий разработчик - главный разработчик. И сеньор - это скорее ведущий и главный, хотя и мидл может быть как старшим, так и ведущим, а бывают и джуны на ставке старшего...
Но разработчик напрямую с заказчиками (бизнес-линии) не общается практически. Это задача аналитика. Да, бывает что разработчика приглашают на встречи аналитика с бизнесом, бывает что разработчик напрямую общается с "консультантом направления" (это уже не совсем аналитик, но еще и не совсем бизнес).
Есть говорить про разницу между мидлом и сеньором, то она прежде всего в том, что сеньор - это, как правило, еще и техлид. Т.е. человек, более-менее ориентирующийся в предметной области (той ее части, которая обращена к разработке). Т.е. сеньору не надо в ТЗ расписывать что и как с чем связано - он сам понимает по каким таблицам эффективнее построить отбор нужных данных (как пример). Еще и рекомендации даст - вот тут индекс добавить, там витрину лучше бы организовать.
Но из этого, также, следует и то, что сеньор "контектснозависим" - со сменой области деятельности или даже направления (команды), он на какое-то время перестает быть сеньором (как это ни парадоксально) в данной конкретной области (до тех пор, пока не вникнет в нее).
А вообще, все эти лычки такая условность... Никогда не позиционировал сябя в этих градациях. Исключительно как "разработчик", "есть опыт в том-то и том-то", "умею то-то и то-то". А там хоть клизмой назовите, только в ... не суйте.
"А вообще, все эти лычки такая условность" пока работаешь за еду да.... а вот если хочется хорошей ЗП
Если хочется хорошей ЗР, надо не лычкой трясти, а что-то реально уметь и знать.
Повторюсь - лычка - это внутри конкретной компании/проекта. Перейди на другой проект и лычка слетит мигом. Если, конечно, это не типовое формишлепство где в общем-то все равно - инетлабаз и порносайт клепать.
А там где сложная логика какая-то - там уже в предметной области ориентироваться надо. Или что-то системное - надо платформу знать.
Понятно, что если опыт большой в близких областях, то и адаптация быстро пойдет. Но сразу прийти и моментально во все вникнуть - так не бывает.
Так что лычки - это так, ЧСВ почесать.
и отчего же на собесах в FAANG уровень определяют по алгоритмам и архитектурному дизайну, а не по знанию какой-то предметной области??? И навешивают лычку и денег отвешивают соответственно
А что, мир ограничивается фаангом?
Ну придите к нам с лычкой фаанга - будет джуном бесплотным. Потому что ни платформы, на которой работаем, ни стека вы точно не знаете. Дай вам задачу конкретную - не сможете тривиально определить какие таблицы как связать и в каком случае какой подход использовать.
Пойдете в промавтоматизацию какую - там вообще все свое. Там с вас спросят знание потрохов всяких RTOS, и протоколов обмена (тот же MODBUS и иже с ними). И фаанговские лычки там не канают.
В любом месте вас будут спрашивать то, что потребуется в работе там. И вешать соотв. лычку. А в другом месте потребуется что-то совершенно иное. Соотв. и спрос иной.
Да даже в том же гугле направлений более чем. Всякие веб приблуды - только одно из них. А как у вас с системной разработкой? Ядро того же андроида писать на уровне сеньора потяните? А теорию компиляторов учили (то же GO пилить)? Пройдете собес?
И по алгоритмам, и по знанию предметной области, чем выше уровень кандидата, тем больше уклон в предметную область. Лычку дают локальную для локального же референса, которая не переходит в другие фаанг кампании.
Поработав с разными рынками, пришел к выводу, что в каждом макрорегионе понятия Джуна/Миддла/Сеньора могут отличаться настолько значительно, что общение нужно начинать с установки некоей системы мер и весов в организации/проекте. В некоторых странах считают, что после трех лет работы человека почти обязательно надо назвать сеньором.
Плюс, постоянный инфошум от многочисленных курсов тоже значительно девальвировал ценность каждого уровня. 10+ лет назад было нормально, когда после обучения работник считался интерном (и это не звучало уничижительно), но когда из каждого утюга вещают про "с нуля и до мидла", статусы джун и интерн уже воспринимаются чуть ли не как оскорбление.
Мидл требует присмотра, а синьор — полностью автономен
Вот. На мой взгляд - это правильное описание сеньёра. Самостоятельность и ответственность, а не чушь типа
что он может быть потенциальным замом тимлида
и прочих, прости господи софт - скилов. Сеньёр не исчезнет на неделю, а потом окажется, что он ничего не сделал, потому что "я не знаю, как это сделать". Если он чего-то не знает, то узнает и задачу выполнит. Если не может выполнить задачу по не зависящим от него причинам, то своевременно уведомит всех заинтересованных лиц, а не будет молчать неделю. И т.д.
Значит я всегда был сеньором)
это просто ответственность. никто не должен исчезать на неделю или морозиться и ничего не делать если чего то не знает, ни синьер, ни джун.
это максимум мидл - "могу погуглить и сделать задачу самостоятельно, а не затихорюсь, потому что не умею".... сеньор, это когда без гугла берет и делает оптимальным способом, на основе большого объема знаний и многолетнего опыта, быстро и качественно (и потому дорого).
не исчезнет на неделю, а потом окажется, что он ничего не сделал, потому что "я не знаю, как это сделать". Если он чего-то не знает, то узнает и задачу выполнит. Если не может выполнить задачу по не зависящим от него причинам, то своевременно уведомит всех заинтересованных лиц, а не будет молчать неделю.
Это всё прекрасно. Только это определение мидла. Если вы можете исчезнуть на неделю и за вами нужно постоянно присматривать, то вы максимум джун.
Не совсем согласен, если мидл требует присмотра, то это джун+ максимум. А если рассматривать это в ключе код ревью, то и для сеньоров оно лишним не будет.
У нас ревью обязательно для всех без исключения т.к. оно снижает вероятность ошибок. Так что "все под присмотром".
Разница между джуном и мидлом прежде всего в том, что джун пишет строго по ТЗ (речь, естественно, о реализации более-менее сложной бизнес-логики), а мидл более вдумчив в плане выбора конкретных алгоритмов.
Нет. Джун требует постоянного надзора, а не присмотра, задачу джуну требуется разжёвывать. Мидл корыряется сам, бпрет хуже проработанные задаси, но требует присиотра, потому что у него ещё мало опыта и он может принимать спорные или неверные архитектурные решения из-за этого.
По определению синьор (сеньор) это феодал, господин.
У меня простой критерий, что :
Джуну надо объяснять что и как делать, как это влияет на бизнес и пр. Не может делать без объяснения даже типовые задачи команды, нужен постоянный контроль и корректировка
Мидл уверенно выполняет типовые задачи на потоке, с небольшим контролем и вводными
Сен решает нетиповые задачи + способен контролировать как минимум предыдущих двоих
Все остальное - это в общем, градации и натягивание этого на разные масштабы коллективов и других сов на глобус
"А это включает в себя процесс по переводу знаний другим коллегам, то есть уметь донести нормальным образом свои мысли до других. "
В какое место Вы переводите знания ?
Куда Вы пытаетесь донести свои мысли?
Вы полагаете, что выражаясь подобным образом, можно "донести свои мысли до других"?
Я думаю, все условно просто. Во-первых, это про hard skilks. Все это бла-бла-бла про тимлида не причем. Тимлид - другой круг обязанностей и ответственность за процесс разработки в целом. Софт скиллы туда же. Это именно категория владения основным умением писать код.
Дальше просто.
Джун. Не способен к самостоятельной работе. Требуется присмотр/менторство, так как знания базовые и косяки возможно просто везде. Как по мне ключевой - джун это всегда прицеп к кому-то
Миддл - может закрывать задачи сам в рамках стека проекта. Понятто код ревью и так далее никто не отменял,но в целом - самостоятельная личность, обязанная закрыть любую штатную задачу
Сеньйор. Может копнуть вперед. Сделать выьор и обосновать, почему так лучше. Пересмотреть чужой код и предложить как его улучшить, и не только в лоб. Ищучить новую технодогию и потом передать опыт команде. Менторство над джунами (предполагается, что плохому не научит)
Все.
Сеньйор, желающий стать ответственным за команду - тимлид. Сеньйор априори не является тимлидом, так как банально не обязан, не может, не интересно думать за всю команду. Т.е. может он и может, но не хочет.
А как же техлид?
Техлид, это одна из ролей в команде, это не градация скиллов. В особых случаях можно быть и джуном-техлидом, если все сбежали, а ты после трёх месяцев стажировки остался :)
Ну я же написал, это по факту ответственный за команду разработчиков. Т.е. это никак не показатель его скилов разработчика. Т.е. своего рода перпендикулярная ось измерения.
Техлид - менеджерская позиция. Более того, техлид не обязательно является разработчиком. К примеру, я как архитектор, могу выступать (и часто выступаю) как техлид на проекте. Хотя как разработчик я на уровне джуна часто, в зависимости от технологии.
вот моя вариация:
- Крепкий мидл может решить любую проблему.
- Сеньор работает так, чтобы проблемы не возникали (ну или не создает проблем).
- Тимлид умеет делать так, чтобы другие не создавали проблем.
- Следующий уровень - это осаживать бизнес от бредовых идей.
Это значит, что нужно будет понимать +‑ в целом архитектуру всего проекта.
Нет, более того даже тимлид не обязан понимать архитектуру проекта. Хотя бы потому, что это может быть бывший QA, аналитик, PO
Иметь нужные доступы по работе, подменять иногда тимлида, чтобы при уходе оного в отпуск проект не останавливался в ступоре.
Доступы к чему? Остановился в чем? Тимлид не определяет набор бэклога, например
При необходимости участвовать в совещаниях по планированию и интеграций.
Интеграции также определяет и планирует не тимлид, а посыл именно в этом. Что не отменяет того, что тем кто будет реализовывать функционал, полезно присутствовать на таких обсуждениях
Не замыкаться только лишь на своих задачах и понимать куда идет разработка в целом.
Разработка, как и аналитика и тестирование идет ровно туда, куда определит PO
Уровень soft‑skills должен быть на должном уровне, чтобы можно было вести переговоры с другими командами, решать конфликты внутри команды и не создавать их самому.
Не создавать конфликты навык необходимый в принципе на любой позиции
Проблема в том, что почему-то Team Lead представляется часто, как самый опытный разработчик или же руководитель над другими разработчиками. Но для этого есть другие позиции и роли, например, Tech Lead или SEM
Team Lead вообще не обязан быть бывшим разработчиком, и в его скоуп работ, как и написано в роли, входит организация работы команды, а не ревью/написание кода
Team Lead вообще не обязан быть бывшим разработчиком, и в его скоуп работ, как и написано в роли, входит организация работы команды, а не ревью/написание кода
Не дай бог. Он же просто будет говорить с командой разработки на разных языках.
И подобные радости:
Разработчик берет фичу и оценивает ее в 3 месяца разработки, на выходе через 3 месяца пристойно работающая фича и 5 тысяч строк кода. Со стороны бизнеса описание такой фичи может быть любым. От добавь вот тут кнопочку паузы процесса, до разработай 10 форм.
Дать этому разработчику премию или уволить его? Кто и как это в вашей команде с лидом не писавшим код будет решать?
Если у вас команда из одного разработчика - нужен ли ей тимлид? Разработчик не должен оценивать задачу в одно лицо, если есть команда, точно также как и должен быть процесс контроля качества (ревью, тесты) и эти процессы не должны быть завязаны на тимлида, т.к. он тоже может захотеть поболеть, в отпуск, уволиться. Иначе это не команда, а просто набор рандомных людей, обобщенных по какому-то признаку.
И если все эти процессы есть, то собрать фидбек на разработчика от коллег можно и не будучи разработчиком. Да, это сложней, чем если сидеть с палкой над каждым лично. Зато эффективней, чем микроменеджмент.
Не дай бог. Он же просто будет говорить с командой разработки на разных языках.
Аналитики, QA, автотестры, DevOps-ы как-то говорят с разрабами и понимают друг друга, а вот именно тим-лид не будет
Разработчик берет фичу и оценивает ее в 3 месяца разработки
Во-первых, это ошибка декомпозиции, и как раз тимлид(или сам ПО) должен на нее указать, если такую задачу хотят протащить.
Во-вторых, после декомпозиции задачи оцениваются не 1 человеком, для этого и делаются стори-ревью, планнинги и так далее. Чтобы все были на одной волне, понимали задачи и риски
на выходе через 3 месяца пристойно работающая фича и 5 тысяч строк кода
Пристойно работающая по каким критериям? И какое отношение кол-во строк кода относится к сложности/длительности фичи?
Со стороны бизнеса описание такой фичи может быть любым
Именно поэтому есть ПО и аналитики, чтобы в разработку и тестирование приходила понятная фича с понятными требованиями
От добавь вот тут кнопочку паузы процесса, до разработай 10 форм.
Кнопки какие? Кому доступны? Какие формы? По каким полям фильтруется/сортируется? Кто источник данных? Какие требования по нагрузке?
И много каких еще вопросов.
Если вы решаете брать в работу такое описание требований, то пожалуйста, но кроме вас в этом никто не виноват
Кто и как это в вашей команде с лидом не писавшим код будет решать?
Решать что?
Есть документация, карточки сервиса(со всем бд/топиками/очередями), архитектурные схемы. Если на запрос от соседней команды тимлид начинает реализовывать/фиксить функционал, то это проблема самого тимлида
Аналитики, QA, автотестры, DevOps-ы
Вы перечислили другие команды. Которые делают другую работу с другими целями, другими задачами и оцениваются по другим критериям.
Общение с ними обычно идет через хотя бы немного формализованные интерфейсы вроде тикетов. Тимлид работает в команде разработке, а не в другой.
декомпозиции
Декомпозиция какая-то будет. Десяток-другой тикетов с каким-то описанием. Сам для себя человек сделал. Это не проблема. Что вам это даст?
Во-вторых, после декомпозиции задачи оцениваются не 1 человеком, для этого и делаются стори-ревью, планнинги и так далее. Чтобы все были на одной волне, понимали задачи и риски
Погружение всей команды в разработку новой фичи до уровня понимания проблем и адекватной оценки сроков это глупость, да и невозможно. Время будет сжигаться в огромных количествах. А тем кто эту фичу не делает это все нафиг не нужно. У них свои задачи.
В общем это не работает.
Пристойно работающая по каким критериям? И какое отношение кол-во строк кода относится к сложности/длительности фичи?
Пользователи довольны, девопсы довольны, обращений в поддержку не слишком много, железа затрачено Х единиц. Вы как первый день в разработке. Все как обычно.
А это к вам вопрос. Я вам показал результат и мне интересно как ваш тимлид не разработчик оценит его. Так уволить или премию дать?
Кнопки какие? Кому доступны? Какие формы? По каким полям фильтруется/сортируется? Кто источник данных? Какие требования по нагрузке?
И много каких еще вопросов.
Это все ненужные детали. Придумайте сами по вкусу, если надо.
Решать что?
Есть документация, карточки сервиса(со всем бд/топиками/очередями), архитектурные схемы. Если на запрос от соседней команды тимлид начинает реализовывать/фиксить функционал, то это проблема самого тимлида
Решать выдать вот этому разработчику премию вот за эту так решенную задачу или наоборот уволить его.
Тимлид иногда пишет сам, примерно половину времени. Это нормально. Чтобы быть на одной волне с командой разработки. Без этого понять что там происходит невозможно.
Всегда могут быть какие-то конфликты. Разработка жалуется что стенды создаются медленно, работают плохо. Девопсы говорят что все работает нормально. Как решать будете? Стенды сложные и комплексные, сбор формализованных метрик это проект минимум на месяц. И не факт что эти метрики что-то покажут.
Документация, особенно внутренняя, как обычно. Что-то вроде есть. Реальности даже соответствует местами.
Дали задачу пяти разработчикам:
junior
не смог решить
middle
в лоб написал 1000 строк запутанного кода
middle+
использовал паттерны, порешал в 500 строк чистого кода
middle++
используя всю мощь ФП, современные подходы и мудрость поколений решил в 100 строк восхитительного, чистого, быстрого, идиоматически правильного кода
senior
немного подумав, решил в 0 строк кода
manager
выставил заказчику счёт за 1600 строк написанного кода, накинул в инвойс ещё сумму за время, потраченное джуном на размышления, вписал работу тестеров и управление проектом, а сеньору сказал, чтобы тот поменьше выделывался, и выполнял kpi.
Забавно, что в градации полностью отсутствует выходной результат (ну, там, производительность получившегося кода, или занимаемые ресурсы...)
Техлид/архитектор - зарубил все пулл-реквесты, и заставил выносить решение в отдельный сервис.
Да забудьте вообще про эти градации. Главное польза приносимая продукту, и каждый как умеет, так и вкладывает свои усилия и навыки. Кто-то лучше, кто-то хуже в силу отсутствия опыта. Вот и вся формула.
Я видел проекты где "мидлы" лидили проект, и наоборот, где лиды работали на позиции разработчика, и всё было нормально.
Важна не градация, а средний уровень разработчиков и как они работают в команде. Опыт дело поправимое, важны сами люди, и как они работают. У нас есть ребята которые были стажеры, но быстро учатся и местами за ними не успеваешь, шустрые пацаны, за пару лет так натаскались что уже знают такие штуки, про которые старики уже не знают.
Поэтому, люди... Важны именно люди, как они работают, их подход, а опыт дело приходящее.
Согласен, командная работа решает. 10 даже средних разработчиков, но с хорошей коммуникацией, процессами и командной работой, думаю, сделают надежнее и предсказуемее результат, чем 10 суперзвезд-снобов индивидуалистов. В среднесрочной-долгосрочной перспективе.
Кабы все так всегда однозначно было...
И так и этак может быть. Одно дело пилить типовой проект на время в стиле картины "Бурлаки на Волге" - там да, суперзвезды не нужны. Нужна команда бурлаков.
Другое дело когда в результат масштабирования системы он перестает справляться с нагрузкой и требуется предельно оптимизировать узкие места без переделывания всего и вся - тут уже мало бурлаков, нужны "суперзвезды".
Так что все нужны и все важны. Большие прорывы как правило начинаются со "снобов-суперзвезд". Они задают направление. А бурлаки уже потом подтягиваются. Когда понятно куда двигаться.
Ну мне так кажется.
В чем будет отличие мидл-специалиста по СКУД и видеонаблюдению от сеньора?
А если взять не разработку, а системное администрирование?
Или мы все сходимся во мнении, что сеньор автономен, а мидлу надо ставить задачи и присматривать?
Ну вот например: специалист в компании закрывает вопросы по СКУД и видео, админит MS AD, сервера на Линуксе, пишет политики и регламенты - как определить его грейд?
Это будет мидл СКУД + сеньор админ + мидл техпис?
Или как?
В чем будет отличие мидл-специалиста по СКУД и видеонаблюдению от сеньора?А если взять не разработку, а системное администрирование?
Да как везде. Сеньор сделает вам готовый проект так что он будет потом работать десятилетиями без особых проблем. Без привлечения других экспертов.
Мидл или накосячит в паре мест что переделывать придется или будет звать внешних экспертов для всяких тонкостей.
специалист в компании закрывает вопросы по СКУД и видео, админит MS AD, сервера на Линуксе, пишет политики и регламенты
Эникейщик. Ничего не умеет на самом деле. Максимум джун везде.
Да как везде. Сеньор сделает вам готовый проект так что он будет потом работать десятилетиями без особых проблем. Без привлечения других экспертов.
Ну так и миддл в случае СКУД сделает так же :)
Эникейщик. Ничего не умеет на самом деле.
Как же ничего не умеет? Наоборот, умеет в СКУД, в AD, в линукс, и в документирование. Люди, которые закрывают вопросы по разным направлениям, они наоборот, умеют много, а не "ничего не умеют". Сеньор, который знает несколько смежных направлений, это отнюдь не редкость, а норма. Наоборот, специалист, который якобы хорошо знает только что-то одно и джун во всех остальных смежых областях, это скорее исключение.
Ну так и миддл в случае СКУД сделает так же :)
Верю на слово, ибо не разбираюсь.
Значит это коммон область где сеньоры невозможны. Это нормально. Все изучено, есть решения для всех случаев и надо просто грамотно им следовать. Мидл это вершина развития в такой области.
Как же ничего не умеет?
Вот так. У человека ни времени ни головы на столько разных областей не хватит. Чтобы их изучить на хорошем уровне и вляпаться и успешно выбраться из множества разных корнер кейсов. Сеньор вероятно заранее знает решение вашей проблемы потому что он пять очень похожих уже успешно решил.
Сеньор, который знает несколько смежных направлений, это отнюдь не редкость, а норма.
Это не смешные области. Это абсолютно разные области. Для админа смежное это девопс, например. Запилить поднимающиеся и умирающие временные окружения для разработки админ вполне может. Сети на уровне милда (мидла провайдера или бигтеха) типичный хороший админ вероятно знает. А вот даже типичная корпоративная AD с не менее типичными эксченджами и прочей требухой в ней для линукс админа это темный лес. К СКУД он и пальцем не притронется.
Значит это коммон область где сеньоры невозможны.
Возможны, просто проектирование и монтаж в области СКУД - это работа, которая не требует специалистов высокого профиля. Какие-то расширенные знания требуются для иных вещей, зачастую спрятанных от клиентов. Например, тестирование и интеграция новых компонент, которые появились в ассортименте у поставщиков. Или в граничных вещах, например, интеграция СКУД с чем-то, для чего нет стандартных решений.
Это не смешные области. Это абсолютно разные области.
Неа, очень даже смежные. СКУД - всего лишь ещё одна железяка с сервером и софтом в инвентори у админа, она вообще не требует никаких специальных знаний, которые отсутствуют в багаже у админа. Что он там не сможет сделать, логи посмотреть и почитать в чём проблема, или там витуху обжать при необходимости? Корпоративная AD? AD, это всего лишь одна из реализаций LDAP, который отнюдь не чужд линуксовому миру, и в нём же и зародился. Что там может смутить линуксового админа, кроме личной неприязни к форточкам?
Вот так. У человека ни времени ни головы на столько разных областей не хватит.
Нет, я правда не понимаю. Как это не хватит? Мы же с вами не говорим про сеньора-программиста node.js, который одновременно сеньор-разраб микроконтроллеров и сеньор-сосудистый хирург. Это всё несколько смежных направлений в пусть довольно обширной, но все равно одной и той же области - администрирование корпоративной инфрастуктуры. Направления отнюдь не обширные, на уровне "уметь решать вообще все задачи, которые у вас могут возникнуть" познаются за несколько лет.
Неа, очень даже смежные. СКУД - всего лишь ещё одна железяка с сервером и софтом в инвентори у админа, она вообще не требует никаких специальных знаний, которые отсутствуют в багаже у админа. Что он там не сможет сделать, логи посмотреть и почитать в чём проблема, или там витуху обжать при необходимости
Не может и не будет чинить когда все неизвестно почему перестало работать. Его зона ответственности заканчивается на работающем железе, операционке, бекапах и всем таком. Что там внутри системы ему все равно. Ровно так же как и с любым другим пользовательским софтом.
Системы иногда ломаются по самым невероятным и непонятным причинам.
Корпоративная AD? AD, это всего лишь одна из реализаций LDAP, который отнюдь не чужд линуксовому миру, и в нём же и зародился. Что там может смутить линуксового админа, кроме личной неприязни к форточкам?
Вы прямо совсем не попали. Корпоративная AD это только MS без вариантов и там миллионы специфичных штук и особенностей. Смутить ничего, он и трогать не будет. Не его работа. Железки работают? Сеть есть? Линукс машинки работают в AD как договорились? Ну и отвалите.
Нет, я правда не понимаю. Как это не хватит? Мы же с вами не говорим про сеньора-программиста node.js, который одновременно сеньор-разраб микроконтроллеров и сеньор-сосудистый хирург. Это всё несколько смежных направлений в пусть довольно обширной, но все равно одной и той же области - администрирование корпоративной инфрастуктуры. Направления отнюдь не обширные, на уровне "уметь решать вообще все задачи, которые у вас могут возникнуть" познаются за несколько лет.
Шутите? Несколько лет недостаточно чтобы стать сеньором даже в одной области. Мидлом то сложно стать. Это все очень комплексные и очень сложные области.
Сделать что-то типовое по гайду это даже не мидл. Сеньор на самом деле решает любые внезапные проблемы и делает все так что таких проблем после него становится меньше чем было до него. Это годы и годы опыта в одной области.
Не может и не будет чинить когда все неизвестно почему перестало работать.
Что такое "неизвестно почему перестало работать"? Это же не гагиопневматический перфекционатор. СКУД - это датчики, магнитные замки, считыватели, турникеты, сервер регистрации событий и база данных. Вы считаете, что админ с опытом работы более одного месяца не в состоянии определить, что поломался магнитный замок, и выяснить, сломалась там катушка, питание или сигнальный кабель, что ли?
Корпоративная AD это только MS без вариантов и там миллионы специфичных штук и особенностей.
Например? Назовите мне хотя бы пару-тройку специфичных штук и особенностей AD, которые требуют какой-то особой квалификации.
Шутите? Несколько лет недостаточно чтобы стать сеньором даже в одной области. Мидлом то сложно стать. Это все очень комплексные и очень сложные области.
Нет, абсолютно серьёзно. Если мы бы говорили про хирургию, я бы не спорил. Про администрирование AD, не знать его вдоль и поперёк вплоть до настройки федеративной аутентификации с облачным решением от компании "Рога и Копыта" за условный год можно только если им не особо интересоваться.
Вот так. Любая комплексная система иногда может внезапно перестать работать без понятной причины. Особенно если забили на регламентные работы или уволили всех сеньоров (которые с виду ничего не делали).
Электричества админ тоже не касается. Сломалось - он звонит электрикам с которыми у конторы договор вероятно со sla. Они приезжают и чинят. Админ при этом гарантирует что его железки проработают заранее оговоренное и всем понятное время без внешнего электричества. И в это время будет тоже заранее понятное качество сервиса для клиентов. Там много тонкостей на самом деле.
И даже кабеля админ как правило не ремонтирует. Про ноков слышали? Или на пользовательском уровне сервисдеск/аникейщики. Вот те или другие чинят провод сами или передуют проблему другой специальной организации с которой у вашей конторы тоже есть договор со sla. Админ при этом гарантирует что все ваши сервера нормально работают с альтернативными каналами связи. А пользователи могут использовать альтернативный канал для своей работы. Аналогично с заранее понятным качеством работы. Тут тоже много тонкостей.
Откройте любой опросник или учебник MS для сертификации. Там для меня много непонятных слов. Они в пиратском виде доступны, ссылок давать не буду.
Рога и копыта не интересны. Им аутсорса и локального студента эникейщика хватит. Я про серьезных людей и серьезную работу. Ну хотя бы от 1000 серверов или 10000 пользователей.
Вот так. Любая комплексная система иногда может внезапно перестать работать без понятной причины.
Нет. Так не бывает. Бывает "перестало работать, надо провести диагностику". Это не магия, все причины вполне себе детерминированы - аппаратный отказ той или иной компоненты, внесённые изменения в ОС или другое ПО, проблемы с хранилищем данных и т.д. В случае СКУД, я, пожалуй, уже перечислил все возможные.
Электричества админ тоже не касается. Сломалось - он звонит электрикам с которыми у конторы договор вероятно со sla.
Я про электричество не говорю. Там дело не в SLA, а в сертификации. Что такое SLA, электрики не знают. Это сугубо терминология из ИТшных хэндбуков. Но им и не нужно, с электриками вообще договоров на обслуживание обычно не заключают - любое маль-мальски крупное офисное здание должно иметь штатного энергетика или даже подразделение, задача которых оперативно устранять проблемы с электрикой. Это если компания невелика. Уже даже средние компании имеют лицензированных энергетиков в штате. Это такая же востребованная должность, как штатный сисадмин.
Я про серьезных людей и серьезную работу. Ну хотя бы от 1000 серверов или 10000 пользователе
Ну так надо бы сразу вам было сказать, что вы будете говорить не про то, как бывает в ИТ, а про то, как бывает в 0.001% ИТ-компаний :)
Мидл - это программист.
Сеньор - это программист + архитектор + аналитик.
Но не руководитель проекта. Решать, какую фичу реализовываем в первую очередь, он не должен.
В разработке есть только две сложных задачи: инвалидация кеша и наименование переменных. Предлагаю добавить в этот список третью - классификацию разработчиков. Уже второй десяток лет обсуждают кто миддл, а кто сеньор и у каждого есть свое мнение на этот счет :)
Я бы первую проблему обобщил. Про наименование переменных согласен.
Я всегда называл одной из двух сложных проблем разработки - отладку конкурентного кода. Инвалидация кэша одна из похожих задач, но всё же это достаточно конкретная одна задача, хотя таких задач целый класс.
Более точно, кмк, звучала бы абстракция "идемпотнетность конкурентных процессов*" = независимость результата работы функции от порядка, количества и контекста её вызова, если такая независимость требуется. А конкурентными алгоритмами являются и инвалидация кэша, и асинхронное выполнение операций над ресурсами одной системы, и потоковое объединение данных из разных источников. Д даже порядок вызовов include в коде на С или require в Lua может влиять на итоговый результат, хотя не всегда это желаемый эффект.
* - "процесс" в общем понимании слова, не в контексте ОС.
Вот только в такой формулировке, думаю, можно описать большинство задач из любой сферы деятельности, не только IT.
Эта тема ниочем, в сухом остатке, синьор это тот, кто кого взяли на синьорскую должность и/или зп.
Прошёл собес и сидишь на встречах 24/7 не написав и строчки кода? Поздравляю, тебе даже не нужно уметь кодить.
Может я нафармил ЧСВ, но встречал множество людей с множеством лычек, множество из которых вводили меня в ступор и желание скорее сбежать, пока не начал кидаться на людей. Техлиды, синьоры, архитектора из сферы вроде банковской бросают в холодный пот, что можно сделать человеку пластиковым стаканчиком? хорошо, что в кафе нет вилок
Техлиды, синьоры, архитектора из сферы вроде банковской бросают в холодный пот
Зря вы так. Там цена ошибки крайне высока, а система запредельно сложна. Так что там все очень консервативно.
Мало кто представляет себе сколько процессов постоянно крутится на центральном сервере банка в фоновом режиме. И сколько там данных постоянно перелопачивается. И во что выливается для разработчиков ядровых систем очередная "креативная фича" в мобильном приложении.
Зря вы так. Там цена ошибки крайне высока, а система запредельно сложна.
Да бросьте, так везде говорят. Я банковскую сферу и упоминаю, потому, что до боли знаком с людьми, проектами и системами оттуда. Умение некомпетентных людей строить сложную систему, непонятную никому, включая создателей из элементарной задачи это пожалуй самое яркое впечатление.
Я банковскую сферу и упоминаю, потому, что до боли знаком с людьми, проектами и системами оттуда
Ну я тоже знаком. И на этом основании говорю.
Во-первых, систем и проектов там очень много. У нас это центральные системы (центральные сервера и работающая на них АБС) и вокруг них еще несколько десятков внешних систем. Я даже затруднюсь все перечислить.
Во-вторых, эту задачу я никак не назову "элементарной", просто примерно представляя тот функционал, который там крутится. Даже если ограничиться только центральными системами. И те объемы данных с которыми приходится работать.
В-третьих, то, что крутится на серверах, в большинстве своем mission critical. Отказ чего-то, даже казалось бы небольшого, может потянуть за собой только прямых убытков на десятки миллионов. Плюс репутационные. Плюс потенциальное нарушение требований регулятора (время недоступности основных систем нормируется минутами), а это как минимум штрафы, максимум - потеря лицензии.
Мне кажется это достойные темы для дискуссии
Но мы в треде "В чем разница между мидлом и сеньором", выраженный мной тезис "в банковской сфере очень много некомпетентных людей, нанятых по принципу "вы же погромист?", как пример, области где человеку легко получить лычку
Давайте так. Что вы подразумеваете под "банковской сферой"?
Вот я разработчик центральных банковских систем. Платформа IBM i, DB2 for i, SQL, RPG, C/C++. Ну вроде как сеньор, наверное (по крайне мере в разработке у нас уже позиций выше нет, дальше только архитектор направления, но это уже не то - вообще не мое, пробовал, отказался). Или лид (по крайне мере техлид направления - комплаенс).
Вы что, всерьез думаете, что могу вот так просто взять и перейти в разработку WBI? Или мобильного приложения? Или сайта? Да ни разу. Там свои стеки, свои задачи, своя архитектура, свои подходы. Да же при том, что все это в одном и том же банке.
Больше скажу, даже есть я перейду из команды комплаенса в команду системы расчетов (например) - уже потребуется время чтобы в их процессы и сущности вникнуть. Хоть это и на том же сервере и том же стеке работает. Даже при том, что смежные темы у нас есть (тот же контроль платежей по которому я работал).
И я не знаю где нанимают по указанному вами принципу "ты же программист".
Нет, у нас, конечно, примерно так и нанимают. Просто потому, что разработчиков под IBM i в стране пара-тройка сотен всего. Людей, которые эту платформу знают и понимают как она работает (назовите принципиальные отличия объектов типа *DTAQ от *USRQ) . И примерно столько же кто знает основной наш язык RPG (более 80-ти процентов кода под эту платформу на нем пишется) - назовите ососбенности инициализации полей структуры и какие там подводные камни могут быть.
Поэтому да. Берем людей с опытом разработки и обучаем сами. Но это не значит это не компетентные люди. Повторюсь - на уровне ядра АБС некомпетентность разработчика обходится банку слишком дорого. А уж что-то, а деньги тут умеют считать.
Все просто. Сеньор это состояние, когда ключевой навык это решение поставленной задачи или проблемы.
Например, джуна надо вести за ручку, мидлу поставить чётко конкретную задачу. Синьору достаточно просто дать задание что то сделать. Задание любого уровня. Сам изучит ситуацию и разберётся, сам найдёт решения и нужные инструменты.
В общем, это "решала" от мира ИТ.
Не согласен с равнением на лида, это разные компетенции и иногда замом лида может быть просто опытный миддл. Вообще, если миддл - это опытный джун, то сеньор это далеко не опытный миддл. Миддами с опытом становятся все, а вот сеньорами нет. Сеньор - это болше про экспертность в своей области.
Всё просто: джун копирует код на Stackoverflow из вопроса. Миддл - из ответа. А сеньор вообще забыл дорогу на Stackoverflow, потому что привык, что по большинству сложных задач решения в интернете нет.
А сеньор вообще забыл дорогу на Stackoverflow, потому что привык, что по большинству сложных задач решения в интернете нет.
Сеньоры тоже постоянно копируют код из SO, просто потому что всё в голове наизусть не удержишь, а то, что удержишь, целиком писать зачастую лень, если можно готовые сниппеты надёргать. А сложные задачи... а сложные задачи, они отнюдь не каждый день случаются. И даже далеко не каждый месяц.
Я сеньор уже много лет, и с трудом вспомню, когда в последний раз приходилось копировать код со Stackoverflow. Если задача простая и маленькая, то код пишешь сразу из головы, не думая. Не потому что помнишь, а потому что знаешь, как воспроизвести. Если же надо воспроизвести длинный кусок кода, то он, как правило, берётся из другой части проекта, или из другого проекта или прямо из ядра фреймворка, библиотеки и т.д. Если под рукой нужного сниппета нет, то он копируется из документации или папки examples в репозитории используемого решения. И вот только если во всех вышеуказанных местах ничего не нашлось, тогда идёшь на Stackoverflow.
Ну так и миддл и даже джун будет делать то же самое. Текущий проект - это первоисточник, понятное дело, что если там надо сделать очередной эндпойнт или что-то в этом роде, ты просто скопируешь соседний и переименуешь. На SO ходят, когда надо добавить что-то новое в проекте. Например, первый эндпойнт.
Сеньор никогда не будет копировать код первого эндпоинта с SO, потому что для этого есть во-первых генераторы кода, а во-вторых, документация. Stackoverflow в данном случае вообще лишний. И джун не будет делать то же самое. Когда у джуна возникает вопрос, он идёт гуглить ответ. Когда вопрос возникает у сеньора, он либо уже знает, где именно написан ответ, либо придумывает его сам.
Сеньор никогда не будет копировать код первого эндпоинта с SO, потому что для этого есть во-первых генераторы кода, а во-вторых, документация.
Кстати, есть одно железное отличие сеньора от миддла. Сеньор, по квалификации, а не по должности, никогда не будет говорить "никогда". Категоричность, это непрофессионализм или недопрофессионализм, человек с хорошим опытом дожен знать, что у любого подхода есть граничные условия, где он эффективен, и не эффективен за их пределами.
Например, про копирование кода эндпойнта, есть немало причин делать это вручную, а не использовать сваггер и ему подобные. И это если речь идёт о заголовках. А я вообще писал не про заголовки, а про реализацию (наверное же очевидно, что заголовки вашего эндпойнта на SO уж точно не валяются). А там, извините, хоть генераторы для некоторых платформ и существуют, какие-либо преимущества перед ручным кодом они дают только в очень частных случаях, в остальных их использование в лучшем случае вкусовщина, в худшем - оверхед. И раз вы себя позиционируете как сеньор, то странно, что вы про это не в курсе.
Никогда, никогда, никогда сеньор-разработчик не будет копировать код первого эндпоинта со Stackoverflow. Он может его скопировать из документации, из папки examples или demo, с другого проекта. Но никогда не со Stackoverflow.
Ну тогда раскройте свою мысль, что ли. Я причины легко могу назвать: вы садитесь начинать новый проект, у вас нет папки examples или demo (ибо откуда она у вас взялась-то? Я последний раз что-то такое видел в 90-е годы, когда ещё ставил галочку "устанавливать примеры" при установке IDE), и это ещё стадия PoC, на которой проектировать апи ещё никто не садился, соответственно, доков openapi нет и не ожидается, а надо через три дня что-то работающее показать. А скачать сниппет на SO - это несколько секунд, куда быстрее, чем лезть в предыдущие проекты, где что-то подобное.
Моя мысль изложена в моём первом комментарии. Но поясню ваши вопросы: examples и demo - это в javascript экосистеме принято. Любой пакет или либа имеет либо такую папочку, либо онлайн-демо. Но это конечно не об эндпоинтах.
Говоря о документации, я имею в виду не openapi документацию для эндпоинта, а обычную документацию для фреймворка или библиотеки. Как правило, в нормальных фреймворках в документации есть примеры эндпоинтов. И эти примеры будут проверены и утверждены сообществом, в отличие от Stackoverflow, где может писать каждый. Я вот реально не понимаю, что может быть за такая технология, где будучи сеньор-разработчиком с ходу надо лезть не в доки, а на Stackoverflow.
Моя мысль изложена в моём первом комментарии. Но поясню ваши вопросы: examples и demo - это в javascript экосистеме принято.
Ок, то есть вы сходу начали отвешивать какие-то платформенно-зависимые постулаты, при этом даже не упомянув про их применимость? Сеньор, говорите? Ладно, я не эксперт по экосистеме JS, хотя многократно с ней пересекался, и тоже, подозреваю, вы преувеличиваете. Вот, например, нода. Найдите мне тут сниппет для обработки POST-запроса.
https://nodejs.org/docs/latest-v20.x/api/
Точнее, найти-то вы наверняка найдёте, время на поиск замерьте, пожалуйста.
А вот - гугл и SO:
https://www.google.com/search?q=handling+post+request+in+node+js
Сравните, и сразу же получите железный контраргумент, почему SO - лучше.
И эти примеры будут проверены и утверждены сообществом, в отличие от Stackoverflow, где может писать каждый
Простите, но мы же говорим с вами как раз не про джуна, а про сеньора. Мне сложно представить сеньора, который по своей рабочей платформе не в состоянии отличить корректный сниппет от некорректного. Я ведь изначально упоминаю SO не как источник знаний (мы ведь говорим про человека, у которого они уже есть), а как источник готового кода.
платформенно-зависимые постулаты
Папка examples не является платформенно-зависимой. Просто я много работаю с javascript и Drupal. Эта практика применяется и там, и там.
По вашему запросу у меня Stackoverflow только на пятой позиции выдачи. И там приводят сниппет с использованием express. Если вы собираетесь использовать express, сразу смотрите его документацию, там всё есть. А если не собираетесь, то опять же получается, что Stackoverflow не дал ответа на вопрос
Точнее, найти-то вы наверняка найдёте, время на поиск замерьте, пожалуйста.
А могу я вас всё-таки попросить проверить? А то вы так настойчиво спорите, что меня даже удивляет, откуда у вас такая уверенность :)
Там на две позиции выше в выдаче статья How to handle post-request in Node.js without frameworks. Вот там сразу нормально написано. А ниже идёт стек, там лучшие ответ подразумевает использование express, приходится листать дальше и вчитываться. То есть помимо документации нашёлся ещё один источник более удобный, чем Stackoverflow
Эх. Вымерли техлиды в умах живущих... У всех заканчивается ветка на тимлидстве
Джун пишет код под присмотром других разработчиков.
Мидл пишет код без присмотра других разработчиков.
Сеньор решает проблемы.
Почему-то в основном обсуждение все равно скатывается к разработке...
Но, осмелюсь напомнить, что IT многогранно.
Что делает джун / мил / сеньор в следующих категориях: (?)
(мы берем наверное средний бизнес и госсектор от 100 до 2000 сотрудников и 10-50 серверов)
1) СКУД (включая хранилища до 4го класса защиты)
2) Видеонаблюдение (включая хранилища до 5го класса защиты)
3) Сеть (ЛВС + вифи + GSM)
4) ИБ / Кибербез (наверное включая DLP / SIEM / OSINT / Pentest / ГОСТ)
5) Линукс (включая Astra SE / Брест, которые теперь в госсекторе)
6) MS Windows
7) 1C либо другие ERP
8) Тестирование
9) Техническая документация
10) ЭДО / ЭЦП / Цифровые доверенности
11) и т.д
Если сотрудник закрывает вопросы компании по 4-5 позициям из (при этом опыт сотрудника в сфере IT берем ну например 10 лет) - то каков его грейд? Как это определить? Ну вот банально - какую мне ему зарплату назначить? HRы только мямлят...
Понятно, что это зависит от компании и вида бизнеса.
з.ы А если ему еще падавана дать в обучение - то он сразу "Ведущий" получается?
В чем разница между мидлом и сеньором