Junior и Senior: в чём разница?

2013-11-08

Я годами пытался понять, что отличает Senior-специалиста от Junior-специалиста. 10 лет опыта работы с Java или .NET? Докторская степень в информационных технологиях? Количество законченных проектов?

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

А потом до меня дошло. Я участвовал в конференции IDDDTour в Бельгии, где обсуждались вопросы проблемно-ориентированного программирования. Знаете, что меня удивило? Помещение почему-то не было наполнено молодыми специалистами, которые впитывали мудрость опытных разработчиков.

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

Вот такой подход и определяет настоящего сениора.

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

Старший разработчик в сотни раз эффективней самого профессионального джуниора, если оценивать продуктивность на бизнес-уровне.

Всё-таки «джуниор» звучит достаточно… ммм… снисходительно. Джуниорство не имеет ничего общего с возрастом, только с уровнем навыков.

Вспомним о модели Дрейфуса

(пятиступенчатая модель умственной деятельности, задействованной в приобретении навыков)

Немного предыстории для тех, кто не в курсе.

В начале 1980-х гг. два учёных брата, Хьюберт и Стюарт Дрейфус, выступили с докладом в научно-исследовательском центре воздушных сил США, посвящённому подготовке пилотов. Изначально братья изучали проблемы искусственного интеллекта, а потом перешли к исследованию процесса познания как такового. Так появилась модель приобретения навыков, названная их именем. Эта модель существенно отличается от многих подобных построенных матриц компетентности. Во-первых, тем, что она была успешно применена на практике в сфере здравоохранения при интенсивном обучении медсестёр. Во-вторых, тем, что эта модель описывает не только сами стадии развития навыков, но и обратную реакцию человека.

Вот эта модель:

Как это работает в реальной жизни?

Недавно один мой друг тренировал команду из 15 .NET программистов, работавших в международной немецкой компании. Для решения простых задач команда была разбита на мини-группы. В качестве разогревающего задания им нужно было решить следующую несложную задачу:

Разбить текст на предложения и выделить все предложения, содержащие в себе определённые слова.

Эффективность разных мини-групп различалась в десятки раз.

Самая быстрая команда нашла решение за 30 секунд:

return
source.Split(‘.’, ‘!’, ‘?’)
.Select(_ => _.Trim())
.Where(_ => searchFor.All(_.Contains));

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

Все эти 15 программистов были высокооплачиваемыми, но спектр их навыков варьировался от уровня новичка до специалиста.

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

Бельгийский разработчик и основатель своего дела Том Янссенс пишет об уровнях приобретённых навыков так:

«Спросите разработчика, как бы он справился, например, с такой задачей: вам нужен вебсайт с возможностью загрузки файлов из локальной сети, поэтому вам нужно создать встроенный в браузер проводник для обзора файлов сети. Как справятся с этим программисты разного уровня?

1. Новичок. Спросит, как должен выглядеть проводник и начнёт рассказывать о реализации.
2. Продолжающий. Спросит, как должен выглядеть проводник и начнёт рассказывать о том, как это реализовать с помощью ajax и прочих штучек.
3. Специалист. Затронет вопросы безопасности браузера и проблемы сетевых драйверов.
4. Профессионал. Спросит, зачем вам нужна эта функциональность, реализованная именно таким образом.
5. Эксперт. Поставит под сомнение принятое решение и потребует использовать кнопку загрузки как наиболее оптимальный вариант в данной ситуации».

Здесь явно виден не линейный рост продуктивности, а экспоненциальный.

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

Настоящая деловая ценность ПО состоит в его конкурентных преимуществах и удобстве для пользователя. Для того, чтобы сделать продукт таким, нужно переосмысление его возможностей и навыки коммуникации, которые позволят вербализовать концепцию и необходимые для реализации ресурсы.

Как и в любой другой сфере, настоящий эксперт работает инстинктивно. Если вы его спросите, как именно он сделал то или иное, он не сможет быстро ответить на этот вопрос. Точно так же, как вы не задумываетесь о том, какие движения вы производите при ходьбе.

Миру нужны разработчики, которые стремятся к простоте.

Миру нужны разработчики, которым для решения проблемы нужны не месяцы, а минуты.

Что в итоге?

Старший разработчик сосредоточен на деловой ценности продукта и не усложняет процессы. Он развивает бизнес-процессы таким образом, чтобы они работали и без его участия.

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

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

Перевод: Люся Ширшова. По материалам блога Marco Heimeshoff.