Чим Senior відрізняється від Junior чи Middle? Тільки вміннями чи чимось більше?
Поділіться своїм досвідом: що, на вашу думку, допомагає Junior перетворитися на Senior у своїй справі?
До речі, у нас ще є цікава стаття на цю тематику. Загляньте — там є багато корисного.
У компаній насправді значно більше тайтлів буває. На заході ще розповсюджені звання Staff та Principal. Ще буває і Fellow. Відповідно до розмірів компанії звання відповідають посадам технічного керівника. (Ще буває комбінують у величезних компаніях типу Google з розряду Senior Staff, або Junior Fellow з розряду генерал майор та генерал лейтенант). Якщо брати класифікацію із PMI то від проекту до портфелю, тобто Staff відповідає посаді лінійного технічного менеджера, а Fellow начальника групи підрозділів (віце-президента, старшого директора, міністра, генерала, адмірала і т.п. як це зветься в різних організаціях).
В чому різниця на рівні виконавців, тут вже пояснили.
Ну і тайтли лише тайтли, звісно CTO шлюпки на 5 людей «Рогата копита» часто не відповідає рівню Staff великої компанії де в проекті може бути 40 людей (відповідно і зарплата і т.д.), та як і в армії в різних видах військ звання в різних підрозділах однієї і тієї самої компанії так само не відповідають. Умовно капітан піхоти, та капітан авіації — це абсолютно різний рівень в посадах. Перший командир до 100 людей, другий стройовий пілот і командир максимум
Junior — набириється досвідом
Middle — використовує досвід
Senior — ділиться досвідом
Senior — це той хто в момент постановки задачі каже чому так не вийде. А якщо таска вже оформлена — може адекватно пояснити чому ні.
PS. Якщо все ок, то ок. Але від нас чекають трохи більшого завжди.
Senior — це той хто в момент постановки задачі каже чому так не вийде.
це експерт )) я провіряв
Ні. Це наша звичайна робота )
Ці погони, лише взаємна згода компанії та робітника щодо оплати та тайтлу.
Існують інженери та розробники. Розробники вміють стукати молотком, інженери вміють вигадувати та проектувати.
Додайте до цього А) Досвід, та Б) Рівень відповідальності.
А JMS — то для его-турбації =)
Junior — може вирішити задачу, в якої або одне рішення, або декілька, але лід підказав яке.
Middle — може вирішити задачу, в якої декілька рішень, та обирає найбільш оптимальне тут і зараз.
Senior — вирішує задачі, в яких нема рішень, здатен так змінити вимоги, щоб задачу можна було вирішити.
задачі, в яких нема рішень, здатен так змінити вимоги, щоб задачу можна було вирішити.
ніт то не сіньор сіньор так не вміє
сіньор реально що вміє то є
вирішує задачі
але лід підказав яке.
максимум що зможе сіньор у роскладі то дійти до місця де подальше просування згідно вимог стане не можливим як то увійде у вже очевидний contradiction і тоді вже хтось «згори» щось «вирішить» як то зокрема «відкинути задачу взагалі»
... але зауважте на слові «максимум» бо «у середньому» сіньор звичайний ні коли туди навіть не дойде саме до місця де подальше просування згідно вимог стане не можливим як то увійде у вже очевидний contradiction і у середньому у самім процесі вже потребуватиме зовнішній overseeing щоб побачити таку точку або просто визначити командного рівня рішення «ок до оцього моменту копаємо далі видаємо результат будь який який є по результату (у т.ч. просто нема ні якого результату) і тоді приймаємо рішення копать чи не копать»
тож фактичний максимум який можер вирішувати «реальний сіньор» то лише мати навичку копать самостійно у грубій оцінці 50/50 досягаючи результат (бодай який) у випадках
задачі, в яких нема рішень
та може 80/20 або навіть більше у випадках
задачу, в якої або одне рішення, або декілька
Senior Engineer — це просто старший інженер, одна з посад на довгому кар’єрному шляху спеціаліста. Не обмежуйте свою кар’єру посадою старшого інженера і не зводьте цю посаду в культ.
Джун — не умеет работать.
Мидл — умеет работать.
Синьор — умеет не работать
Джун — не знає як треба робити
Мідл — знає, як треба робити
Сенйор — знає, як НЕ треба робити
Junior — не працює, вчиться працювати
Middle — працює
Senior — працює, вчиться не працювати
Software Architect — не працює
Solution Architect — не працює, вчиться заважати працювати
CTO — заважає працювати
Solution Architect — не працює, вчиться заважати працювати
загалом то є його основна робота і є вчиться вже піздно работать нада ))
1. Не сцить брати відповідальність
2. Може самостійно вирішувати великі задачі чи проекти
Багато хто згадує про постановку задачі і я з цим погоджусь, але як на мене також не потрібно забувати за горизонт планування спеціаліста. Так як скоріш за все джун напише код, який чітко виконує поставлену задачу, але буде максимально простим та без можливості модифікації та масштабування. Мідл вже буде писати із думкою, а які речі можна перевикористати та з ідеєю на майбутнє масштабування модуля, а сенйор буде також думати про те, як би в ході вирішення цієї задачі не зачепити, а то і покращити роботу інших модулів, і масштаб охоплення вже весь проект. Також сенйор буде сам собі ставити задачі по покращенню роботи над проектом для всієї команди, покращення структури, опис роботи цього модуля в межах всієї системи.
Ось так виглядає різниця із погляду мідла embedded розробника на С.
Сеніор чує завдання і знає що робити. Джун чує, гуглить(чи ейаїть) і пише те, що згодом переписуватиме (якщо пройде ревю). Мідл робить те саме, що й джун, тільки знає де треба поправити щоб не переписувати😅
Очевидна відповідь що відрізняється досвідом. Але наступним буде питання: а що саме цей досвід?
Сучасною мовою можна сказати що досвід — це данні на яких навчався не-штучний інтелект професіонала. Навіть не-спеціалісти у ШІ розуміють наскільки важливі данні, на яких навчається модель. Бо фактично від них залежить що вона буде вміти, а що — ні. І що буде робити добре, а що — погано.
Тому і кажуть що досвід не можна нічим замінити. Не можна відразу стати синьйором просто перечитавши багато книг. Досвід — це система зі зворотнім навчанням, а отже — потребує багато спроб, помилок і висновків.
Мене свого часу дуже дратувало коли .Net синьорам доводилося стати Full Stack синьйорами. Насправді будь-який .Net девелопер вже Full Stack і навіть більше: бо на .Net можна написати усе: і GUI, і сайт, і мобільний аплікейшин і навіть щось для embeded девайсів.
Але коли синьйор з досвідом .Net 10+ років витрачає пару місяців або почитати книжки та пройти декілька курсів Front End — це аж ніяк не зробить його Front-End синьйором!
А отже девелопер, якого галера продає як Full Stack Senior — насправді Back-End 90% та Front-End 10%. Відповідно і якість front-end коду буде на рівні джунів.
Досвід ніщо не може замінити!
Коли девелопер робить помилки, то це необов’язково про*оби або погана робота. Бувають такі задачі, де помилки- це частина роботи. «На досвіді» такі задачі робляться успішніше.
Зазвичай, технічні задачі такого штибу трапляються на рівні «людського фактору», але бува й на нових, необкатаних технологіях, коли йдеш недостатньо протореним шляхом.
Джуну треба допомога з тасками.
Мідл — робить таски.
Сеніор — роздає таски.
(Лід це сеніор якому навішали додаткових обов’язків та відповідальності без відповідного інкременту зп)
Junior: 8 годин пише код
Middle: 4 години мітинги, 4 години пише код
Senior: 1 година мітинги, 5 години розбирається що тут відбувається, 1 годину пише код
Чим вищий рівень інженера тим «менш технічну» постановку задачі йому треба і «більш об’ємну» роботу він може зробити.
Тобто сіньор зможе зробити «треба висилати інвойси коли продукт оплачений».
Мід зможе зробити «генерувати pdf для інвойсу», «прикрутити 3rdparty для розрахунку VAT», «надсилати імейл з приатаченим інвойсом».
Джун зможе «прикрутити AWS SES для насилання імейлів», «добавити нові філди A,B,C до інвойсу».
Техлід ще й організує документацію, CI/CD, якісний код, тести.
В кінцевому результаті все зводиться до досвіду, вміння задавати потрібні питання і передбачати майбутні зміни і можливі проблеми.
Junior: каже що зробить задачу за 4 години, робить за 8, логає 8.
Middle: каже що зробить задачу за 4 години, робить за 4, логає 4.
Senior, каже що зробить задачу за 4 години, робить за 2, логає 8. Відпочиває.
Десь таке читав, що джун має вміти вносити зміни в наявні модулі, мідл — самостійно написати новий модуль в системі, а сеньйор може всю систему з 0.
Один всю систему? Ніколи не зможе. Якщо мова звичайно про SSE, а не якогось унікума, який і PM+BA, і Front-end, і Back-end, і Архітектор. Проте це виняток з правила, підтвердження якому ще треба пошукати.
Може, бо те що ви описали це ентерпрайзно-галерний оверхед. Оці всі срам мастери шизнес аналітики та рахітектори.
Тобто 99% нашого ІТ?
Звичайно якщо у вас прямий контракт чи ви працюєте у гугл, то може там по іншому, але ми тут в Україні дуже прості та приземлені люди.
А яка різниця яке айті.
Просто виходить що __згідно з тим визначенням__ в українському, да і не тільки айті — багато людей не сеніори, от і все.
Окрім різного менеджменту є ще дизайн, тестування тощо. Не може все-все зробити одна людина. Це такі самі казки галєрних вождів, як і «дуже потрібні» архітектори.
Один всю систему? Ніколи не зможе.
тобто ніколи не чули про Linux, Git та одного шведськомовного фіна?
а про недолугого ватніка Сисоєва і nginx?
Ні. Зараз в одиночку не робляться продукти. Подєлки а-ля POC — можливо.
тобто ніколи не чули про Linux, Git та одного шведськомовного фіна?
а про недолугого ватніка Сисоєва і nginx?
Слышали. Там офигенно большой перечень разработчиков.
зы когда я был молодой и умный, я написал небольшую приблуду, которую я потом отдал «в хорошие руки». приблуда в принципе на 80% была рабочая, а может и на 90%. Чтобы довести её до состояния продукта понадобилось много времени и команда прогеров на 2 порядка сильнее меня
Прогнозована якість виконання задач, вміння ставити питання та рівень комунікації з замовником
Vic
Yuriy Tymchuk
Oleksii Kliuiev
Alex Fogol
Oleksii Kliuiev
Ihor Malovanyi
Vitaly Platonov
Dmytro Skorokhod
Maksym Tuhai
Pavlo Romaniuk
Dmytro
Александр Енотов
Donald Trump
Євгеній Федотов
Rostyk Chuma
Beaver Green
Gremlin
Yury Gavrilenko
Sir Lemur
Просто Анон
Afterlife
Andriy Shevchenko
Afterlife
Yury Gavrilenko
Oleg Korol
Evgeny Sergeev
Oleksii Kovalov
Дмитро
Evgeny Sergeev
34 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів