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

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

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

Выберите своего наставника

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

Быть голодным

Давайте подготовим несколько вопросов перед началом рабочего дня. Давайте спросим о проекте, который вы объединили, не только об его общей архитектуре, но и о его бизнес-подходе. Как разработчик, вы должны понимать архитектуру системы, исходный код программного обеспечения. Однако, зная бизнес-требования и варианты использования системы, вы поймете, почему система спроектирована таким образом, а не другим.

Помните, что когда вы новичок, у вас есть только одно простое, но более мощное преимущество. Спрашивать. Вы можете спросить обо всем, когда вам двадцать, но когда вам тридцать, вы не можете.

Четыре уровня «знания»

Если кто-то спросит вас, знаете ли вы технологию или нет, когда вы ответите да или нет?

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

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

Читать чужой документ, чужой исходный код

Это еще один взгляд на изучение чужих ошибок.

В то время, когда вы начинаете работу над уже работающим проектом, вам нужно так много всего прочитать — BRD, HLD или какое-то детальное решение и элегантные исходные коды проекта (конечно, есть). Это кажется скучной работой, но вы можете переосмыслить и изменить свое мнение на более интересные задачи. Помимо глубокого понимания проекта, в котором вы будете работать, вы должны подумать: «Если бы я был им, поступил бы я так? Да, это было отличное решение ИЛИ Нет, я бы нашел другие пути». Пусть думают, что вы пишете/кодируете, а не просто читаете.

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

И, наконец, никогда не сдавайся

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

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