Как сделать шаг вперед в качестве младшего, среднего или старшего разработчика?

По адресу Командный редактор - 6 months and 3 weeks ago / Apr 2020
Как сделать шаг вперед в качестве младшего, среднего или старшего разработчика?

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

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

Различные старшинства Названия

Различные организации могут иметь разные старшинства, но в основном они делятся на три категории:

  • Младший разработчик
  • Разработчик среднего уровня
  • Старший разработчик

Младший разработчик

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

  • Их основная мантра - "заставить его работать", не обращая особого внимания на то, как достигается решение. Для них рабочее программное обеспечение и хорошее программное обеспечение эквивалентны.
  • Обычно для достижения чего-то они требуют очень специфических и структурированных направлений. Они страдают от туннельного зрения, нуждаются в наблюдении и постоянном руководстве, чтобы быть эффективными членами команды.
  • Большинство младших разработчиков просто пытаются выполнить эту роль и, застряв, могут уйти с работы к старшему разработчику, вместо того, чтобы хотя бы попытаться что-нибудь зарезать.
  • Они не знают о деловой стороне компании и не понимают, как думают менеджмент/продажи/маркетинг/ и т.д., и не понимают, сколько переделок, потраченных впустую усилий и ухудшения для конечного пользователя можно сэкономить, познакомившись с бизнес доменом.
  • Чрезмерный инжиниринг является серьезной проблемой, часто приводящей к хрупкости и ошибкам.
  • При возникновении проблемы они часто пытаются исправить только текущую проблему, так же известную как исправление симптомов, вместо того, чтобы исправлять проблему с корнем.
  • Ты можешь заметить поведение "Чьей-то Эльзы" от них.
  • Они не знают, что или сколько они не знают, благодаря эффекту Даннинг-Крюгера.
  • Они не берут на себя инициативу и могут бояться работать над незнакомой кодовой базой.
  • Они не участвуют в обсуждениях в команде.

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

  • Всевозможные проблемы могут быть решены, если вы работаете над ними достаточно долго. Не сдавайтесь, если переполнение стека или проблема на GitHub не имеет ответа. Говорить "Я застрял, но я пробовал X, Y и Z. Есть ли у тебя какие-нибудь указания?" на твою зацепку гораздо лучше, чем говорить "Это за гранью моих возможностей".
  • Читайте много кода, не только код в проектах, над которыми вы работаете, но и исходный код ссылки/фреймворка, с открытым исходным кодом. Спросите своих коллег-разработчиков, возможно, и на Reddit, о хороших примерах с открытым исходным кодом для выбранного вами языка/инструментов.
  • Делайте личные побочные проекты, делитесь ими с людьми, вносите свой вклад в сообщество с открытым исходным кодом. Обращайтесь к людям за помощью. Вы будете удивлены, сколько поддержки вы можете получить от сообщества. Я до сих пор помню свой первый проект с открытым исходным кодом на GitHub около 6 лет назад, это был небольшой PHP-скрипт (библиотека), который получал подробности для заданного адреса из Google's Geocoding API. Кодовая база была супер грязной, в ней не было никаких тестов, не было никаких подсказок или снифферов, а также не было CI, потому что я не знал ни о чем из этого в то время. Не знаю, как, но одна добрая душа каким-то образом нашла проект, разломала его, переделала, "модернизировала", добавила linting, пронюхала код, добавила CI и открыла запрос на вытаскивание. Этот единственный запрос на подтягивание научил меня так многому, что я, возможно, никогда не научился бы так быстро, потому что я ещё учился в колледже, работал в маленькой сервисной компании и делал просто маленькие сайты, не зная, что правильно, а что нет. Этот пиар на GitHub был моим знакомством с открытым исходным кодом, и я всем обязан этому.
  • Избегайте так называемого "чьего-нибудь проблемного поля" поведения.
  • Когда дается задача, чтобы решить, попытаться определить первопричину и исправить это вместо того, чтобы исправлять симптомы. И помните, не имея возможности воспроизвести, средства не решены. Она решается, когда понимаешь, почему это произошло и почему больше не происходит.
  • Имейте уважение к коду, который был написан до вас. Будьте щедры при вынесении суждений об архитектуре или проектных решениях, принятых в коде. Поймите, что код часто бывает некрасивым и странным по причине, отличной от некомпетентности. Научиться жить и процветать с унаследованным кодом - это большое умение. Никогда не думайте, что кто-то глуп. Вместо этого выясните, как эти умные, целеустремленные и опытные люди пришли к решению, которое сейчас является глупым. Подходите к унаследованию унаследованного кода с "менталитетом возможностей", а не с жалобой.
  • Это нормально - ничего не знать. Тебе не нужно стыдиться того, что ты уже ничего не знаешь. Нет глупых вопросов, задавайте сколько угодно вопросов, которые позволили бы вам работать эффективно.
  • Не позволяй себе ограничивать свое рабочее место. Продолжайте работать над своим самосовершенствованием.
  • Делай домашнее задание. Представь, что спускается по трубе. Участвуй в обсуждениях в команде. Даже если ты ошибаешься, ты чему-нибудь научишься.
  • Узнайте о домене, с которым вы работаете. Узнайте о продукте как о конечном пользователе. Не предполагайте ничего, задавайте вопросы и уточняйте в случае сомнений.
  • Научитесь эффективно общаться - мягкие навыки имеют значение. Научитесь писать хорошие электронные письма, представлять свою работу, вдумчиво формулировать свои вопросы.
  • Посиди со старшими разработчиками, посмотри, как они работают, найди наставника. Никому не нравятся всезнайки. Держись за свое эго и будь достаточно скромным, чтобы брать уроки у опытных людей.
  • Не просто слепо следуйте советам "экспертов", возьмите его с зерном соли.
  • Если вас просят предоставить смету некоторых работ, не отвечайте, если у вас нет всех подробностей, чтобы сделать разумную оценку. Если вас вынуждают это сделать, разместите его 2 раза или более в зависимости от того, насколько сильно вы не знаете, что нужно сделать для того, чтобы задача была помечена как "выполненная".
  • Уделите некоторое время тому, чтобы научиться пользоваться отладчиком. Отладчики весьма полезны при навигации по новой, недокументированной или плохо документированной кодовой базе или при отладке странных проблем.
  • Не говорите "это работает на моей машине" - да, я часто это слышал.
  • Попробуйте превратить любые чувства неадекватности или синдром самозванца в энергию, чтобы продвинуться вперед и увеличить свои навыки и знания.

Разработчики среднего уровня

Следующий уровень после младших разработчиков - Mid Level. Они технически сильнее Junior-разработчиков и могут работать с минимальным контролем. Им еще предстоит решить некоторые проблемы, чтобы перейти на старший уровень.

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

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

Старшие разработчики

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

  • С их прошлым опытом, допущенными ошибками, проблемами, с которыми сталкивается чрезмерно разработанное или недоработанное программное обеспечение, они могут предвидеть проблемы и убедить в направленности кодовой базы или архитектуры.
  • У них нет синдрома "Шайни-Той". Они прагматичны во время казни. Они могут делать компромиссы, когда это необходимо, и они знают почему. Они знают, где быть догматичными, а где прагматичными.
  • У них хорошая картина поля, они знают, какой инструмент лучше всего подходит для работы в большинстве случаев (даже если они не знают этот инструмент). У них есть врожденная способность подобрать новый инструмент/язык/парадигму/ и т.д., чтобы решить проблему, которая требует этого.
  • Они знают, что они в команде. Они рассматривают это как часть своей ответственности по наставничеству. Это может варьироваться от парного программирования с младшими девчонками до выполнения невыразительных задач по написанию докторских или тестовых работ или чего-либо еще.
  • Они имеют глубокое понимание домена - они знают о деловой стороне компании и понимают, как менеджмент/продажи/маркетинг/ и т.д. думают и извлекают выгоду из своих знаний в области бизнеса в процессе развития.
  • Они не делают пустых жалоб, они выносят решения, основанные на эмпирических доказательствах, и у них есть предложения по решениям.
  • Они думают гораздо больше, чем просто код - они знают, что их работа заключается в решении проблем, а не просто в написании кода.
  • Они имеют возможность брать на себя большие неопределённые проблемы, определять их, разбивать на части и выполнять фигуры. Старший разработчик может взять что-то большое и абстрактное и работать с этим. Они придумают несколько вариантов, обсудят их с командой и реализуют их.
  • Они с уважением относятся к коду, который был написан перед ними. Они щедры, когда выносят суждения об архитектуре или проектных решениях, принятых в коде. Они подходят к унаследованию унаследованного кода с "менталитетом возможностей", а не с жалобой.
  • Они знают, как давать обратную связь, никому не причиняя вреда.

Заключение

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

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

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


Эта статья была первоначально опубликована на сайте https://roadmap.sh 3 декабря 2019 года и была написана Камраном Ахмедом: https://roadmap.sh/guides/levels-of-seniority. Пожалуйста, обратите внимание, что разрешение на использование контента было сделано с автором в твиттере перед публикацией.





Командный редактор
Командный редактор
Кураторство блогов для cdrrazan.com! В основном код, линукс и техника для помощи студентам и профессионалам.


комментарии на основе Disqus