Пошаговое руководство: от 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.

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

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

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

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

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

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

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

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



Підписуйтесь: Soundcloud | Google Podcast | YouTube


20 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Массив из миллиона элементов который во обрабатываете на фронте? У вас точно проблема с типом сортировки? Может все таки с архитектурой приложения?

по своему опыту понял что на самообучении далеко не уедешь и синьером не станешь никогда.
с нуля что то освоить на базовом уровне — да это тот случай.
но что б стать експертом нужны 2 вещи обязательно. 1 — практика(реальные сложные проекты, много проектов). 2 — скиловая тима (от которой експертиза и перенимается)

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

Автору не мешало бы указать источник «авторской методики». Учить других это хорошо, но не все могут, поэтому месседж о том, что это прям мастхев непонятен, более того иногда это даже вредно для тех кого «учат».
Массив из миллионов элементов на странице не является чем-то из ряда вон выходящим? Да ладно, а пример можно?
Вы сортируете таблицы из миллионов элементов на странице? Т.е. прям все выгружаете на клиентскую часть?

Там не страница, там мобильное приложение с возможностью работы оффлан, поэтому да там много элементом может бы и поболее миллиона

Чим вмотивована така категоричність п.10 про необхідність менторства?
Виглядає як типова галєрна хотєлка проїхатись на чужих горбах.

Дозволяє ще більше закріпити вивчене. Також відсікаються непотрібні частини знань, що не вкладаються у модель вивченого. Стосується не лише JS а в принципі будь-чого.

Воно то так, але чому так категорично? )

Майстером-джедаєм лише коли у тебе з’являється падаван стаєш ти.
З мого досвіду — це остання сходинка, на яку потрібно впевнено стати, щоб називатись сеніором.

Цикломатическая сложность и умения рефакторинга в «основных навыках», для JavaScript, серьезно?
В современном мире, где скалирование это «а добавь ка в облаке еще десяток инстансов, а то UI диалога логина начал тормозить» первый навык нужен небольшому кругу людей, люто уверовавшему, что они создают второй Гугл попытками скалирования калькулятора на 100500 миллионов онлайн-пользователей.
Второй навык нужен абсолютно любому разработчику, начиная от джунов и заканчивая SDETами.

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

Да, к JS эта статья относится также, как и язык Go к Adobe Photoshop.

Статья почти не привязана к js. Думаю стоило заморочится сделать ее более общей, или расширить до нескольких ЯП.

Достаточно грамотно все описано. Респект!

Software Developer сосредоточен на инструментах, Software Engineer — на процессе разработки

Таке визначення десь описане чи це особисте уявлення автора?

Прочитав key difference за посиланням і воно не матчиться з описом у цій статті.

Розуміння складності алгоритмів, рефакторинг і софт скіли це вимоги до типового девелопера на нашому ринку.

Софт скилы — да
Понимание сложности алгоритмов — уверен что многие даже не понимают что такое Big O, не говорю уже про Big Omega, Big theta (Хотя в практике принято говорить только про Big O).
Рефакторинг — все о нем лишь говорят но мало кто умеет делать.

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

Разработчик — человек который реализовывает систему разработанную инженером!

Но опять же соглашусь еще и с тем мнением что на нашем рынке эти понятия действительно могут иметь совершенно другой смысл.

В чистому виді інженерія це використання фундаментальних знань для вирішення проблем НОВИМИ способами.

Це зовсім не про процеси розробки, алгоритми, рефакторинг чи дизайн-патерни.
А нашому ринку є позиції типу Manual QC Engineer — позиція важлива але важко в’яжеться з поняттям інженерії.

учитывая хейт в недавней теме о литкоде, не только Big O непонимают, но еще и структур данных не знают.

Всё это словоблудие -это, конечно, хорошо, но может кто-нибудь вспомнить хоть одну ситуацию в стиле «извините, вы Developer, а мы ищем Engineer.»

Багато де описане, але багато де по різному. Ще я зустрічав порівняння типу «кодер проти програмісти» і «програміст проти девелопера», загалом більшість людей хочуть відокремити людей з вузькими знаннями від тих хто має широке поле знань, але часто прив’язують це відокремлення до термінів які мають інше значення і з’являеться плутанина. Це мої враження по темі, не претиндую на авторитетність. Але автор дає цікаві терміни

I-Shaped, T-Shaped

ось вони були введені для такого відокремлення, і дають чітке розуміння різниці, вважаю що їх використання доцільніше.

Подписаться на комментарии