Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Как перейти из тестирования в разработку и дорасти до Senior. Советы из личного опыта

Привет, меня зовут Ольга, и я работаю Senior Back-end Developer в People.ai. В компанию я пришла как QA Automation и за три года прошла путь до текущей должности.

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

Статья пригодится инженерам позиций джуниор и мидл, которые хотят вырасти или сбалансировать свои hard skills и прокачаться в новых направлениях; QA, стоящим на распутье и думающим, куда двигаться дальше; нововходящим в отрасль и другим. Я не претендую на объективность, а расскажу, как это было, на своем опыте.

Иллюстрация Марии Рыбак

Кратко о моем пути в ІТ

Я закончила Национальный горный университет в Днепре по специальности «Экономическая кибернетика». Эта специальность пыталась объединить в себе модную тогда экономику с элементами Computer Science, поэтому после окончания вуза мне открывалось два пути — поприще экономиста и дорога в ІТ. И сначала я выбрала первое.

С карьерой экономиста не сложилось, зато стало понятно, чего я в жизни делать не хочу. Это нехотение дало мотивацию на занятия, и я стала учить HTML, CSS, SQL, JavaScript, запустила свой блог на WordPress. Меня восхищало то, как несколько тегов могут создать новую сущность, пусть даже одну HTML-страницу.

Затем моя компания стала задумываться о построении внутренней автоматизированной системы аудита, я помогала выделять use-cases и requirements, начала искать литературу, как это делать, и наконец поняла, что мои увлечения могут стать работой.

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

Официально в ІТ я попала в 2014 году, устроилась в Luxoft на позицию тестировщика — проект Deutsche Bank, связанный с тестированием ETL финансовых и рисковых данных и построением отчетов для регуляторов. Тогда моим хобби стал Python, но применить его на проекте возможности практически не было, поскольку работали на удаленной машине со строго ограниченным набором программ.

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

В таком режиме продержалась не больше двух месяцев, так как получила заманчивый офер на QA Automation во Львов (молодая компания Lviv IT, работа на Go Daddy — тестирование системы по продаже услуг хостинга, доменов и прочего).

В 2017 году увидела на фейсбуке пост Олега Рогинского о том, что требуются QA Automation в стартап People.ai. Этот пост меня зацепил — от него повеяло смелостью, дерзостью и новыми технологиями. Написала. Мне ответили, последовала небольшая серия собеседований, потом офер.

История в People.ai

В People.ai необходимо было написать фреймворк для автотестирования по ручным тестам, которые занимали у QA по три дня, чтобы можно было прогонять его регулярно. Это было то, чего я хотела: самостоятельные решения, отсутствие микроменеджмента, интересные задачи. Засиживалась по выходным, потому что затягивало и было интересно попробовать новый подход.

Спустя некоторое время фреймворк был написан, а компания приняла решение работать без тестирования (end-to-end ownership — как девелопер, ты должен проверить свою фичу и провести ее до успешного релиза). Это означало, что QA в компании больше не будет. Мне предложили остаться в роли Junior-разработчика, и я с радостью согласилась.

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

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

Примерно за полгода выросла в мидла. Наверное, больше всего помогло то, что делало меня хорошим QA — привычка к проверкам и к ownership. Я всегда тщательно тестировала свой код и хорошо покрывала юнит-тестами. К тому же накопилось системное знание о том, как работает продукт и как я могу проверить свои компоненты. Я чувствовала себя ответственной за код даже после релиза. Если видишь в проекте фичу, написанную корявенько, но покрытую на 95%, то это моя (шучу).

В 2020 году получила повышение до Senior. Раньше я думала, что Senior — это исключительно степень крутости твоих навыков кодинга. И что до этой ступени мне шагать еще много лет, особенно если оглянуться вокруг и посмотреть, с какими людьми я работаю.

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

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

Советы на пути к Senior

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

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

Базовые вещи

Я сама продолжаю учиться и пытаюсь делать это системно, хоть и не всегда получается. Информации сейчас огромное количество, и тяжело бороться с искушением «пойти по ссылкам» из первой же статьи. Я стараюсь строить свое обучение по табличке в гугл-доке, основанной на Programmer Competency Matrix. Например, как тут.

Заношу темы и ссылки на статьи/учебники в документ и раскрашиваю цветами то, что уже прошла. Это дает мотивацию и позволяет замечать прогресс. До обучения по плану я постоянно видела только то, чего мне не хватает, и теряла мотивацию. Или шла по бесконечным ссылкам, пытаясь объять необъятное и съесть слона целиком, а в результате отчаивалась. Oдин только план не решает проблему системности и нехватки времени, поэтому нужно расставить приоритеты — в порядке важности для работы, актуальности и увлекательности.

Мне помогает тратить деньги на свое обучение, пусть даже символические. На том же Udemy в период распродажи можно купить курсы по 10 долларов, и эти 10 долларов будут мотивировать на продолжение.

Я люблю иногда зависнуть в онлайн RPG или поиграть в «Ведьмака», и мне помогает перенос RPG на реальную жизнь: я словно персонаж, который занимается прокачкой. Зарабатывает себе бейджики на Udemy, закрашивает ячейки в гугл-таблице с планом обучения. А если нет конкретных бейджиков и курсов, я использую простой таймер — пытаюсь как минимум пару часов в неделю тратить на улучшение своих скилов.

Еще один совет по базовым вещам — стараться выделить время на обучение в процессе работы над чем-то новым. Грубо говоря, лучше не бежать за хотфиксом на Stack Overflow, а выделить время на более глубокое изучение вопроса (конечно, если вокруг нет пожара и система не лежит).

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

Не кодингом единым

Кроме базы того, что делает человека инженером (а не доктором или архитектором), есть список умений и навыков, которые отличают именно Senior. Я бы хотела описать их подробнее, так как для меня они стали откровением.

  • ownership;
  • самостоятельность;
  • инициативность;
  • способность смотреть страху в лицо;
  • коммуникация и прозрачность.

Ответственность за свой код. Это основное, особенно в продукте. Я бы даже сказала, что это условие попадания в продукт.

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

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

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

Самостоятельность. Это способность решить проблему. Размер проблемы зависит от уровня, на котором человек действует, и важно стремиться этот уровень повышать.

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

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

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

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

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

Пример из жизни. У нас есть репозиторий с кодом, хорошенько покрытый тестами. Тестов много, около двух тысяч. Каждый деплой на прод проходит после проверки линтером, проверки на уязвимости в библиотеках и прогона всех тестов. Тесты бегут не менее 10 минут. Итого, чтобы вмерджить код в master, необходимо 10 минут плюс еще 10 минут, чтобы задеплоить на прод.

Учитывая, что команда в среднем деплоит 7 раз в день, получаем 140 минут ожидания в день на команду. А если сталкиваемся с необходимостью сделать хот-фикс, то 20 минут превращаются в целую вечность.

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

Другой мой коллега очень не любит динамическую типизацию и использует в своих проектах статическую проверку типов через mypy. Там, где он касается кода, добавляет аннотацию с типами. Коллега активный ревьюер pull request’ов и, помимо рекомендаций по оптимизации кода, всегда напоминает о проверке типов. Сколько времени моей жизни он сэкономил, дав дельный совет или удержав от ошибки, я уже не берусь посчитать.

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

Способность смотреть страху в лицо. Страх, чувство неуверенности — это хорошо. Это выход из той самой зоны комфорта, знак в начале неизвестной дороги. А что толку ходить всегда одними и теми же путями? Бояться нужно однотипности.

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

А потом вдруг понимаешь, что именно сделало упомянутого инженера более опытным. Он не боялся разбираться в новом, он читал код, документацию, логи и учился. И если не браться за новые задачи, то никакого опыта не будет, один лишь стаж. И это понимание — важная ступень между language-specific кодером и инженером.

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

Понимание последнего пришло ко мне с трудом. При переходе от джуниора я задавала много вопросов. Мне было неловко, но и работу надо было делать. А потом дошло, что целесообразнее потратить 10 минут времени более знающего коллеги, чем часами или днями биться об стену. Правда, и спрашивать теперь приходится гораздо реже.Тем самым я отвечаю своим коллегам — всегда готова ввести в курс дела или объяснить логику известного мне компонента.

Смотреть страху в лицо — это еще и умение признавать свои ошибки и учиться на них. В нашей компании с этим помогает практика написания постмортемов. Постмортем — это своеобразный отчет об инциденте, анализ его причин, таймлайна и поиск шагов по предотвращению подобных случаев в будущем, уменьшение времени на обнаружение и расследование. Каждый постмортем обсуждает инженерная команда. В результате всегда имеется список action items, которые будут предприняты в течение одной-двух недель. Таким action item может быть написание нового теста, добавление нового мониторинга или логов, введение дополнительных ограничений и политик.

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

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

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

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

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

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

Вывод

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

И ответ на вопрос — зачем все это нужно? Мне это было нужно, потому что хотелось большей свободы и возможности создавать новые сущности и улучшать их. А также владеть суперспособностью починить прод и решить чью-то проблему (в диадеме и развевающемся плаще).

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

Если нет никакого интереса, то и результата не будет. А начальный импульс нужно помогать себе поддерживать: придумывать ачивки, измерять прогресс достижением каких-то шагов, заводить пет-проекты. И беречь себя от перенапряжения, после которого несколько дней ничего не хочется.

В заключение не могу удержаться и не посоветовать курс, с которого практически начался для меня Python — MITx: 6.00.1x Introduction to Computer Science and Programming Using Python, доступен на edx.org. Когда я проходила, проверка домашних заданий и получение сертификата еще были бесплатными.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось26
До обраногоВ обраному10
LinkedIn

Схожі статті




22 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Спасибо за статью.
Заметил у вас в статье такую вещь,как programmer-competency-matrix.
Честно говоря, мне кажется, что там не хватает ещё одной колонки типа О(1) :)

Люди, які за 3 роки «виростають» з Junior QA в Senior Dev, нівелюють всі ці звання і лички від Junior до Senior.

ого. сильне ствердження. так думаю що потрібно знати весь анамнез, що було «до» QA. може там тридцять років викладання на вайтішних курсах;)

Якщо людина 30 років працювала викладачем, то вона має право називати себе Senior Lecturer. Але при чому тут Senior Developer? Це рівень того, хто багато років (і успішно) займався комерційною розробкою.

ні. це рівень того, хто вміє розв’язувати проблеми замовника самостійно швидко і найкращим чином. із роками і десятиліттями формального «досвіду» ця характеристика прямого зв’язку не має.

Це ваша думка, яка не має нічого спільного з реальністю.

"це ваша думка, яка не має нічого спільного з реальністью"©

Тоже из Automation перешёл в разработку. Вдохновляющая статья.

" Как перейти из тестирования в разработку"...залишитися в компанії, бо QA вже не треба, але запропонували бути одразу Junior розробником)
...дякую, класний спосіб, записав

карошая добрая статья, прочитал удовольствием:). правда потом почитал об єтом вашєм пипле.аі на прекрасном, и теперь даже не знаю кому доверять.

Не розумію :
1. Чого не рости в QA
2. Чого було не йти відразу в dev?
3. Чого взагалі в dev?

А хто вам сказав, що в Україні хочуть зробити кар’єру в QA або R&D? Люди все життя проводять в погоні за довгим доларом.
Якби програмісту платили 500 доларів, а охоронцю в офісі 2000 доларів, як ви думаєте, ким би люди мріяли стати?

назревает логичный вопрос...а что дальше?
в лиды?

А далі буде пост «Як стати архітектором за 1 день»

Відкрита вакансія у people.ai — Principal Backend Engineer до $11 000
Рівень зарплатні — вражає
Як розумію, так дорого оцінюється реальний, багаторічний досвіт, здобутий на багатьох Enterprise-проектах
Маю це показати знайомим, які ставлять математичну базу перш за все

здобутий на багатьох Enterprise-проектах

Відповідно, кожен рік-два потрібно міняти контору, щоб був досвід.

якщо ви будете кожний рік скакати, то на principal вас точно не візьмуть.

А так не візьмуть, бо за 6 років на одному проекті технології протухли.

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

как эксперт по всему этому прямо заявляю ерунда это подделка )) «любовь» и прочия бла бла бла ныне модная

как и во многих и видимо всех схожих сферах всё решает практика а «любовь» возникает уже там когда уже достаточно практики как банальной привычки просто брать и этим заниматься вот и весь секрет «главное любовь» да ничё такого просто берёшь и делаешь и так повторяешь 10,000 раз и оп-па ты уже просто делаешь это автоматически и это тебе уже даже нравится просто потому что ты уже можешь вот это всё

There Is No Spoon

первыйна!

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