Как понять, что вы уже не junior-разработчик — отвечают эксперты

Молодым специалистам очень важно понимать, что это далеко не самый важный вопрос в их деятельности, а может быть даже вредный. По нашим наблюдениям, у многих начинающих программистов наблюдается склонность к переоценке своего профессионального уровня. После первых успехов в начале карьерного пути часто возникает иллюзия «я всё умею, учиться больше не надо». Практической пользы от того, что человек субъективно чувствует себя middle, а не junior, нет.

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

Рынок труда в области разработки ПО достаточно конкурентен, и компании заинтересованы в карьерном развитии сотрудников.

Junior-разработчик только учится и мало что умеет делать самостоятельно. Middle тоже учится, но уже может решать конкретные задачи, задавая минимум вопросов. Следующий уровень — senior — учится, знает, как решить задачу, и обучает junior-разработчиков.

Когда я начинал изучать разработку, то читал много книг по программированию, статьи на Habrahabr и работал в небольшой веб-студии. Смотрел, как устроены сложные проекты, и старался перенимать лучшие практики. Затем я перешёл в большую компанию и приступил к активному изучению готовых фреймворков: Aurelia, Angular, React. Грань, когда я превратился из junior-разработчика в middle, выглядела так: я перестал писать «велосипеды», начал решать поставленные задачи качественно, в срок и почти самостоятельно.

На обсуждение middle-разработчик выносит только нюансы решения, а не вопросы, как подступиться к задаче. Все Pull Request проходят быстро и с минимальным количеством замечаний. При этом middle довольно точно оценивает рабочее время с учётом возможных форс-мажоров. Он сам может общаться с бизнесом или внутренним заказчиком, чтобы уточнить необходимые детали. И, конечно, middle знает, чего делать точно не стоит. Он понимает, когда надо взять готовую библиотеку, а когда писать код самому.

Хороший способ проверить свой уровень — сходить на собеседование. Это мини-экзамен, после которого можно сильно вырасти в качестве. Разумеется, также можно запросить обратную связь у коллег. Бесплатно и без временных затрат получить объективную оценку знаний и узнать, над чем стоит работать, чтобы выйти на следующий уровень.

По моему глубокому убеждению, звания в IT — субъективщина. Работодатели должны сами проводить переаттестации и по факту повышать зарплаты. Во многих компаниях, где мне приходилось работать, формальной градации по уровню квалификации вовсе не было.

Возвращаясь к вопросу: если вы сами справляетесь с задачами, после вас не нужно исправлять баги и вы понимаете требования бизнеса, то вы определено уже не junior. Также можно попросить коллегу по вашей специализации оценить ваш текущий уровень, и уже по результату делать запрос на повышение зарплаты или же подтягивать свои навыки.

Поскольку я сам ещё junior-разработчик, то поделиться опытом мне не придётся. Но, с другой стороны, я считаю, что взгляд снизу не менее важен. Ну, и так как я ещё junior, то обязан знать, что такое middle, и понимать, к чему стремиться.

Я считаю, что оценивать уровень программиста по количеству лет, которые он потратил, работая в своей области, неправильно. Как минимум потому, что в IT-мире всё быстро устаревает. Думаю, что тяжело назвать middle’ом того программиста, который 5 лет фиксил баги, и при этом ни разу не реализовал новый функционал.

Самостоятельность и уверенность в решении задач

Чаще всего текущие задачи, с которыми я сталкиваюсь, заставляют меня «дёргать» моих старших товарищей, чтобы что-то узнать, уточнить, пояснить. Я понимаю, что тем самым я отнимаю у них часть рабочего времени, да и просто отвлекаю. С одной стороны, мне жутко неудобно тревожить их, но зачастую это единственный источник быстрого решения проблемы.

Из всех этих эпизодов я сделал вывод, что мне часто не хватает компетентности, опыта и знания системы, ну и, как следствие, уверенности в самостоятельном решении задач. Наверное, если бы я мог брать задачи и самостоятельно их закрывать, без отвлечения своих коллег, то это было бы уже первым звоночком, говорящем о моём приближении к грейду middle-разработчик.

Категории задач

Конечно, сейчас любой junior, как и я, с уверенностью скажет: «Я уже решал немало задач самостоятельно!». Да, это здорово, но нужно учитывать и сложность решаемых задач. Исправлять баги, писать юнит-тесты, костыли и жмякать на кнопку автоматической сборки билда может практически любой начинающий программист. Но вот самому реализовать новый функционал, улучшить текущую архитектуру или производительность и делать это с умом, по моему мнению, junior вряд ли сможет. Считаю, что это веское основание задуматься о повышении своего грейда до middle.

Проектирование

Когда мне впервые дали написать код на боевом проекте, то я почему-то решил, что чем больше я напишу, тем будет круче. Я написал рабочую библиотеку, которая генерирует документы в PDF из заготовленных шаблонов и приходящих JSON’ов. Со временем понадобилось добавить ещё несколько шаблонов для новых документов. И с добавлением каждого шаблона я начал понимать, насколько громоздким, нечитабельным и неподдерживаемым становится код.

Если бы я изначально продумал архитектуру этой «маленькой» библиотеки так, чтобы не пришлось рефакторить код, то это был бы ещё один поинт в сторону middle-разработчика.

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

Если всё же не ясно:

1. Найдите в компании старшего разработчика, который использует тот же стек, что и вы, и попросите его оценить ваш уровень.
2. Также можете просить коллег проводить ревью вашего кода.
3. Узнайте, над чем ещё вам предстоит работать, чтобы дотянуть до middle.

Основные отличия между junior и middle-разработчиком заключаются в уровне самостоятельности при решении задач и качестве их выполнения.

При постановке задачи с junior-разработчиком необходимо максимально конкретно обсудить пути решения и используемые технологии. Кроме того, код junior-разработчика нуждается в постоянном ревью более компетентных коллег. И в противоположность этому, middle-разработчики способны самостоятельно брать на себя задачи более высокого уровня.

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

Как понять, что ваша мышца уже достаточно выросла, и вы можете жать не 50, а 100 кг? Да не бывает так. Если всегда жали 50, то 100 не выжмете. Сначала надо перейти на 55, 60 кг и т. п. Так же и между junior и middle нет никакого квантового скачка. Это шкала постепенного развития. Поэтому более сложные задачи нужно брать всегда: как только в текущих всё понятно и всё получается — обязательно нужно постараться найти что-то, содержащее долю новой нагрузки, новых знаний и умений. То есть прибавить 5 кг. Если не будете прибавлять — так и будете всю жизнь жать 50. Но и накинув сразу 50 кг — точно не справитесь и заработаете проблемы со здоровьем. Ну а зарплата должна следовать за уровнем задач. Если даже вы не получили нового формального звания, но делаете больше и лучше, чем раньше (жмёте не 100, но уже хотя бы 70) — вполне можно ожидать роста компенсаций пропорционально своему вкладу.

Если говорить просто, то junior — это уровень, на котором много вопросов и мало ответов. Как правило, на этом уровне разработчик почти всё делает посредством взаимодействия с командой или с куратором. Не вылезает из книжек, и почти весь его код — это чьи-то примеры с Stack Overflow или Github. На этом уровне приходится контролировать все этапы разработки. Но основное время уходит на то, чтобы подробно описать задачу в самом начале: что и как делать.

Middle — это уровень зрелости, когда много вопросов закрыто. Разработчик почти самостоятельно способен решить задачу, ему не нужно в подробностях объяснять, что и как делать, но без общих объяснений у него редко получается выполнить всё правильно.

На уровне Senior есть четкое понимание всех методов и инструментов. Этому разработчику достаточно краткого описания задачи, всё остальное он сможет выполнить самостоятельно. Уровень компетенции такого специалиста позволяет полностью полагаться на его решения без дополнительного контроля, результат работы прогнозируемый и ожидаемый. На этом уровне разработчик способен видеть проект в разрезе, что даёт ему возможность правильно выбирать архитектурные решения.

Как говорил булгаковский Мастер: «Никогда и ничего не просите! Никогда и ничего, и в особенности у тех, кто сильнее вас. Сами предложат и сами всё дадут!».

Молодые разработчики и не должны сами оценивать свой уровень, просить задачи и деньги — против них работает эффект Даннинга-Крюгера. Оценка — дело их руководителей, разработчик же, пока он ощущает себя именно разработчиком, а не вершителем чужих судеб, живёт по принципу «делай, что должен, и будь, что будет». Если же юный программист чувствует в себе бурление амбиций, то и говорить надо об этом.

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

Ну, а если руководство совсем не блещет и вопросы о квалификации рассматривает как бунт, то лучше поискать себе другое руководство. Если, конечно, чувствуете, что готовы и можете себя продать как специалиста.

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

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

Во-вторых, вы способны решать более сложные задачи без посторонней помощи. Обычно junior-разработчику для решения любой задачи требуется консультироваться с более опытными коллегами. Разработчик уровня middle большую часть задач способен делать самостоятельно.

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

Junior — специалист, который владеет всеми основными технологиями в своем стеке, он умеет очень много (тот, кто почти ничего не умеет — не junior, а студент на раннем этапе). В силу того, что у junior мало опыта, он может допускать ошибки архитектурного плана, применять не подходящие в данном кейсе решения. Junior’ов необходимо контролировать, помогать им, зачастую добиваться, чтобы они сами обращались за помощью, когда необходимо (а не сидели над одним вопросом 2 дня, ничего не понимая). Нужно кураторство над ними в широком понимании.

Middle-разработчик — это уже специалист, который успешно работает на своём первом проекте минимум полгода, выбирает нетривиальные задачи по силам, код на ревью выставляет сам, без промежуточного контроля. Middle-разработчику можно доверить обучение студента или кураторство над junior.

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

Во-первых, это уровень владения профессией. Есть три ступени мастерства:

1. Человек осваивает инструмент. На этом этапе ему необходим наставник, который подскажет, как надо делать.
2. Человек знает, как выполнить поставленную перед ним задачу. Он самостоятельно работает, двигаясь в согласованном направлении.
3. Человек владеет инструментарием и может научить другого.

Разработчик, который дорос до уровня middle, редко обращается с вопросом «как сделать?», самостоятельно ищет способы решения задачи и не применяет первый найденный в интернете. Он обсуждает с коллегами несколько вариантов реализации и понимает слабые стороны каждого из них.

Во-вторых, это подход к рассмотрению самой задачи. Уровень языков программирования — это очень важно. Но не менее важно переориентировать своё мышление на понимание проблемы, которую необходимо решить в рамках задачи. Именно это обеспечивает рост в категорию middle и выше. Другими словами, получая задачу, надо ответить себе на пять вопросов в правильном порядке:

1. Зачем это надо делать?
2. Можно ли сделать потом?
3. Почему не сделали раньше?
4. Что надо сделать?
5. Как это сделать?

Молодой специалист практически всегда думает только о способе решения задачи («Как это сделать?»), оставляя предыдущие 4 пункта без внимания. В том числе потому, что для разработчика уровня junior, а зачастую и middle, вопросы приоритизации («Можно ли сделать потом?» и «Почему не сделали раньше?») являются данностью. Но понимание причин и приоритетности задачи позволяют правильно выстроить свою работу, предложить оптимальное решение и, в итоге, развиваться в своей профессиональной области.

Можно выделить несколько критериев уровня профессионализма разработчика. Но насколько вы круты по каждому из них, чтобы быть не junior’ом, решать вам.

1. Самостоятельность: другие сотрудники не тратят время на обучение вас технологиям, как внутренним, так и внешним.
2. Качество вашего кода: стоит его оценивать относительно уровня стандартов кодирования в компании.
3. Производительность труда: как с точки зрения скорости решения проблем, так с точки зрения скорости разработки нового функционала. Однако стоит учесть, что скорость разработки может сильно влиять на качество кода, причём не в лучшую сторону.
4. Вклад в кодовую базу продукта: насколько сложные и важные задачи решает ваш код.

В любой сфере опыт работы рассматривается как определяющий критерий для оценки специалиста. Не является исключением и программирование, где принята «волшебная» временная граница в два года — именно людей с таким опытом принято рассматривать как middle-разработчиков, в то время как senior’ами становятся программисты со стажем от 10 лет.

Это логично: информационные технологии многогранны и требуют непосредственного вовлечения для их освоения, поэтому только поработав на нескольких проектах и сменив несколько стеков (способов организации данных) можно развить необходимую эрудицию в этой области, достаточную для принятия правильных решений там, где предоставляется выбор.

Границы опыта в 2 и 10 лет вписываются в знаменитое правило Парето о том, что 20 % усилий дают 80 % результата. Программиста, сделавшего эти 20% усилий, можно назвать middle-разработчиком. И правилу 10 000 часов для достижения мастерства в любой области (а это примерно и есть 10-летний срок) эти границы тоже соответствуют.

В то же время, такой критерий как опыт иногда неоднозначен: разработка ПО очень разнообразна по своей природе — можно делать одно и то же многие годы и не развиваться. А можно приобрести огромный багаж знаний и опыта, решив несколько интересных и сложных задач в сравнительно короткое время в интенсивном режиме.

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

Нужно искать фидбек на свой код от более опытных специалистов (вот почему в успешных компаниях стараются развить институт наставничества и много усилий уделяют подбору команд). По комментариям экспертов обычно можно наглядно увидеть свой прогресс — замечаний становится меньше, они перестают повторяться. Код требует более глубокого вовлечения от эксперта, а сами комментарии несут свежую информацию, заставляют изучать новое.

Уровень ответственности на этапе перехода из junior в middle обычно сводится к большему объему самостоятельной работы и меньшей вовлечённости старших программистов. Сложность задач также должна увеличиваться. Если они однообразны и перестали требовать значительных усилий — это тревожный звонок.

Чем больше программист введёт метрик, чем чаще и тщательнее он их отслеживает, чем больше фидбека стремится получить, тем более объективным критерием становится показатель его опыта работы. Для самостоятельной проверки полезно воспользоваться самым прямолинейным способом — рыночным. Одним из вариантов является прохождение интервью на роль middle-разработчика на интересующих проектах. Если интервью успешно пройдено, то это первый сигнал к тому, что вы уже middle-разработчик.

Я вижу три возможные точки зрения: общепринятая, философско-справедливая и как на самом деле.

1. Принятая, общая и неточная оценка — по времени работы. Считается, что якобы за пару лет достаточный опыт придёт сам, но это не всегда так. Если разработчик спокойно сидел на одном месте, не торопясь делал простые задачи и не интересовался ничем вокруг, то вряд ли он стал на ступеньку выше.

2. Мне кажется, что справедливо считать человека middle-разработчиком, когда он:

• самостоятельно решает поставленные задачи;
• за ним не надо «приглядывать»;
• сам не только хочет, но и может решать более сложные задачи за вменяемый срок;
• готов брать на себя ответственность за какую-то часть разработки;
• имеет широкий кругозор. Это значит, что он не просто решает задачи в контексте кода одного проекта, но и знает, как и зачем он взаимодействует с другими сервисами, как поддерживает код, логирует события и мониторит в случае отказа, как разворачивается на сервера.

Если он всё это знает, хоть, возможно, это и не его прямая обязанность, он может называть себя middle-разработчиком и просить повышения.

3. В реальности же всё зависит от того, как разработчик продал себя при трудоустройстве. Если искали middle-разработчика, вы прошли отбор и прошли испытательный срок, будьте вы даже ещё студентом, то вы middle. Все оценки относительны, в каждой компании всё по-своему, требования и ожидания от сотрудников разной градации различаются. Опыт можно нарисовать, но всех действительно волнуют твои способности выполнять поставленную работу.