Хотите дальше читать devby? 📝
Support us

Почему программистов не нужно оценивать по «годам опыта»

Оставить комментарий
Почему программистов не нужно оценивать по «годам опыта»

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

Читать далее

Фото: austin.wordcamp.org.

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

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

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

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

Этапы роста разработчика

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

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

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

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

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

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

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

Написанные «средними» разработчиками самостоятельно системы проваливаются по совершенно иным причинам, чем творения молодых специалистов. Джуниор просто напишет гору условно-рабочих алгоритмов. А хороший «средний» частично воплотит содержимое книг «Design Patterns» и «Domain Driven Design». Конечно, это прекрасные книги для изучения процесса разработки крупных систем. Но простое следование их постулатам приводит к построению излишне сложных систем, которые гибки там, где это не важно, и неповоротливы в значимых вещах.

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

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

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

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

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

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

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

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

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

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

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

Это просто гигантское упрощение

Реальность такова, что никто не подходит под описанные рамки в точности. Я уже устал смотреть, как программистов оценивают по «годам опыта». Безусловно, они что-то могут вам рассказать, но это практически бесполезная информация вне остального контекста.

Более того, в нашей индустрии принято ценить дерзких умных молодых ребят после университета. Эти парни действительно ценны и необходимы, но не более, чем их коллеги с 15-20 годами «полевого» опыта. Пора переставать стереотипно нанимать людей и начать больше думать о команде и сочетаемости талантов. Если все в команде будут думать одинаково — вы окажете медвежью услугу и проекту, и организации.

А вы согласны с автором?

Выскажите ваше мнение в комментариях к публикации.

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.

Читайте также
Маск почти прав: если часто твитить, больше шансов стать успешным (исследование)
Маск почти прав: если часто твитить, больше шансов стать успешным (исследование)
Маск почти прав: если часто твитить, больше шансов стать успешным (исследование)
Российские программисты создали «Ольгу Станиславовну» — нейросеть для оценки комментариев в сети
Российские программисты создали «Ольгу Станиславовну» — нейросеть для оценки комментариев в сети
Российские программисты создали «Ольгу Станиславовну» — нейросеть для оценки комментариев в сети
1 комментарий
Список списков: что почитать в Twitter про карьеру в IT
Список списков: что почитать в Twitter про карьеру в IT
Bubble
Список списков: что почитать в Twitter про карьеру в IT
Как найти работу через LinkedIn: лайфхаки от карьерного консультанта
Как найти работу через LinkedIn: лайфхаки от карьерного консультанта
Bubble
Как найти работу через LinkedIn: лайфхаки от карьерного консультанта

Хотите сообщить важную новость? Пишите в Telegram-бот

Главные события и полезные ссылки в нашем Telegram-канале

Обсуждение
Комментируйте без ограничений

Релоцировались? Теперь вы можете комментировать без верификации аккаунта.

Комментариев пока нет.