По каким признакам молодой специалист может понять, что уровень его квалификации вырос до уровня middle. Ответы экспертов на Tproger.
Часто молодые специалисты не чувствуют момент, когда уровень их квалификации вырос и можно брать более сложные задачи и просить увеличения зарплаты. По каким признакам это понять? Спрашиваем у экспертов.
Краткие выводы в конце статьи.
Герман Шеремет, директор по развитию комплекса ГК «Системные Технологии»:
Во-первых, это уровень владения профессией. Есть три ступени мастерства:
Разработчик, который дорос до уровня middle, редко обращается с вопросом «как сделать?», самостоятельно ищет способы решения задачи и не применяет первый найденный в интернете. Он обсуждает с коллегами несколько вариантов реализации и понимает слабые стороны каждого из них.
Во-вторых, это подход к рассмотрению самой задачи. Уровень языков программирования — это очень важно. Но не менее важно переориентировать своё мышление на понимание проблемы, которую необходимо решить в рамках задачи. Именно это обеспечивает рост в категорию middle и выше. Другими словами, получая задачу, надо ответить себе на пять вопросов в правильном порядке:
Молодой специалист практически всегда думает только о способе решения задачи («Как это сделать?»), оставляя предыдущие 4 пункта без внимания. В том числе потому, что для разработчика уровня junior, а зачастую и middle, вопросы приоритизации («Можно ли сделать потом?» и «Почему не сделали раньше?») являются данностью. Но понимание причин и приоритетности задачи позволяют правильно выстроить свою работу, предложить оптимальное решение и, в итоге, развиваться в своей профессиональной области.
Михаил Егоров, заместитель генерального директора по стратегическому развитию компании «Ай-Ди — Технологии управления»:
Молодым специалистам очень важно понимать, что это далеко не самый важный вопрос в их деятельности, а может быть даже вредный. По нашим наблюдениям, у многих начинающих программистов наблюдается склонность к переоценке своего профессионального уровня. После первых успехов в начале карьерного пути часто возникает иллюзия «я всё умею, учиться больше не надо». Практической пользы от того, что человек субъективно чувствует себя middle, а не junior, нет.
Стремиться следует к более глобальным целям, например стать архитектором, где возможностей для профессиональной реализации гораздо больше. Соответственно, существенно выше и оплата. Оптимальный путь для этого — попасть в компанию, которая поможет вам вырасти за счёт компетентного руководства, интересных проектов и коллег-профессионалов. Важно понимать, что при должном отношении к делу продвижение специалиста искусственно сдерживаться не будет. Если становится очевидно, что человек вырос, его неизбежно повысят.
Рынок труда в области разработки ПО достаточно конкурентен, и компании заинтересованы в карьерном развитии сотрудников.
Антон Пальгунов, Senior Frontend Developer в компании Revolut:
Junior-разработчик только учится и мало что умеет делать самостоятельно. Middle тоже учится, но уже может решать конкретные задачи, задавая минимум вопросов. Следующий уровень — senior — учится, знает, как решить задачу, и обучает junior-разработчиков.
Когда я начинал изучать разработку, то читал много книг по программированию, статьи на Habrahabr и работал в небольшой веб-студии. Смотрел, как устроены сложные проекты, и старался перенимать лучшие практики. Затем я перешёл в большую компанию и приступил к активному изучению готовых фреймворков: Aurelia, Angular, React. Грань, когда я превратился из junior-разработчика в middle, выглядела так: я перестал писать «велосипеды», начал решать поставленные задачи качественно, в срок и почти самостоятельно.
На обсуждение middle-разработчик выносит только нюансы решения, а не вопросы, как подступиться к задаче. Все Pull Request проходят быстро и с минимальным количеством замечаний. При этом middle довольно точно оценивает рабочее время с учётом возможных форс-мажоров. Он сам может общаться с бизнесом или внутренним заказчиком, чтобы уточнить необходимые детали. И, конечно, middle знает, чего делать точно не стоит. Он понимает, когда надо взять готовую библиотеку, а когда писать код самому.
Хороший способ проверить свой уровень — сходить на собеседование. Это мини-экзамен, после которого можно сильно вырасти в качестве. Разумеется, также можно запросить обратную связь у коллег. Бесплатно и без временных затрат получить объективную оценку знаний и узнать, над чем стоит работать, чтобы выйти на следующий уровень.
Евгений Ефремов, Software Engineer в MobiDevices:
По моему глубокому убеждению, звания в IT — субъективщина. Работодатели должны сами проводить переаттестации и по факту повышать зарплаты. Во многих компаниях, где мне приходилось работать, формальной градации по уровню квалификации вовсе не было.
Возвращаясь к вопросу: если вы сами справляетесь с задачами, после вас не нужно исправлять баги и вы понимаете требования бизнеса, то вы определено уже не junior. Также можно попросить коллегу по вашей специализации оценить ваш текущий уровень, и уже по результату делать запрос на повышение зарплаты или же подтягивать свои навыки.
Данил Юсупов, инженер-программист 3 категории в компании ICL Services:
Поскольку я сам ещё junior-разработчик, то поделиться опытом мне не придётся. Но, с другой стороны, я считаю, что взгляд снизу не менее важен. Ну, и так как я ещё junior, то обязан знать, что такое middle, и понимать, к чему стремиться.
Я считаю, что оценивать уровень программиста по количеству лет, которые он потратил, работая в своей области, неправильно. Как минимум потому, что в IT-мире всё быстро устаревает. Думаю, что тяжело назвать middle’ом того программиста, который 5 лет фиксил баги, и при этом ни разу не реализовал новый функционал.
Самостоятельность и уверенность в решении задач
Чаще всего текущие задачи, с которыми я сталкиваюсь, заставляют меня «дёргать» моих старших товарищей, чтобы что-то узнать, уточнить, пояснить. Я понимаю, что тем самым я отнимаю у них часть рабочего времени, да и просто отвлекаю. С одной стороны, мне жутко неудобно тревожить их, но зачастую это единственный источник быстрого решения проблемы.
Из всех этих эпизодов я сделал вывод, что мне часто не хватает компетентности, опыта и знания системы, ну и, как следствие, уверенности в самостоятельном решении задач. Наверное, если бы я мог брать задачи и самостоятельно их закрывать, без отвлечения своих коллег, то это было бы уже первым звоночком, говорящем о моём приближении к грейду middle-разработчик.
Категории задач
Конечно, сейчас любой junior, как и я, с уверенностью скажет: «Я уже решал немало задач самостоятельно!». Да, это здорово, но нужно учитывать и сложность решаемых задач. Исправлять баги, писать юнит-тесты, костыли и жмякать на кнопку автоматической сборки билда может практически любой начинающий программист. Но вот самому реализовать новый функционал, улучшить текущую архитектуру или производительность и делать это с умом, по моему мнению, junior вряд ли сможет. Считаю, что это веское основание задуматься о повышении своего грейда до middle.
Проектирование
Когда мне впервые дали написать код на боевом проекте, то я почему-то решил, что чем больше я напишу, тем будет круче. Я написал рабочую библиотеку, которая генерирует документы в PDF из заготовленных шаблонов и приходящих JSON’ов. Со временем понадобилось добавить ещё несколько шаблонов для новых документов. И с добавлением каждого шаблона я начал понимать, насколько громоздким, нечитабельным и неподдерживаемым становится код.
Если бы я изначально продумал архитектуру этой «маленькой» библиотеки так, чтобы не пришлось рефакторить код, то это был бы ещё один поинт в сторону middle-разработчика.
Middle-разработчик не станет лепить новый код класс за классом, а скорее всего начнёт с интерфейсов и будет стараться применять паттерны проектирования там, где они уместны. Кстати, вот хороший сайт с каталогом паттернов.
Если всё же не ясно:
Александр Солодченко, преподаватель школы IT и безопасности HackerU
Основные отличия между junior и middle-разработчиком заключаются в уровне самостоятельности при решении задач и качестве их выполнения.
При постановке задачи с junior-разработчиком необходимо максимально конкретно обсудить пути решения и используемые технологии. Кроме того, код junior-разработчика нуждается в постоянном ревью более компетентных коллег. И в противоположность этому, middle-разработчики способны самостоятельно брать на себя задачи более высокого уровня.
Если вы чувствуете, что всё чаще и чаще вместо того, чтобы полностью проговаривать способ решения задачи, просто берёте и делаете её, а старшие коллеги не вмешиваются в процесс вашей работы, и при дальнейших код-ревью критики вашего кода стало гораздо меньше — можно смело сказать, что вы middle-разработчик.
Тимур Нозадзе, руководитель отдела разработки REG.RU:
Как понять, что ваша мышца уже достаточно выросла, и вы можете жать не 50, а 100 кг? Да не бывает так. Если всегда жали 50, то 100 не выжмете. Сначала надо перейти на 55, 60 кг и т. п. Так же и между junior и middle нет никакого квантового скачка. Это шкала постепенного развития. Поэтому более сложные задачи нужно брать всегда: как только в текущих всё понятно и всё получается — обязательно нужно постараться найти что-то, содержащее долю новой нагрузки, новых знаний и умений. То есть прибавить 5 кг. Если не будете прибавлять — так и будете всю жизнь жать 50. Но и накинув сразу 50 кг — точно не справитесь и заработаете проблемы со здоровьем. Ну а зарплата должна следовать за уровнем задач. Если даже вы не получили нового формального звания, но делаете больше и лучше, чем раньше (жмёте не 100, но уже хотя бы 70) — вполне можно ожидать роста компенсаций пропорционально своему вкладу.
Роман Голофаев, ведущий iOS-разработчик «Райффайзенбанка»:
Если говорить просто, то junior — это уровень, на котором много вопросов и мало ответов. Как правило, на этом уровне разработчик почти всё делает посредством взаимодействия с командой или с куратором. Не вылезает из книжек, и почти весь его код — это чьи-то примеры с Stack Overflow или Github. На этом уровне приходится контролировать все этапы разработки. Но основное время уходит на то, чтобы подробно описать задачу в самом начале: что и как делать.
Middle — это уровень зрелости, когда много вопросов закрыто. Разработчик почти самостоятельно способен решить задачу, ему не нужно в подробностях объяснять, что и как делать, но без общих объяснений у него редко получается выполнить всё правильно.
На уровне Senior есть четкое понимание всех методов и инструментов. Этому разработчику достаточно краткого описания задачи, всё остальное он сможет выполнить самостоятельно. Уровень компетенции такого специалиста позволяет полностью полагаться на его решения без дополнительного контроля, результат работы прогнозируемый и ожидаемый. На этом уровне разработчик способен видеть проект в разрезе, что даёт ему возможность правильно выбирать архитектурные решения.
Дмитрий Казаков, руководитель отдела веб-разработки RU-CENTER:
Как говорил булгаковский Мастер: «Никогда и ничего не просите! Никогда и ничего, и в особенности у тех, кто сильнее вас. Сами предложат и сами всё дадут!».
Молодые разработчики и не должны сами оценивать свой уровень, просить задачи и деньги — против них работает эффект Даннинга-Крюгера. Оценка — дело их руководителей, разработчик же, пока он ощущает себя именно разработчиком, а не вершителем чужих судеб, живёт по принципу «делай, что должен, и будь, что будет». Если же юный программист чувствует в себе бурление амбиций, то и говорить надо об этом.
В идеальном мире, конечно же, руководитель сам оценит разработчика, без всякого стимула с его стороны, и сам же предложит ему варианты. Понятно, что мы живём не в идеальном мире и менеджмент обычно не совсем идеальный, но и тут лучше спрашивать обратную связь, а не предлагать повысить себе грейд. И делать выводы, разумеется. Если вы подозреваете, что говорите с нормальным человеком, который не будет вас вводить в заблуждение, то надо прислушаться.
Ну, а если руководство совсем не блещет и вопросы о квалификации рассматривает как бунт, то лучше поискать себе другое руководство. Если, конечно, чувствуете, что готовы и можете себя продать как специалиста.
Кирилл Васин, ведущий инженер-программист компании Bell Integrator:
Отличия между junior и middle-разработчиками так или иначе сводятся к их производительности. В разных организациях понятия об уровне разработчиков могут отличаться, но в среднем можно судить по таким признакам.
Во-первых, вы уже знаете, как решать типовые несложные задачи в вашем проекте, а также как не допускать типичные ошибки, которые потом могут вылиться в баги и время, затраченное кем-то на их исправление.
Во-вторых, вы способны решать более сложные задачи без посторонней помощи. Обычно junior-разработчику для решения любой задачи требуется консультироваться с более опытными коллегами. Разработчик уровня middle большую часть задач способен делать самостоятельно.
В-третьих, вы умеете писать читаемый код, понятный другим людям. Junior-разработчики часто об этом не задумываются, стараясь как можно быстрей решить задачу. Если код будет плохо читаемым, то при исправлении ошибок или доработках кому-то придётся тратить лишнее время.
Junior — специалист, который владеет всеми основными технологиями в своем стеке, он умеет очень много (тот, кто почти ничего не умеет — не junior, а студент на раннем этапе). В силу того, что у junior мало опыта, он может допускать ошибки архитектурного плана, применять не подходящие в данном кейсе решения. Junior’ов необходимо контролировать, помогать им, зачастую добиваться, чтобы они сами обращались за помощью, когда необходимо (а не сидели над одним вопросом 2 дня, ничего не понимая). Нужно кураторство над ними в широком понимании.
Middle-разработчик — это уже специалист, который успешно работает на своём первом проекте минимум полгода, выбирает нетривиальные задачи по силам, код на ревью выставляет сам, без промежуточного контроля. Middle-разработчику можно доверить обучение студента или кураторство над junior.
В целом для повышения уровня квалификации необходимо постоянно изучать проект и стек технологий, с которым вы работаете. В тот момент, когда вы перестанете думать: «как это сделать?» — и начнёте думать: «как это сделать лучше?» — вот тогда вы уже middle-разработчик.
Олег Граждан, разработчик в Voximplant:
Можно выделить несколько критериев уровня профессионализма разработчика. Но насколько вы круты по каждому из них, чтобы быть не junior’ом, решать вам.
Виталий Чижков, руководитель группы разработки проектов Тверского технологического центра Accenture:
В любой сфере опыт работы рассматривается как определяющий критерий для оценки специалиста. Не является исключением и программирование, где принята «волшебная» временная граница в два года — именно людей с таким опытом принято рассматривать как middle-разработчиков, в то время как senior’ами становятся программисты со стажем от 10 лет.
Это логично: информационные технологии многогранны и требуют непосредственного вовлечения для их освоения, поэтому только поработав на нескольких проектах и сменив несколько стеков (способов организации данных) можно развить необходимую эрудицию в этой области, достаточную для принятия правильных решений там, где предоставляется выбор.
Границы опыта в 2 и 10 лет вписываются в знаменитое правило Парето о том, что 20 % усилий дают 80 % результата. Программиста, сделавшего эти 20% усилий, можно назвать middle-разработчиком. И правилу 10 000 часов для достижения мастерства в любой области (а это примерно и есть
В то же время, такой критерий как опыт иногда неоднозначен: разработка ПО очень разнообразна по своей природе — можно делать одно и то же многие годы и не развиваться. А можно приобрести огромный багаж знаний и опыта, решив несколько интересных и сложных задач в сравнительно короткое время в интенсивном режиме.
Объективными критериями являются качество кода и уровень ответственности. Задача любого разработчика, который хочет развиваться — ввести в обиход и уметь отслеживать метрики для оценки этих критериев. Нужно внимательно следить за сделанными ошибками и убеждаться, что они не повторяются.
Нужно искать фидбек на свой код от более опытных специалистов (вот почему в успешных компаниях стараются развить институт наставничества и много усилий уделяют подбору команд). По комментариям экспертов обычно можно наглядно увидеть свой прогресс — замечаний становится меньше, они перестают повторяться. Код требует более глубокого вовлечения от эксперта, а сами комментарии несут свежую информацию, заставляют изучать новое.
Уровень ответственности на этапе перехода из junior в middle обычно сводится к большему объему самостоятельной работы и меньшей вовлечённости старших программистов. Сложность задач также должна увеличиваться. Если они однообразны и перестали требовать значительных усилий — это тревожный звонок.
Чем больше программист введёт метрик, чем чаще и тщательнее он их отслеживает, чем больше фидбека стремится получить, тем более объективным критерием становится показатель его опыта работы. Для самостоятельной проверки полезно воспользоваться самым прямолинейным способом — рыночным. Одним из вариантов является прохождение интервью на роль middle-разработчика на интересующих проектах. Если интервью успешно пройдено, то это первый сигнал к тому, что вы уже middle-разработчик.
Сергей Толмачёв, Lead Scala Developer и куратор курса Scala Basic в Binary District:
Я вижу три возможные точки зрения: общепринятая, философско-справедливая и как на самом деле.
Если он всё это знает, хоть, возможно, это и не его прямая обязанность, он может называть себя middle-разработчиком и просить повышения.
Переход из junior в middle — это не конкретная точка, а процесс постоянного развития.
Вот примерные характеристики, по которым можно понять, что вы уже «подросли»:
Вообще, стремиться стоит не к новому «званию», а к собственному развитию в качестве разработчика. А до middle/senior-специалистов пускай вас повышают сами работодатели.
