Как стать автором
Обновить

Чем отличается сениор от миддла, или как второму стать первым

Время на прочтение 6 мин
Количество просмотров 12K
Всего голосов 25: ↑17 и ↓8 +9
Комментарии 24

Комментарии 24

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

Потому что ему проще и быстрее сделать самому, чем управлять работой других людей.

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

Поэтому роль техлида заключается в том числе и в том, чтобы задавать правильное направление, а не только в решении конкретных задач. Для конкретных задач как раз нужны сеньоры.
Думаю перепутали техлид и тимлид
НЛО прилетело и опубликовало эту надпись здесь
Поддержу. Недавно читал комментарий к статье, где обсуждались паттерны проектирования. И человек высказал похожую мысль: люди стали использовать паттерны для того, чтобы можно было какое-то конкретное программное решение как-то БЫСТРО назвать. И потом сказать об этом другому человеку. И все. И не нужно вокруг этого религию городить. Похожая ситуация и с синьерами.
Представим на минуту, что есть 2 оффера — в одном большая ЗП, интересный проект, но будут называть джуном, а в другом — синьер с низкой ЗП и скучной работой. Может пара процентов с комплексами и выберут «синьера», а у остальных людей думаю хватит ума отделить суть от шелухи.
В этой статье сделали очень правильный упор на понимание инфраструктуры и бизнес требований.
По какой-то причине многие разработчики совершенно не интересуются инфраструктурой проекта, если он чуть более сложный чем 3-5 компонентов. Их не волнует где это крутится в продакшене, или даже в тест енвайрнменте. У них в дев компонент запустился, заглушки проверил — все.
А именно понимание инфраструктуры — это огромный слой различных решений.

Где хранить пароли и сертификаты — в конфигах, в базе, в специальном решении? С некоторыми решениями нужно интегрироваться, и не всегда бывает просто.

Как правильно интегрировать сервисы — лазить в общую базу, лазить друг к другу по API, ставить посредине какой-нить брокер, почему все это было сделано, где дало прирост а где лишнее усложнение?

Приведу простой пример.
Был монолит, десятки библиотек. Разделили на «микросервисы». Каждому нужны эти библиотеки. Но выделять в отдельный пакет не стали. Так с каждым микросервисом и бегает лишних 50-100 мегабайт библиотек.
Дев, который джун или мид — посчитает, что крупной конторе 50-100 мегабайт это же пшик.
А грамотный поинтересуется и посчитает. Например у нас 20 разработчиков. Пишем одновременно 2 релизных бренча и десятка два фича-бренчей. История билдов хранится как минимум десять дней, а те которые были задеплоены на тестовый енвайрнмент еще дольше. Храним бэкапы деплоя.
Умножаем 50-100 мегабайт на все это, получаем пару терабайт просто на библиотеки, которые дублируются несколько сотен раз. Бэкап гигабайта и бекап 100-300 гигабайт — очень разные по затратам вещи. Уже хранить артефакты в дженкинсе становится накладно, надо нексус/артифактори, надо retention policy, надо усложнять деплоймент.
Плюс каждый билд нагружен копированием, запаковыванием, распаковыванием. Даже не так жалко денег, сколько ненужного простоя ради вот такой простой вещи.
10 лет назад я решал проблему, когда Jenkins UI тормозил жутко, и люди не понимали в чем дело. А оказывается просто сотни билдов, каждый из которых после завершения тащит на мастер гигабайтный артефакт, просто забивает сеть. И в проекте работали очень умные инженеры. Просто не сильно интересовались инфраструктурой, которая за годы выросла и усложнилась.

Это только верхушка целой области, где многие сеньоры могут зубы обламать.
Вот кстати, пример хороших сеньорных комментариев в habr.com/ru/news/t/512936, где описан алгоритм 11-значного номера для идентификатора жителей РФ.

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

И это именно архитектурно-инфраструктурый взгляд.
Забавно, что наличие банальной логики стало признаком «сеньорства». Чуть ниже в комментах, утверждают, что отличие синьора от мидла — это то, что синьор будет сначала " в инфраструктуре разбираться", а потом только кодить. Т.е., если ты пришел на проект, и, вместо того, что бы тупо начать что-то кодить, абы как и абы зачем, сначала посмотрел код, как организована БД и т.п., то ты уже синьор. Ясно. Видимо, не ту должность я занимаю…
Ясно. Видимо, не ту должность я занимаю…

Видимо да, если нужно разжевывать смысл вышеуказанного текста.

что наличие банальной логики стало признаком «сеньорства».

Без банальной логики можно кодить. Но стать сеньором без банальной логики нельзя.

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

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

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

Простите, но мне непонятно, как вообще можно что-то кодить без банальной логики. Нет, ну конечно, можно просто «копировать-вставить», но ведь мы про реальные проекты. Как можно вносить изменения в проект, не понимая его общего устройства и того, как будут взаимодействовать твои изменения с остальной частью кода.
Разжевываю: тот, кто придумал 11-значный номер без идентификатора центра, и решил что каждый центр будет выдавать номера независимо, видимо не представлял себе как в принципе можно после этого синхронизировать данные, как в будущем строить системы, которые будут получать эти данные, выполнять по ним поиск. Как это все в принципе масштабировать.
Тут нужно понимание процессов как это работает.

Проблема в том, что вы считаете, что ваша логика единственно правильная. Я сталкивался с такими разработчиками, которые совершенно не толерантны к мнению коллег. Нередко, причиной такого поведения является именно это самое синьорство, поскольку почему-то именно эти виртуальные звания нередко используются вместо аргументов в споре. На вроде «я синьор, я лучше знаю. Точка!». Вот вам пример, относительно того же номера:
11-значный номер требует 5 байт. Население РФ — 120 млн. 120 млн*5 байт =примерно 572 мегабайта. Пусть будет 3хкратный запас номеров — это всего лишь 1716 мегабайт. Сгенерируем номера заранее и будем хранить их в ЕДИНСТВЕННОЙ базе, откуда все пользователи будут получать их по запросу. С этим справится любой простенький сервер. Запросы будут блокирующие, для исключения гонки. БАМ! Проблема решена — нам не нужно синхронизировать данные между разными базами, поскольку база у нас одна. Все «центры» просто выдают готовые номера из единой базы. Что, кстати, также позволит решить проблему с мошенничеством на местах, если вдруг такая возникнет.
Нет, ну конечно, можно просто «копировать-вставить», но ведь мы про реальные проекты.

Да, частенько такое и вижу.

Как можно вносить изменения в проект, не понимая его общего устройства и того, как будут взаимодействовать твои изменения с остальной частью кода.

Да легко. Надо еще один микросервис — скопировали другой, и начали его править. Зачем скопировали кучу переменных, которые не будут использоваться в новом микросервисе — неясно. Зачем скопировали какие-то маунты, кучу скриптов, чужие сертификаты — неясно. Потом может быть почистят, а может быть и нет.
Контейнеры позволяют каждому микросервису не мешать другим, неся кучу мусора.
Вот вам пример, относительно того же номера:
11-значный номер требует 5 байт. Население РФ — 120 млн. 120 млн*5 байт =примерно 572 мегабайта. Пусть будет 3хкратный запас номеров — это всего лишь 1716 мегабайт.

Давайте так.
Для населения нужно хранить номер и может быть еще какие-то данные? Или как вы привяжете номер к конкретному гражданину?
А если там нужно имя фамилия отчество, год рождения, номер паспорта, биометрические данные, фото — то уже и килобайта на каждого будет мало.

Сгенерируем номера заранее и будем хранить их в ЕДИНСТВЕННОЙ базе, откуда все пользователи будут получать их по запросу.

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

С этим справится любой простенький сервер.

Ну уже нет.

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

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

Что, кстати, также позволит решить проблему с мошенничеством на местах, если вдруг такая возникнет.

Каким это образом?
Какая разница выдал центр номер сам или запросил номер у другого центра?
Мошенничество в чем?

Давайте так.
Для населения нужно хранить номер и может быть еще какие-то данные? Или как вы привяжете номер к конкретному гражданину?
А если там нужно имя фамилия отчество, год рождения, номер паспорта, биометрические данные, фото — то уже и килобайта на каждого будет мало.

Простите, я что-то не понял — а в вашем случае что, не нужно эти данные хранить? Или мы все-таки про алгоритм генерации номеров? Хранение остальных данных гражданина никакого отношения к нему не имеет, поскольку номер будет всего лишь одним «параметров» гражданина.
В тех задании сказано, что данные должны храниться распределенно. Не должно быть единой базы. Каждый регион должен хранить своих пользователей.

Простите, но где вы это увидели? Этого нет ни в оригинальном посте, ни в законопроекте.
Ну уже нет.

Если бы на моем сервере стоимостью 5 евро/месяц не крутилась уже куча необходимых мне сервисов, я бы с легкостью продемонстрировал обратное.
Не хочу лишний раз трогать «боевой» сервер.
Центры должны выдавать номера кому-то. Вдобавок у вас получается схема, когда на каждый запрос в определенный центр, нужно сделать запрос в другой центр. Дополнительная точка отказа.

Эти номера будут выдаваться ЕДИНСТВЕННОМУ потребителю — «Единый федеральный информационный регистр сведений о гражданах страны, иностранных гражданах и лицах без гражданства» в качестве уникального идентификатора.
Каким это образом?
Какая разница выдал центр номер сам или запросил номер у другого центра?
Мошенничество в чем?

Самое простое, что я могу представить — это создать новую личность. Говорят, востребованная услуга.
Простите, я что-то не понял — а в вашем случае что, не нужно эти данные хранить?

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

Простите, но где вы это увидели? Этого нет ни в оригинальном посте, ни в законопроекте.

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

Но в случае полностью централизированного хранения, все упирается в скорость подключения. Из регионов. Из каждого удаленного маленького региона, где даже мобильный интернет может лежать часами а то и днями.
IMHO проще обеспечить каждый региональный центр сервером для хранения базы данных, чем всех связать в отказоустойчивую и быструю сеть. Плюс централизированную базу проще унести.
Зря вы так. Статья полезная, как минимум для джунов. Адекватные джуны почитают и попробуют осознать свое место в отрасли и куда и как им идти. А то у нас 100500 джунов через полгода уже «мидлы», через год — «синьоры», с соответствующими запросами. Всему свое время.
НЛО прилетело и опубликовало эту надпись здесь
Судя по описанию сеньёра из этой статьи — сеньер он только в данном проекте сеньер, потому как знает потребности бизнеса и инфраструктуру.

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

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

Разница в подходе.
Senior не рванется бегом закрывать тикеты в джире, а первым делом хотя бы поверхностно изучит предметную область, кодовую базу и потребности бизнеса.

Эх, если бы еще не требовали «бегом закрывать тикеты в джире»… Вот у меня, к примеру был случай, когда по смыслу нужно было автоматизировать один процесс и дело пошло бы гораздо быстрее. Я проявил инициативу, занялся автоматизацией, меня наругали за «таски в джире» и не дали завершить начатое, а через полгода, когда совсем уже стало невмоготу вопрос автоматизации опять всплыл, но я уже был занят другими задачами. И этим занимался другой человек.
Есть процессы вхождения, никто не поставит человека с первого дня в ситуацию принятия важных решений. На этом этапе и сениор будет задавать много вопросов, но его уровень позволит разобраться, осмыслить, продолжить. И никогда нормальный спец не будет принимать решения наугад.
Переходя на другой проект сеньёр автоматом становится мидлом, потому как не знает проекта, не знает причин выбора инфраструктурных решений, не понимает уровень говнокода с которым придется работать и бизнес потребности проекта.


Неправда. Ему просто понадобится определенное время на выяснение инфраструктуры нового проекта и бизнесов. Но ознакомиться с новой структурой и изучать как инфраструктура работает — это как раз и разница между сеньором и мидлом.

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

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

И напоследок — при приходе крутого специалиста, он решает задачи по мере сложности. Через месяц-два он вполне уже сможет сам принимать решения вполне продуманныею
Зарегистрируйтесь на Хабре , чтобы оставить комментарий