Комментарии 14
Вся проблема классификации джун-мид-сеньор заключается в том, что многомерные объекты пытаются классифицировать по одномерной шкале. Так можно классифицировать спортсмена по прыжкам в длинну. Чем дальше прыгает - тем выше у него звание (новичок, любитель, продвинутый, про). Но даже уже с бегом уже получаются другие измерения - получается многомерная шкала (спринт/стайер/марафон,эстафеты) - уже не классифицируешь. "Про" спринтер может быть обычным "любитель" в марафоне - и загнать всех "бегунов" в рамки 4х званий невозможно.
А все потуги подвести какую-то теорию под классификацию айтишников в эти 3 категории - заранее обречены на провал - и эта статья в том числе. Слишком много переменных: обучаемость, коммуникативность, знание принципов работы компьютера, опыт, везение, приятность голоса и красивые глаза, пет проекты, и т.д. и т.п., сотни их.
А все, кто с мозгами уже давно поняли - что это деление весьма субъективно. Корреляция конечно есть - но чаще всего только в рамках одной компании.
Есть «матрица компетентности программиста» - уже неплохая попытка сделать многомерную оценку навыков и расставлять приоритеты «сеньорности» в зависимости от нужд
Хотел бы взглянуть, но опять же, попытка классифицировать N-мерных сотрудников по 2-мерной шкале (надеюсь, я правильно интерпретировал слово "матрица") - не намного здравее, чем по 1-мерной. Получается просто какая-то не сильно репрезентативная хеш сумма.
На эту тему можно рассуждать вечно. Объективной оценке наша профессия поддаётся весьма слабо. Каких-то более-менее адекватных оценок можно достичь только замкнувшись внутри компании. При смене места работы - оцениваться придется заново (на собеседовании, разумеется, оценить не получится, можно только примерно прикинуть, а реальная оценка появится спустя полгода). Если сотрудник разрабатывал на C# ASP.NET MVC портал для сотрудников Роскосмоса в Росцифре, то кем он станет перейдя в геймдев стартап в Исландии на JS - одному богу известно.
Да нечего там глядеть. Никогда эти матрицы не работали для программистов и не работают.
Лично мне она позволила определить области, в которых я хотел бы подтянуть свои навыки. Я не говорю что надо по всем столбцам стремиться к максимуму, но выбрать для себя направления нужные в работе и росте можно. Ну и в собеседованиях помогает при выставлении оценки.
https://www.sijinjoseph.com/programmer-competency-matrix/ - пользовался вот этой.
Дело в том, что начиная с некоторого уровня опыта и знаний, столбцов становится примерно сотни, и никакой возможности ориентироваться в них не остается. Да даже если навыков два — вот скажите, что лучше, 10 баллов за первый и 1 за второй, или два по 5? Нет никакого внятного критерия, что есть хорошо, и когда у вас становится 100 колонок — это не лучше, а только хуже.
Для вашего работодателя это зависит от проекта. Лично для вас - от ваших приоритетов.
Попробую на примере пояснить. У меня был джун который делал отличные компоненты (qt widgets, desktop), но часто тупил при работе с бизнес логикой. Оказалось что человек совершенно не представляет что такое структуры данных. Вот я с ним и пробежался по матрице, определив приоритетные точки роста. Понял что человек хорошо умеет ui, знает синтаксис языка, но проседает в алгоритмизации и ещё некоторых вещах. Старался потом давать ему задачи, которые можно было растянуть по времени и обучаться на них. «Матрица» выступила своего рода списком категорий, без неё оценка навыков программиста превращалась в квест, похожий на сложное и подробное собеседование.
Ну, я не исключаю, что в частном случае кому-то помогает. Особенно для джунов. Но:
Оказалось что человек совершенно не представляет что такое структуры данных.
А вы без матрицы разве это не определили бы? И как она вам помогла? Я исхожу из того, что вы как скажем лид, или просто более опытный, обычно и без всякой матрицы понимаете, скажем в процессе ревью, в каких областях у коллеги слабые места. Зачем вам для этого какая-то формальная матрица?
без неё оценка навыков программиста превращалась в квест, похожий на сложное и подробное собеседование.
Ну я и толкую о том, что навыки программиста это и есть такой обширный набор знаний и опыта из разных областей, что упорядочить его в простое линейное множество навыков на практике зачастую невозможно.
Ещё одно любопытное наблюдение - у сварщиков 6 разрядов и хоть у них довольно сложная профессия, но вариативность навыков намного меньше. У айтишников их всего 3, выводы делайте сами
Для "Мидл инженера", видимо, подразумевалась другая диаграмма. Сейчас у "Мидла" и "Сиеньора" они одинаковые.
Мы сеньором называем именно вот этого вашего финального инженера. А то, что у вас синиор, называем мидл стронг. И как указали выше в комментариях, разрабатывается матрица компетенций, чтобы сделать многомерную оценку навыков.
Опыт и знания можно оценить ситуативными вопросами. Т.е берется случай из опыта, в котором принимались решения и дается кандидату на оценку.
Мое мнение, что вот эта идея, которую пропагандирует Дядька Боб, про абстракцию над инструментами - полная чушь. Да, мы используем абстракции, но для удобства, а не для возможности менять инструменты. Выбор инструментов в разработке ПО - решение компромиссов. Существуют нефункциональные требования, которые противоречат друг другу, нельзя сразу сделать все. Поэтому, существует большое количество инструментов для одной и той же задачи. Каждый инструмент выбрал для себя приоритетом те или иные нефункциональные особенности. И предлставил для них интерфейс. Например база данных может упор делать на целостность или масштабирование. На запись, или на чтение. И так далее со всеми инструментами. И соответсвенно каждый инструмент предоставляет свой интерфейс, которые реализует эти самые уникальные особенности. И это нормально, что нефункциональные требования меняются. На старте проекта нужно экономить, проект может и не взлететь. Проект вырос - может потребоваться переезд на другую систему хранения данных. Это будет сложный процесс, который потребует множественных изменений, но это не значит что первоначальный выбор реляционой БД был неверным.
Это то, о чем вы упоминаете в своей статье, но вот про пункт с абстрагированием я не согласен. Условно говоря, я не хочу использовать более сложный DataMapper вместо привычного ActiveRecord только потому, что потом когда-нибудь что-то изменится. В большинстве случаев это потом никогда не наступит. Да, ActiveRecord имеет массу недостатков, но я все равно всегда буду новый проект начинать именно с ним, просто потому что это быстрее и дешевле. Если это тот самый проект, который получит развитие - он потом сможет оплатить дорогую процедуру переезда. Но, по статистике большинство проектов не взлетают, и я предпочту сэкономить бюджет клиента.
Знания и опыт - это две перпендикулярные оси. Знания - это, грубо говоря, я знаю, как надо делать. А опыт - это я знаю, как не надо.
И то, и другое у растет со временем, потраченным на занятие своей профессиональной деятельностью.
Клёво делать интересные проекты. Автоматизировать, масштабировать. Работать с умными адекватными людьми.
А вот эти все сеньор - не сеньор взялись из желания бизнеса все измерить и подвести под иерархию. Ведь иерархия позволяет обосновать, кому платить больше, кому меньше, кто начальник, а кто дурак.
Не могу согласиться с определением. Знания - это то, что ты изучил, а опыт это применение этих знаний на практике. И опыт может быть как положительный, так и отрицательный.
Ты можешь знать как ходить и выбирать направление движения. Ты можешь пойти в одну сторону и понять, что зря ты сюда шел и вернуться обратно. Ты заработал опыт, что ходить туда это неправильно, но ты всё ещё не знаешь, куда идти.
Короче, опыт это не такая односторонняя вещь, как указано в этом определении.
Вы — не сеньор в программной инженерии