Заметка навеяна вопросом друга на эту тему, решил развернуто ответить.
Далее пойдут, разумеется, лишь только мои мысли, которые основаны на моем опыте. Специально перед написанием этой заметки решил ничего не читать в других местах, чтобы не замылить собственное ощущение. Приступим.
В чем разница между мидлом и сеньором? Пройдем по пунктам:
Зам тимлида
Да, позиция сеньора означает, что он может быть потенциальным замом тимлида, Что это значит?
Это значит, что нужно будет понимать +‑ в целом архитектуру всего проекта.
Иметь нужные доступы по работе, подменять иногда тимлида, чтобы при уходе оного в отпуск проект не останавливался в ступоре.
При необходимости участвовать в совещаниях по планированию и интеграций.
Не замыкаться только лишь на своих задачах и понимать куда идет разработка в целом.
Уровень soft‑skills должен быть на должном уровне, чтобы можно было вести переговоры с другими командами, решать конфликты внутри команды и не создавать их самому.
Ответственность
Здесь разница именно в том, что сеньор прежде всего должен уметь взять задачу / направление в развитии проекта и вести его до нужного результата.
Понимать, что дальше с большой долей вероятности эта задача связана с человеком и придется за нее отвечать и далее. А это включает в себя процесс по переводу знаний другим коллегам, то есть уметь донести нормальным образом свои мысли до других.
Техническая часть
Разумеется техническая часть также важна. Сеньор должен иметь понимание как решить разные задачи, какие плюсы и минусы у конкретного решения и чем могут быть эти решения чреваты.
Есть базовые пазлы разработки и они должны быть знакомы сеньору. Причем пусть даже какая‑то из технологий не известна — это не страшно, всегда можно погрузиться настолько, насколько это нужно, чтобы начать перформить на должном уровне.
Общий опыт работы
За два года нельзя стать сеньором, разве что в каких‑то фильмах, а не в реальности. Потому что опыт вещь такая, которую нарабатываешь с годами. Есть множество условностей и договоренностей как делать правильно, а как нет. И чисто физически их получить за короткий промежуток времени сложно, если вообще возможно.
Зачастую это опыт не просто технический, а общий в разработке. Нужно знать и понимать что делать и как, нужно понимать круг своих обязанностей, нужно понимать и правильным образом ожидать от других действия. А это нарабатывается с годами. А это нельзя покрыть теоретическими знаниями и техникой написания алгоритмов и решением задач на литкоде. Это нечто большее. Это уверенность человека в своей правота, умение отстаивать свое решение.
Вместо итога
Резюмируя скажу, что это лишь мое мнение и мнение во время, пока я работал. Почему уточняю? Потому что определение лычек меняется всегда и нет каких‑то точных черт, которые бы гвоздями прибили разницу эту.
Друзья, также есть телеграм канал по разработке, кому интересно — подписывайтесь.
Комментарии (70)
uuger
02.10.2023 09:22+16Поработав с разными рынками, пришел к выводу, что в каждом макрорегионе понятия Джуна/Миддла/Сеньора могут отличаться настолько значительно, что общение нужно начинать с установки некоей системы мер и весов в организации/проекте. В некоторых странах считают, что после трех лет работы человека почти обязательно надо назвать сеньором.
Плюс, постоянный инфошум от многочисленных курсов тоже значительно девальвировал ценность каждого уровня. 10+ лет назад было нормально, когда после обучения работник считался интерном (и это не звучало уничижительно), но когда из каждого утюга вещают про "с нуля и до мидла", статусы джун и интерн уже воспринимаются чуть ли не как оскорбление.
YChebotaev
02.10.2023 09:22+24Мидл требует присмотра, а синьор — полностью автономен
dsh2dsh
02.10.2023 09:22+3Вот. На мой взгляд - это правильное описание сеньёра. Самостоятельность и ответственность, а не чушь типа
что он может быть потенциальным замом тимлида
и прочих, прости господи софт - скилов. Сеньёр не исчезнет на неделю, а потом окажется, что он ничего не сделал, потому что "я не знаю, как это сделать". Если он чего-то не знает, то узнает и задачу выполнит. Если не может выполнить задачу по не зависящим от него причинам, то своевременно уведомит всех заинтересованных лиц, а не будет молчать неделю. И т.д.
Meth_0d
02.10.2023 09:22+1это просто ответственность. никто не должен исчезать на неделю или морозиться и ничего не делать если чего то не знает, ни синьер, ни джун.
dimas062
02.10.2023 09:22-1это максимум мидл - "могу погуглить и сделать задачу самостоятельно, а не затихорюсь, потому что не умею".... сеньор, это когда без гугла берет и делает оптимальным способом, на основе большого объема знаний и многолетнего опыта, быстро и качественно (и потому дорого).
Source
02.10.2023 09:22не исчезнет на неделю, а потом окажется, что он ничего не сделал, потому что "я не знаю, как это сделать". Если он чего-то не знает, то узнает и задачу выполнит. Если не может выполнить задачу по не зависящим от него причинам, то своевременно уведомит всех заинтересованных лиц, а не будет молчать неделю.
Это всё прекрасно. Только это определение мидла. Если вы можете исчезнуть на неделю и за вами нужно постоянно присматривать, то вы максимум джун.
MihaTeam
02.10.2023 09:22+15Не совсем согласен, если мидл требует присмотра, то это джун+ максимум. А если рассматривать это в ключе код ревью, то и для сеньоров оно лишним не будет.
SpiderEkb
02.10.2023 09:22У нас ревью обязательно для всех без исключения т.к. оно снижает вероятность ошибок. Так что "все под присмотром".
Разница между джуном и мидлом прежде всего в том, что джун пишет строго по ТЗ (речь, естественно, о реализации более-менее сложной бизнес-логики), а мидл более вдумчив в плане выбора конкретных алгоритмов.
Dolios
02.10.2023 09:22+2Нет. Джун требует постоянного надзора, а не присмотра, задачу джуну требуется разжёвывать. Мидл корыряется сам, бпрет хуже проработанные задаси, но требует присиотра, потому что у него ещё мало опыта и он может принимать спорные или неверные архитектурные решения из-за этого.
bondeg
02.10.2023 09:22+3Спорные или неверные решения могут принимать все, только сеньор объяснит почему и зачем)
pbatanov
02.10.2023 09:22+1У меня простой критерий, что :
Джуну надо объяснять что и как делать, как это влияет на бизнес и пр. Не может делать без объяснения даже типовые задачи команды, нужен постоянный контроль и корректировка
Мидл уверенно выполняет типовые задачи на потоке, с небольшим контролем и вводными
Сен решает нетиповые задачи + способен контролировать как минимум предыдущих двоих
Все остальное - это в общем, градации и натягивание этого на разные масштабы коллективов и других сов на глобус
nikolz
02.10.2023 09:22"А это включает в себя процесс по переводу знаний другим коллегам, то есть уметь донести нормальным образом свои мысли до других. "
В какое место Вы переводите знания ?
Куда Вы пытаетесь донести свои мысли?
Вы полагаете, что выражаясь подобным образом, можно "донести свои мысли до других"?
Batalmv
02.10.2023 09:22+13Я думаю, все условно просто. Во-первых, это про hard skilks. Все это бла-бла-бла про тимлида не причем. Тимлид - другой круг обязанностей и ответственность за процесс разработки в целом. Софт скиллы туда же. Это именно категория владения основным умением писать код.
Дальше просто.
Джун. Не способен к самостоятельной работе. Требуется присмотр/менторство, так как знания базовые и косяки возможно просто везде. Как по мне ключевой - джун это всегда прицеп к кому-то
Миддл - может закрывать задачи сам в рамках стека проекта. Понятто код ревью и так далее никто не отменял,но в целом - самостоятельная личность, обязанная закрыть любую штатную задачу
Сеньйор. Может копнуть вперед. Сделать выьор и обосновать, почему так лучше. Пересмотреть чужой код и предложить как его улучшить, и не только в лоб. Ищучить новую технодогию и потом передать опыт команде. Менторство над джунами (предполагается, что плохому не научит)
Все.
Сеньйор, желающий стать ответственным за команду - тимлид. Сеньйор априори не является тимлидом, так как банально не обязан, не может, не интересно думать за всю команду. Т.е. может он и может, но не хочет.
DANic
02.10.2023 09:22+1А как же техлид?
PuerteMuerte
02.10.2023 09:22Техлид, это одна из ролей в команде, это не градация скиллов. В особых случаях можно быть и джуном-техлидом, если все сбежали, а ты после трёх месяцев стажировки остался :)
Batalmv
02.10.2023 09:22Ну я же написал, это по факту ответственный за команду разработчиков. Т.е. это никак не показатель его скилов разработчика. Т.е. своего рода перпендикулярная ось измерения.
Техлид - менеджерская позиция. Более того, техлид не обязательно является разработчиком. К примеру, я как архитектор, могу выступать (и часто выступаю) как техлид на проекте. Хотя как разработчик я на уровне джуна часто, в зависимости от технологии.
DANic
02.10.2023 09:22Я хотел сказать что достигнув в хард скилах уровня Сеньйора, дальнейший рост может быть сторону тимилида и/или техлида
Все же в роль техлида более техническая, тимлида более менеджерская
apachik
02.10.2023 09:22+9вот моя вариация:
- Крепкий мидл может решить любую проблему.
- Сеньор работает так, чтобы проблемы не возникали (ну или не создает проблем).
- Тимлид умеет делать так, чтобы другие не создавали проблем.
- Следующий уровень - это осаживать бизнес от бредовых идей.
Soupbreak
02.10.2023 09:22+4Это значит, что нужно будет понимать +‑ в целом архитектуру всего проекта.
Нет, более того даже тимлид не обязан понимать архитектуру проекта. Хотя бы потому, что это может быть бывший QA, аналитик, PO
Иметь нужные доступы по работе, подменять иногда тимлида, чтобы при уходе оного в отпуск проект не останавливался в ступоре.
Доступы к чему? Остановился в чем? Тимлид не определяет набор бэклога, например
При необходимости участвовать в совещаниях по планированию и интеграций.
Интеграции также определяет и планирует не тимлид, а посыл именно в этом. Что не отменяет того, что тем кто будет реализовывать функционал, полезно присутствовать на таких обсуждениях
Не замыкаться только лишь на своих задачах и понимать куда идет разработка в целом.
Разработка, как и аналитика и тестирование идет ровно туда, куда определит PO
Уровень soft‑skills должен быть на должном уровне, чтобы можно было вести переговоры с другими командами, решать конфликты внутри команды и не создавать их самому.
Не создавать конфликты навык необходимый в принципе на любой позиции
Проблема в том, что почему-то Team Lead представляется часто, как самый опытный разработчик или же руководитель над другими разработчиками. Но для этого есть другие позиции и роли, например, Tech Lead или SEM
Team Lead вообще не обязан быть бывшим разработчиком, и в его скоуп работ, как и написано в роли, входит организация работы команды, а не ревью/написание кода
BugM
02.10.2023 09:22Team Lead вообще не обязан быть бывшим разработчиком, и в его скоуп работ, как и написано в роли, входит организация работы команды, а не ревью/написание кода
Не дай бог. Он же просто будет говорить с командой разработки на разных языках.
И подобные радости:
Разработчик берет фичу и оценивает ее в 3 месяца разработки, на выходе через 3 месяца пристойно работающая фича и 5 тысяч строк кода. Со стороны бизнеса описание такой фичи может быть любым. От добавь вот тут кнопочку паузы процесса, до разработай 10 форм.
Дать этому разработчику премию или уволить его? Кто и как это в вашей команде с лидом не писавшим код будет решать?
Lewigh
02.10.2023 09:22+7Дали задачу пяти разработчикам:
junior
не смог решить
middle
в лоб написал 1000 строк запутанного кода
middle+
использовал паттерны, порешал в 500 строк чистого кода
middle++
используя всю мощь ФП, современные подходы и мудрость поколений решил в 100 строк восхитительного, чистого, быстрого, идиоматически правильного кода
senior
немного подумав, решил в 0 строк кодаPuerteMuerte
02.10.2023 09:22+25manager
выставил заказчику счёт за 1600 строк написанного кода, накинул в инвойс ещё сумму за время, потраченное джуном на размышления, вписал работу тестеров и управление проектом, а сеньору сказал, чтобы тот поменьше выделывался, и выполнял kpi.
Hlad
02.10.2023 09:22+2Забавно, что в градации полностью отсутствует выходной результат (ну, там, производительность получившегося кода, или занимаемые ресурсы...)
dsh2dsh
02.10.2023 09:22+1Так это, по моим наблюдениям, сейчас вообще никого не волнует. Ну может быть, опосредованно, пользователя. Только его мнение тоже никого не волнует. Современная беда.
Keeper9
02.10.2023 09:22+2senior
Немного подумав, написал строчку с grep + awk.
saboteur_kiev
02.10.2023 09:22+1это девопс.
Современные разработчики в силу профдеформации не могут написать не-ООП решениеBugM
02.10.2023 09:22+1ФП уже проникло достаточно глубоко. Сейчас как раз часто не ООП код пишут. ФП проще и надежнее выходит обычно.
mikronavt
02.10.2023 09:22Техлид/архитектор - зарубил все пулл-реквесты, и заставил выносить решение в отдельный сервис.
yakimchuk-ry
02.10.2023 09:22+3Да забудьте вообще про эти градации. Главное польза приносимая продукту, и каждый как умеет, так и вкладывает свои усилия и навыки. Кто-то лучше, кто-то хуже в силу отсутствия опыта. Вот и вся формула.
Я видел проекты где "мидлы" лидили проект, и наоборот, где лиды работали на позиции разработчика, и всё было нормально.
Важна не градация, а средний уровень разработчиков и как они работают в команде. Опыт дело поправимое, важны сами люди, и как они работают. У нас есть ребята которые были стажеры, но быстро учатся и местами за ними не успеваешь, шустрые пацаны, за пару лет так натаскались что уже знают такие штуки, про которые старики уже не знают.
Поэтому, люди... Важны именно люди, как они работают, их подход, а опыт дело приходящее.
1755
02.10.2023 09:22Согласен, командная работа решает. 10 даже средних разработчиков, но с хорошей коммуникацией, процессами и командной работой, думаю, сделают надежнее и предсказуемее результат, чем 10 суперзвезд-снобов индивидуалистов. В среднесрочной-долгосрочной перспективе.
SpiderEkb
02.10.2023 09:22+1Кабы все так всегда однозначно было...
И так и этак может быть. Одно дело пилить типовой проект на время в стиле картины "Бурлаки на Волге" - там да, суперзвезды не нужны. Нужна команда бурлаков.
Другое дело когда в результат масштабирования системы он перестает справляться с нагрузкой и требуется предельно оптимизировать узкие места без переделывания всего и вся - тут уже мало бурлаков, нужны "суперзвезды".
Так что все нужны и все важны. Большие прорывы как правило начинаются со "снобов-суперзвезд". Они задают направление. А бурлаки уже потом подтягиваются. Когда понятно куда двигаться.
Ну мне так кажется.
1755
02.10.2023 09:22Да, есть оптимизации и места, где оптимально будет взять одного суперзвезду на узкую оптимизацию.
azomorth
02.10.2023 09:22В чем будет отличие мидл-специалиста по СКУД и видеонаблюдению от сеньора?
А если взять не разработку, а системное администрирование?
Или мы все сходимся во мнении, что сеньор автономен, а мидлу надо ставить задачи и присматривать?
Ну вот например: специалист в компании закрывает вопросы по СКУД и видео, админит MS AD, сервера на Линуксе, пишет политики и регламенты - как определить его грейд?
Это будет мидл СКУД + сеньор админ + мидл техпис?
Или как?BugM
02.10.2023 09:22В чем будет отличие мидл-специалиста по СКУД и видеонаблюдению от сеньора?А если взять не разработку, а системное администрирование?
Да как везде. Сеньор сделает вам готовый проект так что он будет потом работать десятилетиями без особых проблем. Без привлечения других экспертов.
Мидл или накосячит в паре мест что переделывать придется или будет звать внешних экспертов для всяких тонкостей.
специалист в компании закрывает вопросы по СКУД и видео, админит MS AD, сервера на Линуксе, пишет политики и регламенты
Эникейщик. Ничего не умеет на самом деле. Максимум джун везде.
PuerteMuerte
02.10.2023 09:22Да как везде. Сеньор сделает вам готовый проект так что он будет потом работать десятилетиями без особых проблем. Без привлечения других экспертов.
Ну так и миддл в случае СКУД сделает так же :)
Эникейщик. Ничего не умеет на самом деле.
Как же ничего не умеет? Наоборот, умеет в СКУД, в AD, в линукс, и в документирование. Люди, которые закрывают вопросы по разным направлениям, они наоборот, умеют много, а не "ничего не умеют". Сеньор, который знает несколько смежных направлений, это отнюдь не редкость, а норма. Наоборот, специалист, который якобы хорошо знает только что-то одно и джун во всех остальных смежых областях, это скорее исключение.
BugM
02.10.2023 09:22Ну так и миддл в случае СКУД сделает так же :)
Верю на слово, ибо не разбираюсь.
Значит это коммон область где сеньоры невозможны. Это нормально. Все изучено, есть решения для всех случаев и надо просто грамотно им следовать. Мидл это вершина развития в такой области.
Как же ничего не умеет?
Вот так. У человека ни времени ни головы на столько разных областей не хватит. Чтобы их изучить на хорошем уровне и вляпаться и успешно выбраться из множества разных корнер кейсов. Сеньор вероятно заранее знает решение вашей проблемы потому что он пять очень похожих уже успешно решил.
Сеньор, который знает несколько смежных направлений, это отнюдь не редкость, а норма.
Это не смешные области. Это абсолютно разные области. Для админа смежное это девопс, например. Запилить поднимающиеся и умирающие временные окружения для разработки админ вполне может. Сети на уровне милда (мидла провайдера или бигтеха) типичный хороший админ вероятно знает. А вот даже типичная корпоративная AD с не менее типичными эксченджами и прочей требухой в ней для линукс админа это темный лес. К СКУД он и пальцем не притронется.
PuerteMuerte
02.10.2023 09:22Значит это коммон область где сеньоры невозможны.
Возможны, просто проектирование и монтаж в области СКУД - это работа, которая не требует специалистов высокого профиля. Какие-то расширенные знания требуются для иных вещей, зачастую спрятанных от клиентов. Например, тестирование и интеграция новых компонент, которые появились в ассортименте у поставщиков. Или в граничных вещах, например, интеграция СКУД с чем-то, для чего нет стандартных решений.
Это не смешные области. Это абсолютно разные области.
Неа, очень даже смежные. СКУД - всего лишь ещё одна железяка с сервером и софтом в инвентори у админа, она вообще не требует никаких специальных знаний, которые отсутствуют в багаже у админа. Что он там не сможет сделать, логи посмотреть и почитать в чём проблема, или там витуху обжать при необходимости? Корпоративная AD? AD, это всего лишь одна из реализаций LDAP, который отнюдь не чужд линуксовому миру, и в нём же и зародился. Что там может смутить линуксового админа, кроме личной неприязни к форточкам?
Вот так. У человека ни времени ни головы на столько разных областей не хватит.
Нет, я правда не понимаю. Как это не хватит? Мы же с вами не говорим про сеньора-программиста node.js, который одновременно сеньор-разраб микроконтроллеров и сеньор-сосудистый хирург. Это всё несколько смежных направлений в пусть довольно обширной, но все равно одной и той же области - администрирование корпоративной инфрастуктуры. Направления отнюдь не обширные, на уровне "уметь решать вообще все задачи, которые у вас могут возникнуть" познаются за несколько лет.
CorwinH
02.10.2023 09:22Мидл - это программист.
Сеньор - это программист + архитектор + аналитик.
Но не руководитель проекта. Решать, какую фичу реализовываем в первую очередь, он не должен.
1755
02.10.2023 09:22+1В разработке есть только две сложных задачи: инвалидация кеша и наименование переменных. Предлагаю добавить в этот список третью - классификацию разработчиков. Уже второй десяток лет обсуждают кто миддл, а кто сеньор и у каждого есть свое мнение на этот счет :)
sibirier
02.10.2023 09:22Я бы первую проблему обобщил. Про наименование переменных согласен.
Я всегда называл одной из двух сложных проблем разработки - отладку конкурентного кода. Инвалидация кэша одна из похожих задач, но всё же это достаточно конкретная одна задача, хотя таких задач целый класс.
Более точно, кмк, звучала бы абстракция "идемпотнетность конкурентных процессов*" = независимость результата работы функции от порядка, количества и контекста её вызова, если такая независимость требуется. А конкурентными алгоритмами являются и инвалидация кэша, и асинхронное выполнение операций над ресурсами одной системы, и потоковое объединение данных из разных источников. Д даже порядок вызовов include в коде на С или require в Lua может влиять на итоговый результат, хотя не всегда это желаемый эффект.
* - "процесс" в общем понимании слова, не в контексте ОС.
Вот только в такой формулировке, думаю, можно описать большинство задач из любой сферы деятельности, не только IT.
Lexicon
02.10.2023 09:22+2Эта тема ниочем, в сухом остатке, синьор это тот, кто кого взяли на синьорскую должность и/или зп.
Прошёл собес и сидишь на встречах 24/7 не написав и строчки кода? Поздравляю, тебе даже не нужно уметь кодить.
Может я нафармил ЧСВ, но встречал множество людей с множеством лычек, множество из которых вводили меня в ступор и желание скорее сбежать, пока не начал кидаться на людей. Техлиды, синьоры, архитектора из сферы вроде банковской бросают в холодный пот, что можно сделать человеку пластиковым стаканчиком? хорошо, что в кафе нет вилок
SpiderEkb
02.10.2023 09:22Техлиды, синьоры, архитектора из сферы вроде банковской бросают в холодный пот
Зря вы так. Там цена ошибки крайне высока, а система запредельно сложна. Так что там все очень консервативно.
Мало кто представляет себе сколько процессов постоянно крутится на центральном сервере банка в фоновом режиме. И сколько там данных постоянно перелопачивается. И во что выливается для разработчиков ядровых систем очередная "креативная фича" в мобильном приложении.
Lexicon
02.10.2023 09:22Зря вы так. Там цена ошибки крайне высока, а система запредельно сложна.
Да бросьте, так везде говорят. Я банковскую сферу и упоминаю, потому, что до боли знаком с людьми, проектами и системами оттуда. Умение некомпетентных людей строить сложную систему, непонятную никому, включая создателей из элементарной задачи это пожалуй самое яркое впечатление.
SpiderEkb
02.10.2023 09:22Я банковскую сферу и упоминаю, потому, что до боли знаком с людьми, проектами и системами оттуда
Ну я тоже знаком. И на этом основании говорю.
Во-первых, систем и проектов там очень много. У нас это центральные системы (центральные сервера и работающая на них АБС) и вокруг них еще несколько десятков внешних систем. Я даже затруднюсь все перечислить.
Во-вторых, эту задачу я никак не назову "элементарной", просто примерно представляя тот функционал, который там крутится. Даже если ограничиться только центральными системами. И те объемы данных с которыми приходится работать.
В-третьих, то, что крутится на серверах, в большинстве своем mission critical. Отказ чего-то, даже казалось бы небольшого, может потянуть за собой только прямых убытков на десятки миллионов. Плюс репутационные. Плюс потенциальное нарушение требований регулятора (время недоступности основных систем нормируется минутами), а это как минимум штрафы, максимум - потеря лицензии.
Lexicon
02.10.2023 09:22Мне кажется это достойные темы для дискуссии
Но мы в треде "В чем разница между мидлом и сеньором", выраженный мной тезис "в банковской сфере очень много некомпетентных людей, нанятых по принципу "вы же погромист?", как пример, области где человеку легко получить лычку
SpiderEkb
02.10.2023 09:22Давайте так. Что вы подразумеваете под "банковской сферой"?
Вот я разработчик центральных банковских систем. Платформа IBM i, DB2 for i, SQL, RPG, C/C++. Ну вроде как сеньор, наверное (по крайне мере в разработке у нас уже позиций выше нет, дальше только архитектор направления, но это уже не то - вообще не мое, пробовал, отказался). Или лид (по крайне мере техлид направления - комплаенс).
Вы что, всерьез думаете, что могу вот так просто взять и перейти в разработку WBI? Или мобильного приложения? Или сайта? Да ни разу. Там свои стеки, свои задачи, своя архитектура, свои подходы. Да же при том, что все это в одном и том же банке.
Больше скажу, даже есть я перейду из команды комплаенса в команду системы расчетов (например) - уже потребуется время чтобы в их процессы и сущности вникнуть. Хоть это и на том же сервере и том же стеке работает. Даже при том, что смежные темы у нас есть (тот же контроль платежей по которому я работал).
И я не знаю где нанимают по указанному вами принципу "ты же программист".
Нет, у нас, конечно, примерно так и нанимают. Просто потому, что разработчиков под IBM i в стране пара-тройка сотен всего. Людей, которые эту платформу знают и понимают как она работает (назовите принципиальные отличия объектов типа *DTAQ от *USRQ) . И примерно столько же кто знает основной наш язык RPG (более 80-ти процентов кода под эту платформу на нем пишется) - назовите ососбенности инициализации полей структуры и какие там подводные камни могут быть.
Поэтому да. Берем людей с опытом разработки и обучаем сами. Но это не значит это не компетентные люди. Повторюсь - на уровне ядра АБС некомпетентность разработчика обходится банку слишком дорого. А уж что-то, а деньги тут умеют считать.
MrNutz
02.10.2023 09:22+1Все просто. Сеньор это состояние, когда ключевой навык это решение поставленной задачи или проблемы.
Например, джуна надо вести за ручку, мидлу поставить чётко конкретную задачу. Синьору достаточно просто дать задание что то сделать. Задание любого уровня. Сам изучит ситуацию и разберётся, сам найдёт решения и нужные инструменты.
В общем, это "решала" от мира ИТ.
khavronsky
02.10.2023 09:22Не согласен с равнением на лида, это разные компетенции и иногда замом лида может быть просто опытный миддл. Вообще, если миддл - это опытный джун, то сеньор это далеко не опытный миддл. Миддами с опытом становятся все, а вот сеньорами нет. Сеньор - это болше про экспертность в своей области.
gun_dose
02.10.2023 09:22Всё просто: джун копирует код на Stackoverflow из вопроса. Миддл - из ответа. А сеньор вообще забыл дорогу на Stackoverflow, потому что привык, что по большинству сложных задач решения в интернете нет.
PuerteMuerte
02.10.2023 09:22А сеньор вообще забыл дорогу на Stackoverflow, потому что привык, что по большинству сложных задач решения в интернете нет.
Сеньоры тоже постоянно копируют код из SO, просто потому что всё в голове наизусть не удержишь, а то, что удержишь, целиком писать зачастую лень, если можно готовые сниппеты надёргать. А сложные задачи... а сложные задачи, они отнюдь не каждый день случаются. И даже далеко не каждый месяц.
gun_dose
02.10.2023 09:22Я сеньор уже много лет, и с трудом вспомню, когда в последний раз приходилось копировать код со Stackoverflow. Если задача простая и маленькая, то код пишешь сразу из головы, не думая. Не потому что помнишь, а потому что знаешь, как воспроизвести. Если же надо воспроизвести длинный кусок кода, то он, как правило, берётся из другой части проекта, или из другого проекта или прямо из ядра фреймворка, библиотеки и т.д. Если под рукой нужного сниппета нет, то он копируется из документации или папки examples в репозитории используемого решения. И вот только если во всех вышеуказанных местах ничего не нашлось, тогда идёшь на Stackoverflow.
PuerteMuerte
02.10.2023 09:22Ну так и миддл и даже джун будет делать то же самое. Текущий проект - это первоисточник, понятное дело, что если там надо сделать очередной эндпойнт или что-то в этом роде, ты просто скопируешь соседний и переименуешь. На SO ходят, когда надо добавить что-то новое в проекте. Например, первый эндпойнт.
gun_dose
02.10.2023 09:22Сеньор никогда не будет копировать код первого эндпоинта с SO, потому что для этого есть во-первых генераторы кода, а во-вторых, документация. Stackoverflow в данном случае вообще лишний. И джун не будет делать то же самое. Когда у джуна возникает вопрос, он идёт гуглить ответ. Когда вопрос возникает у сеньора, он либо уже знает, где именно написан ответ, либо придумывает его сам.
PuerteMuerte
02.10.2023 09:22Сеньор никогда не будет копировать код первого эндпоинта с SO, потому что для этого есть во-первых генераторы кода, а во-вторых, документация.
Кстати, есть одно железное отличие сеньора от миддла. Сеньор, по квалификации, а не по должности, никогда не будет говорить "никогда". Категоричность, это непрофессионализм или недопрофессионализм, человек с хорошим опытом дожен знать, что у любого подхода есть граничные условия, где он эффективен, и не эффективен за их пределами.
Например, про копирование кода эндпойнта, есть немало причин делать это вручную, а не использовать сваггер и ему подобные. И это если речь идёт о заголовках. А я вообще писал не про заголовки, а про реализацию (наверное же очевидно, что заголовки вашего эндпойнта на SO уж точно не валяются). А там, извините, хоть генераторы для некоторых платформ и существуют, какие-либо преимущества перед ручным кодом они дают только в очень частных случаях, в остальных их использование в лучшем случае вкусовщина, в худшем - оверхед. И раз вы себя позиционируете как сеньор, то странно, что вы про это не в курсе.
gun_dose
02.10.2023 09:22Никогда, никогда, никогда сеньор-разработчик не будет копировать код первого эндпоинта со Stackoverflow. Он может его скопировать из документации, из папки examples или demo, с другого проекта. Но никогда не со Stackoverflow.
PuerteMuerte
02.10.2023 09:22Ну тогда раскройте свою мысль, что ли. Я причины легко могу назвать: вы садитесь начинать новый проект, у вас нет папки examples или demo (ибо откуда она у вас взялась-то? Я последний раз что-то такое видел в 90-е годы, когда ещё ставил галочку "устанавливать примеры" при установке IDE), и это ещё стадия PoC, на которой проектировать апи ещё никто не садился, соответственно, доков openapi нет и не ожидается, а надо через три дня что-то работающее показать. А скачать сниппет на SO - это несколько секунд, куда быстрее, чем лезть в предыдущие проекты, где что-то подобное.
gun_dose
02.10.2023 09:22Моя мысль изложена в моём первом комментарии. Но поясню ваши вопросы: examples и demo - это в javascript экосистеме принято. Любой пакет или либа имеет либо такую папочку, либо онлайн-демо. Но это конечно не об эндпоинтах.
Говоря о документации, я имею в виду не openapi документацию для эндпоинта, а обычную документацию для фреймворка или библиотеки. Как правило, в нормальных фреймворках в документации есть примеры эндпоинтов. И эти примеры будут проверены и утверждены сообществом, в отличие от Stackoverflow, где может писать каждый. Я вот реально не понимаю, что может быть за такая технология, где будучи сеньор-разработчиком с ходу надо лезть не в доки, а на Stackoverflow.
PuerteMuerte
02.10.2023 09:22Моя мысль изложена в моём первом комментарии. Но поясню ваши вопросы: 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 не как источник знаний (мы ведь говорим про человека, у которого они уже есть), а как источник готового кода.
titan_pc
02.10.2023 09:22Эх. Вымерли техлиды в умах живущих... У всех заканчивается ветка на тимлидстве
BugM
02.10.2023 09:22Джун пишет код под присмотром других разработчиков.
Мидл пишет код без присмотра других разработчиков.
Сеньор решает проблемы.
Gromilo
В моём уютном мирке бэкенд программистов отдельно взятой компании, получилось, что сеньор - это человек, которому можно доверить задачи уровня проекта. Он сам вытянет нужные знания, пнёт нужных людей (типа аналитика), согласует с заинтересованных лицами (в рамках договорённостей) и доведёт задачу до завершения так, что не придётся переделывать.
Грубо говоря сеньор - это мидл + софт скилы + умение делать проекты.
SpiderEkb
В наших болотах сеньор - это нечто условное. Ибо штатное расписание имеет немного больше градаций - разработчик - старший разработчик - ведущий разработчик - главный разработчик. И сеньор - это скорее ведущий и главный, хотя и мидл может быть как старшим, так и ведущим, а бывают и джуны на ставке старшего...
Но разработчик напрямую с заказчиками (бизнес-линии) не общается практически. Это задача аналитика. Да, бывает что разработчика приглашают на встречи аналитика с бизнесом, бывает что разработчик напрямую общается с "консультантом направления" (это уже не совсем аналитик, но еще и не совсем бизнес).
Есть говорить про разницу между мидлом и сеньором, то она прежде всего в том, что сеньор - это, как правило, еще и техлид. Т.е. человек, более-менее ориентирующийся в предметной области (той ее части, которая обращена к разработке). Т.е. сеньору не надо в ТЗ расписывать что и как с чем связано - он сам понимает по каким таблицам эффективнее построить отбор нужных данных (как пример). Еще и рекомендации даст - вот тут индекс добавить, там витрину лучше бы организовать.
Но из этого, также, следует и то, что сеньор "контектснозависим" - со сменой области деятельности или даже направления (команды), он на какое-то время перестает быть сеньором (как это ни парадоксально) в данной конкретной области (до тех пор, пока не вникнет в нее).
А вообще, все эти лычки такая условность... Никогда не позиционировал сябя в этих градациях. Исключительно как "разработчик", "есть опыт в том-то и том-то", "умею то-то и то-то". А там хоть клизмой назовите, только в ... не суйте.
Ivan22
"А вообще, все эти лычки такая условность" пока работаешь за еду да.... а вот если хочется хорошей ЗП
SpiderEkb
Если хочется хорошей ЗР, надо не лычкой трясти, а что-то реально уметь и знать.
Повторюсь - лычка - это внутри конкретной компании/проекта. Перейди на другой проект и лычка слетит мигом. Если, конечно, это не типовое формишлепство где в общем-то все равно - инетлабаз и порносайт клепать.
А там где сложная логика какая-то - там уже в предметной области ориентироваться надо. Или что-то системное - надо платформу знать.
Понятно, что если опыт большой в близких областях, то и адаптация быстро пойдет. Но сразу прийти и моментально во все вникнуть - так не бывает.
Так что лычки - это так, ЧСВ почесать.
Ivan22
и отчего же на собесах в FAANG уровень определяют по алгоритмам и архитектурному дизайну, а не по знанию какой-то предметной области??? И навешивают лычку и денег отвешивают соответственно
Keeper9
Думаю, что собственно критерий отбора неважен. Сгодится любой критерий, позволяющий отбросить большое количество ненужных кандидатов.
См. "Законы Паркинсона", глава "ОКОНЧАТЕЛЬНЫЙ СПИСОК, или Принципы отбора кадров".
SpiderEkb
А что, мир ограничивается фаангом?
Ну придите к нам с лычкой фаанга - будет джуном бесплотным. Потому что ни платформы, на которой работаем, ни стека вы точно не знаете. Дай вам задачу конкретную - не сможете тривиально определить какие таблицы как связать и в каком случае какой подход использовать.
Пойдете в промавтоматизацию какую - там вообще все свое. Там с вас спросят знание потрохов всяких RTOS, и протоколов обмена (тот же MODBUS и иже с ними). И фаанговские лычки там не канают.
В любом месте вас будут спрашивать то, что потребуется в работе там. И вешать соотв. лычку. А в другом месте потребуется что-то совершенно иное. Соотв. и спрос иной.
Да даже в том же гугле направлений более чем. Всякие веб приблуды - только одно из них. А как у вас с системной разработкой? Ядро того же андроида писать на уровне сеньора потяните? А теорию компиляторов учили (то же GO пилить)? Пройдете собес?
nameless323
И по алгоритмам, и по знанию предметной области, чем выше уровень кандидата, тем больше уклон в предметную область. Лычку дают локальную для локального же референса, которая не переходит в другие фаанг кампании.