Май 03

Пошаговое руководство: от Intermediate к Senior Engineer в JavaScript

Меня зовут Сергей Синенок, я в разработке ПО уже 13 лет и сейчас сотрудничаю с компанией Dev.Pro в роли Solution Architect. Уже не первый год мы в компании занимаемся карьерным планированием и системным развитием специалистов, где я выступаю техническим экспертом и помогаю строить планы дальнейшего развития.

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

Software Developer vs Software Engineer: основные отличия

Для начала предлагаю разобраться, в чем разница между разработчиком и инженером. Конечно, оба хорошо умеют программировать, но сфокусированы они на двух разных компонентах разработки: Software Developer сосредоточен на инструментах, Software Engineer — на процессе разработки. Также Software Engineer должен обладать общими знаниями в Computer Science: алгоритмы и структуры данных, сложность алгоритмов и Big O Notation, паттерны проектирования. А Software Developer хорошо знает свои инструменты — языки, фреймворки, библиотеки. Условно говоря, Software Developer занимается разработкой компонентов системы, а инженер — разработкой целостной системы, ее поддержкой и масштабированием.

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

I-Shaped — этот специалист является экспертом в конкретной области, углубляет свои знания в ней. Пример: Senior Angular Front-end Developer.
T-Shaped — специалист в конкретной области, с широким кругозором и экспертизой в смежных областях. Пример: Senior Full Stack Developer.
E-Shaped — эксперт в нескольких областях, с широким кругозором и экспертизой в смежных дисциплинах. Пример: Senior Software Engineer.

Основные навыки Senior Software Engineer

Масштабирование и цикломатическая сложность

Как правило, когда мы работаем над ежедневными задачами, наша продуктивность и успешность выполняемой задачи измеряется тем, как быстро мы пишем код. В долгосрочной перспективе такой подход может привести к проблемам. Чтобы избежать подобных ошибок, стоит учитывать вопросы масштабирования и понимать цикломатическую сложность кода. Понимание принципов цикломатической сложности и Big O Notation для кода — основа построения систем, устойчивых к изменениям. В изучении этих основ вам поможет курс Coursera Algorithms, Part 1.

Для большей наглядности предлагаю рассмотреть инструмент, который я ежедневно использую в своей работе, Big-O Cheat Sheet.

Выше вы видите график, который показывает сложность алгоритмов и отмечает, к какой категории производительности относится тот или иной алгоритм на основании критерия сложности. Если у алгоритма сложность n^2 и больше, то его не стоит использовать в ежедневной разработке.

Как это применить на практике? Предлагаю разобрать на примере ситуации, с которой не так давно столкнулась наша команда. Для наглядности рассмотрим еще несколько таблиц.

В первой таблице по горизонтали показана сложность алгоритма, по вертикали — количество элементов. На пересечении — скорость обработки такого количества данных при заданной сложности.

На второй таблице мы видим, что есть такой метод сортировки, как Bubble Sort, и в худшем случае сложность этого алгоритма квадратична. Это говорит о том, что сортировка массива с миллионом элементов (10^6) методом «пузырька» (квадратичная сложность O(n^2)) займет чуть меньше 12 дней.

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

Рефакторинг

Рефакторинг также обязательный навык, который жизненно необходим для Senior-специалиста.

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

Базовый статический анализ кода — linter. Стандарты кодирования едины для всех в команде.
Unit Testing. Рефакторинг по принципу «не навреди». Тестируется только то, что нужно: стандарты покрытия для кода, отчетность и так далее.
Самодокументируемый код. Используется документация, которая никогда не устаревает, она генерируется из кода.
Advanced Code Analysis. Тестирование code smells, дублирование, покрытие комментариями.
Безопасность кода, зависимостей и окружения. Автоматизация сканирования кода на безопасность и прочие метрики.

Пресловутые people skills: soft and meta skills

Когда я только начал включать people skills в необходимые скилы для развития, ко мне приходили с вопросами: «А зачем мне это нужно, если я разработчик? Мое дело — писать код».

Отвечая на этот вопрос, предлагаю посмотреть на ситуацию более глобально. Сообщество экспертов Мирового экономического форума (Давос) еще в 2016 году спрогнозировало, что все больше проектов будут требовать командного взаимодействия: акценты смещаются и важность soft skills повышается. Поскольку IT — это часть мировой экономики, тренды, которые там задаются, влияют на события в мире и в IT в частности. Это ведет к тому, что в любом проекте команда всегда опережает одного человека в долгосрочной перспективе по скорости и надежности выполняемой работы.

Мета-навыки — это навыки, «выходящие за пределы». Они выходят как за пределы той или иной деятельности, так и за пределы привычного мышления, восприятия мира и себя в нем. К этим навыкам относится осознанность, управление вниманием, навыки исследования и коррекции собственного восприятия. Прогноз Мирового экономического форума 2020 года: 50% наемных работников будут остро нуждаться в переквалификации к 2025 году.

Поэтому soft и meta skills — неотъемлемая часть экспертизы любого человека, который желает достичь успеха в современном мире.

Knowledge Mind map: мой путь

Помимо навыков, указанных выше, в мире JavaScript мы используем дорожную карту скилов, которой я хочу с вами поделиться. Она поможет построить личный план роста для повышения навыков и экспертизы, которые позволят выйти на новый уровень.

Чтобы было легче ориентироваться в этой карте, я коротко объясню ее принцип работы.

Серый блок — это ваша стартовая точка, уровень экспертизы, которым вы уже владеете. В Definition более подробно указано, какие знания и навыки должен иметь специалист Intermediate-уровня.

От My journey to mastery и начинается наше путешествие к накоплению новых знаний и повышению навыков до уровня Senior. Ответвления делятся на несколько категорий. Первая — это JavaScript stack: в зависимости от того, какие навыки вы хотите прокачать, выбираете релевантную область и углубляете свои знания, протаптывая все новые тропы. Вторая — это people skills, равнозначно важная область, которая требует погружения и прокачки. Третья — Tech Agnostic, которая тоже имеет свои особенности.

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

Авторская методика: гайд по повышению квалификации

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

Главное в этой методике — не пропускать ни единого пункта, только тогда будет результат. Также не забывайте о Rule of Thumb: учиться лучше каждый день и понемногу, чем все и сразу. Прежде чем приступать, рассмотрим следующие пункты:

Определяемся с тем, что хотим изучить. Могут помочь вопросы: что именно я хочу изучить? Зачем?
Ставим себе дедлайн: когда мне нужен результат?
Выделяем время на обучение: когда и как часто я буду учиться?

А теперь приступим к шагам. Первые 6 — подготовительные и нужны для того, чтобы заложить фундамент. Следующие 4 погружают в обучение по LDLT-формуле: learn, do, learn, teach.

Итак, первые шаги ниже:

Общий план. Знакомимся с предметом изучения.
Определяем скоуп. Что конкретно по теме хотим изучить? Например, выучить Node.js — не подходит, мало конкретики. А вот научиться делать REST API на Node.js — то, что нужно.
Определяем критерий успеха. Что будет результатом обучения? Например, сделать REST API на Node.js с CRUD-операциями для продуктов.
Собираем информацию. Составляем список ресурсов для изучения темы. Здесь можно записывать все, что найдете.
Составляем пошаговый план обучения. Теперь составляем структуру, дорожную карту обучения. Можно подсмотреть у других (книги, курсы и так далее) и визуализировать.
Фильтруем ресурсы из № 4. Подбираем подходящие под каждый пункт нашего плана из № 5.
Изучаем достаточно для того, чтобы начать. Пример: запускаем Node.js server без фреймворков.
Включаемся в игру. Экспериментируем с результатами из № 7. «А что, если...?» — наш лучший друг.
Изучаем достаточно, чтобы сделать что-то полезное (достичь нашей цели) — что нужно знать и уметь для этого?
Обучаем других. Учим тому, что узнали сами — структурируем знания и делимся с другими людьми.

Пункты № 8 и № 9 повторяем до тех пор, пока не получим ожидаемый результат. Пункт № 10 нельзя пропустить. Никак. Совсем!

Ошибки, которые я совершал на своем пути

Перекладывание ответственности за свое обучение. Помните о том, что вектор своего развития стоит выбирать самостоятельно в зависимости от ваших планов и целей. Если будете следовать чужим указаниям, то и достигать будете того, что нужно другим, а не вам.
Хаотичное изучение «новеньких блестящих» технологий. Без стратегии и понимания того, какого результата вы желаете добиться, результат будет минимальным.
Спешка и желание знать все и сразу. Всему нужно время. Не пытайтесь перепрыгнуть сразу же к результату, находите интерес в пути.
Бесплатно — значит бесполезно. Ранее я недооценивал бесплатный контент, считая, что пользу можно получить только из платных ресурсов. Но практика показала, что в сети есть много полезного.
Непонимание ценности ментора. «Я и сам могу! Зачем кому-то мне помогать? Учить меня чему-то?» Узнали себя? На самом деле ментор кратно повышает вашу скорость и качество роста, делясь практическим опытом, о котором не прочтешь в книгах.

Рекомендации: что почитать

Clean Coder, The: A Code of Conduct for Professional Programmers — кто такой профессионал в сфере Software Engineering?
The Pragmatic Programmer: your journey to mastery — как стать гуру Software Engineering?
The Complete Software Developer’s Career Guide: How to Learn Your Next Programming Language, Ace Your Programming Interview, and Land The Coding Job Of Your Dreams — набор практических советов по построению карьеры в Software Engineering.
Dinosaur Brains: Dealing with All THOSE Impossible People at Work — soft skills. Советы о том, как ладить с разными людьми.
Emotional Intelligence 2.0 — эмоциональный интеллект. Инструкция по применению.

Вместо выводов

Software Developer занимается разработкой компонентов системы, а инженер — разработкой целостной системы, ее поддержкой и масштабированием.
В ежедневной работе специалисту важно учитывать масштабирование и понимать цикломатическую сложность. В этом поможет инструмент Big-O Cheat Sheet.
Meta и soft skills никуда не уходят, а приобретают все большее значение в современном мире.
Результаты любят цели, дедлайны, записи и визуализацию.
Ошибаться — это нормально, но все же лучше учиться на ошибках других. Берите ответственность за свое обучение, не пытайтесь узнать все сразу, не пренебрегайте помощью других и будет вам счастье!