Junior vs Senior разработчик: в чем, в конце концов, разница между ними?
Кажется, что есть резкий контраст между этими уровнями. Но на самом деле, какое различие между Junior и Senior разработчиком?
Что еще более важно, как с обеих сторон можно оценить рост разработчика в более высшую лигу? Чтобы разобраться в этом вопросе, продолжайте читать статью.
Этот вопрос может показаться глупым и очевидным, но какой же ответ на самом деле?
Я слышал, как некоторые разработчики в моей компании обсуждали этот вопрос. Один из моих Senior разработчиков вовлек двоих Junior из своей команды в какую-то тему, несвязанную с этим. И один из Junior разработчиков, в конце концов, не выдержал и спросил, в чем же разница между Junior и Senior, и предыдущая обсуждаемая тема резко оборвалась.
Senior разработчик, один из самых лучших и ярких кодеров, с которыми я когда-либо имел удовольствие работать, потратил следующие 30 минут пытаясь изложить свое мнение по поводу этих отличий.
По мере того, как разговор наполнялся обычными ответами, Junior разработчик, который первым поднял этот вопрос (еще одна яркая личность в моей компании) предпринял попытку углубиться и разбил вопрос на два полезных под вопроса:
1. Каким объективным образом я, Junior разработчик, могу определить тот момент, когда я трансформировался в «Senior»?
2. Как вы, как Senior разработчик, оцениваете прогресс Junior и знаете, когда этот Junior поднялся на уровень Senior разработчика?
Вопрос 1
Я нашел первый вопрос чрезвычайно интересным. По мере того, как разворачивалось обсуждение в углу офиса, я пытался вспомнить то время, когда я только вступил в мир разработки программного обеспечения и то, как я рос в качестве разработчика на протяжении долгих лет.
Конечно, время является важным фактором, который каждый разработчик рассматривает как часть его/ее перехода на более высокий уровень мастерства. Сопоставив эти годы с различными объявлениями о работе (некоторые считают, что «Senior» должен иметь, по крайней мере, 5-7 лет «ценного опыта», тогда как другие считают, что этот срок должен составлять как минимум 10-15 лет), быстро становится очевидным, что нет никакого реального «стандарта» с точки зрения того, насколько профессионально было потрачено это время.
Побывав на позиции человека, принимающего на работу, я также могу подтвердить тот факт, что некоторые разработчики считают себя Senior после того, как отработали всего несколько лет, в то время как другие считают себя «Middle» после 7-10 лет работы. И это не говоря уже о фактических, продемонстрированных знаниях. Это довольно забавная вещь. Ведь это «сопротивление несоответствия» может вызывать трения, когда высказываются разные мнения о «времени службы».
Что можно сказать о количестве технологий или освоении языка? Есть мнение, что освоение только одного или двух языков для Senior разработчика, когда он/она имеет опыт и знание, помогает решать проблемы, представленные на этом языке/технологии. Знания множества языков/технологий не позволяют сконцентрироваться.
Тем не менее, на другом месте ставят в приоритет более высокую способность работать с многими подобными технологиями и способность решать более обобщенные проблемы с технологиями.
И снова это очевидно: все зависит от того, что от вас требуется на работе. В этом отношении мало помощи от внутреннего ощущения, которое подскажет, готовы ли вы рискнуть перейти в высшую категорию.
После моих долгих размышлений и обсуждений в офисе, я понял, что внутренняя мера для первого вопроса довольна личная. Если бы я ставил условия при выборе шкалы оценки (что неформально я могу сделать), то я бы выбрал уровень вашего комфорта и уверенности, как Junior разработчика, когда Senior член вашей команды/компании попросит вас сделать что-то новое.
Вопрос 2
Есть бесчисленное множество критериев, которые, несомненно, способны ответить на этот вопрос. Честно говоря, я до сих пор хочу увидеть любые из них, которые могут послужить в качестве либо серебряной пули, либо золотой линейки, с помощью которой можно окончательно измерить параметры Senior разработчика.
Да, конечно, есть тесты и экзамены, которые могут быть написаны, чтобы помочь оценить уровень мастерства разработчика. Без сомнений, эти тесты нельзя игнорировать.
Чтобы сделать этот момент еще интереснее, некоторые люди определяют значение «Senior разработчика» не как того, кто обязательно хорошо знаком с технологиями или запрашиваемым языком. Например, в небольшом магазине вице-президент по технологии может быть мастером и Java-разработчиком с большим опытом создания корпоративных приложений на базе IOS. При отсутствии других Senior IOS-разработчиков, кто-то должен взять бразды правления в свои руки.
Тем не мене, я немного отвлекся. Реальный вопрос здесь – оценка прогресса Junior разработчиков, которыми вы управляете.
При наличии нескольких критериев, многое казалось сложным для понимания Junior персонала. Опять же, если попросили бы опубликовать одну конкретную метрику (шкалу оценок), то мне пришлось бы идти вдоль линии способности разработчика генерировать оценку для задачи или серии задач (все равно много) и чтобы эти задачи выполнялись в пределах разумного запаса затраченного времени и с минимум помощи.
Короче, если вы повторяете те ошибки, которые делали вначале, то вы, безусловно, не двигаетесь в сторону Senior разработчика.
Вывод
Эта статья не претендует на то, чтобы ответить на вопросы, поднятые моим проницательным Junior разработчиком. Скорее всего, она служит началом дискуссии о том, какие показатели можно применить к каждому из вопросов. Это и будет отправной точкой.
Как вы думаете? Какими должны быть показатели, чтобы подать заявление? Не все мы можем пользоваться роскошью полноценного отдела кадров, но возможно мы все-таки сможем кое-что узнать.
Оставьте комментарий и давайте начнем беседу.