От разработчика-мидла к сеньору-архитектору: путевые заметки для идущих вверх

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

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

Кто такие джун, мидл и сеньор

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

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

Мидл — специалист, способный самостоятельно решить почти любую задачу, составить простое ТЗ. Мидл начинает искать решение с мыслью: «Как сделать так, чтобы не пришлось переделывать?». Ищет точки вариации, задает вопросы сеньорам и архитекторам, анализирует их логику.

Сеньор — специалист, который:

• Помимо разработки может выступать в роли архитектора на проекте;

• Знает большинство ответов на технические вопросы за счет полученного ранее опыта;

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

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

Если кратко, то:

• Джун учится решать задачи;

• Мидл умеет самостоятельно решать задачи и берет ответственность за их решение;

• Сеньор делит проблему на задачи и отдает их на разработку мидлам и джунам;

• От джуна и мидла ждут решения задач;

• От сеньора ждут готовый продукт.

Мидл решает задачи, сеньор решает системные проблемы. Главная причина, по которой мидл-разработчики перестают расти — неготовность брать ответственность за проект, команду. Быть мидлом — не плохо. Плохо, когда вы хотите расти, но не знаете как.

Путевые заметки

1. Не бойтесь задавать вопросы

Мы часто стесняемся переспросить, так как боимся показаться некомпетентными. В результате ничего хорошего из этого не получается. Как на этой картинке про «качели вместо качели»: заказчик хотел одно, исполнитель додумал детали сам — получилось нерабочее решение.

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

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

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

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

2. Учитесь оценивать задачи

Почему это важно:

• Вы поймете, когда необходимо декомпозировать задачу (поделить на мелкие задачи);

• Вы начнете видеть, какой информации вам не хватает для лучшего решения проблемы;

• Вы сможете заранее обосновать сроки разработки: «Тут много неопределенностей, необходимо заложить больше времени».

3. Беритесь за «неудобные» задачи

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

Беритесь за сложные задачи. Может быть, не получится их решить, но вы значительно прокачаете свои навыки.

4. Отдыхайте

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

Если вы устали, то ваша работоспособность падает и вы начинаете делать задачи в разы медленнее. Когда к вам приходит осознание, что на печатную форму, на которую раньше уходило 4 часа, теперь уходит 6 часов, то ваша продуктивность начинает падать еще сильнее . Получается порочный круг, из-за которого специалисты приходят к выгоранию.

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

Как говорят сисадмины: «Семь бед — один reset». Перезапустите себя и отдохните. Восстановиться можно с помощью любой физической активности или общения.

5. Волшебный пендель

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

Если подводить итог, то:

1. Будьте дотошными;

2. Обдумывайте решения;

3. Учитесь оценивать задачи;

4. Решайте задачи, за которые никто не хочет браться;

5. Отдыхайте.

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

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

Где брать задачи для прокачки?

1. В текущей работе: возьмите задачу соседней команды.

2. Pet-проект: например, «Личный бюджет» на 1С. В нем необходимо посчитать свой бюджет, использовав справочники, регистры, отчеты.

3. Общение с коллегами. Опыт передается через истории из практики и обсуждений задач.

4. Курсы, видео и статьи в открытом доступе.

Став мидлом, я долгое время не понимал, куда мне идти дальше, и осознал, что хочу быть архитектором, когда начал изучать различные ресурсы (книги, телеграм-каналы). Самое главное — пробовать новые знания на практике. Без этого они не закрепятся в вашей голове. Я рекомендую прочитать:

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

• «Профессиональная разработка в системе «С:Предприятие 8. Издание 2». Я ее читал, когда был джуном и готовился к тестированию 1С:Специалист. Это лучшая книга, которая расскажет о том, как работает платформа.

Каждый шаг вперед — это маленький подвиг

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.