Привет, Хабр! Меня зовут Артем Грищенко и я middle iOS-разработчик продуктов Future Crew. Если ты начинающий разработчик, скорее всего, у тебя есть мечта: вырасти, перестать быть «новичком» и почувствовать уверенность в своих силах. Чаще всего говорят: «Это долгий процесс, наберись терпения». И действительно, путь у каждого свой. Но у всех карьерных путей есть общее: рост возможен только при увеличении зоны ответственности. Про это часто забывают, годами просиживая на одном месте. 

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

Ловушка простых задач

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

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

Как меня сначала выжали как котенка, а затем еще пару раз вдохновили по самое не хочу

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

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

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

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

 И здесь сложилось три очень важных фактора:

• желание брать ответственность и развиваться.

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

• желание команды взаимодействовать со мной, а не держать в сторонке.

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

Как я полюбил ответственность и перестал бояться сложных задач

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

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

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

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

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

Какие навыки нужны для роста:

Смелость браться за сложные задачи

Моей первой таской был рефакторинг отправки аналитики. Требовалось разложить события по нужным местам и заменить текущую логику на переиспользуемые вспомогательные функции. И сделать это надо было не на одном экране, а во всем проекте. 

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

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

Открытость к помощи и общению

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

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

Системность в работе

Чтобы не теряться в обилии задач, я учился разбивать их на подзадачи. Декомпозиция помогает сделать работу управляемой и двигаться шаг за шагом. Чтобы этот процесс был прозрачным, я вёл заметки: фиксировал, что уже сделал, что осталось, и какие вопросы нужно уточнить. 

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

Общее понимание продукта

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

Но главный секрет успеха — это поддержка коллег

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

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

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

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

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

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

P.S. За свое везение я хочу сказать спасибо своему лиду — Алексею Григорьеву, который поделился своим опытом выращивания джунов в отдельном посте и показал, что при грамотном подходе начинающие разработчики быстро растут вместе с проектом и становятся опорой продукта.