Как инженер-программист прошел путь от SW2 до директора за 4 года

Как быстро получить повышение. Как инженер получил 4 повышения менее чем за 4

Чтобы помочь мне понять вас, заполните этот опрос (анонимно)

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

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

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

The estimated total pay for a Principal Technical Program Manager is $165,559 per year in the San Francisco, CA Area area, with an average salary of $144,822 per year.

По данным Glassdoor. Это доходит до 322 000 для более хорошо зарекомендовавших себя компаний.

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

Фон

Эта история впервые была освещена на YouTube-канале Рахула Пандея здесь. Команда изо всех сил пыталась снизить эксплуатационные расходы на свои услуги. В то время как команда инженеров сосредоточилась на разработке сложных решений, один креативный инженер начал копаться в проблеме. Он заметил, что было несколько клиентов, которые значительно увеличили расходы, но не так сильно увеличили доход. Сбросив расходы с этих клиентов, эта проблема будет решена. Без необходимости дорогостоящего проектирования. И гораздо быстрее. Это позволило ему получить множество повышений по службе.

Основные моменты

Эта история будет охватывать следующие идеи

Иногда нужно разрубить гордиев узел. Программная инженерия часто связана с решением большого набора проблем. Иногда инженерам приходится придумывать замысловатые решения, чтобы распутать нити. В других случаях вы хотите прорваться насквозь. Рассказ об Александре Македонском.
Проектирование хорошее. Инжиниринг в контексте экономических решений намного лучше. Вместо того, чтобы подходить к вещам как к чисто инженерной проблеме (что было бы сложно), этот инженер попытался исправить экономический аспект (сделать решение более устойчивым). Это было намного лучше.
Расширьте свой кругозор. Решение, которое придумала наша прекрасная рок-звезда, является одним из основных примеров принципа Парето (правило 80–20). Каждый разработчик программного обеспечения, серьезно относящийся к своей карьере, должен много читать. Или подвергать себя различным идеям. Уметь кодировать — это круто. Принятие правильных решений гораздо важнее.

Это не тот пост, который вы хотите пропустить. Давайте повеселимся.

Александр Македонский и узел Гордиона

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

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

Благодаря досрочным победам Александр дошел до города Гордиум. Там лежал знаменитый гордиев узел, спутанная веревка. Легенда гласит, что тот, кто развяжет веревку, будет править миром. Имейте в виду, что греки очень верили в это. Таким образом, было очень важно развязать это.

Александр боролся с этим секунду. Чем больше времени он проводил, тем более беспокойными становились его солдаты (и он сам). В конце концов Александр заявил, что в легенде не сказано, что узел нужно развязывать определенным образом. Поэтому он вытащил свой меч и разрубил узел, в процессе развязав вещь.

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

Так как же нам убедиться, что мы не попадемся в эту ловушку? Давайте рассмотрим это дальше.

Сделайте вдох, выпейте воды и уменьшите масштаб

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

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

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

Читать Читать и еще раз читать

Плохие программисты вообще не читают. Хорошие инженеры читают много технических материалов (блоги, доклады, статьи и книги). Феноменальные инженеры читают все это, но также узнают, как насчет более «мягких» навыков (общение, обучение, организация) или более «гуманитарных наук» (экономика, история, социология и т. д.). Помните, какой бы код мы ни создавали, мы создаем его для людей (прямо или косвенно). Если никто не может использовать то, что вы создаете, оно бесполезно. Научиться создавать решения, которые приносят большую пользу, и работать с другими над созданием собственных решений — это важные навыки, которые помогут вам достичь вершины. Игнорируйте их на свой страх и риск.

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

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

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

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

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

Для машинного обучения решающее значение имеет база, сочетающая программную инженерию, математику и информатику. Это поможет вам концептуализировать, построить и оптимизировать машинное обучение. Мой ежедневный информационный бюллетень Интервью по технологиям — это просто охватывает темы проектирования алгоритмов, математики, последних событий в области технологий, разработки программного обеспечения и многого другого, чтобы помочь вам стать лучшим разработчиком. Сейчас действует скидка 20 % на ЦЕЛЫЙ ГОД, так что не забудьте проверить ее.

Я создал Технологические интервью, сделанные просто, используя новые методы, полученные в результате обучения нескольких людей в ведущих технологических компаниях. Информационный бюллетень предназначен для того, чтобы помочь вам добиться успеха, избавив вас от часов, потраченных впустую на работу с Leetcode. У меня есть политика 100% удовлетворения, поэтому вы можете попробовать ее без риска для себя. Вы можете прочитать FAQ и узнать больше здесь

Не стесняйтесь обращаться, если у вас есть какие-либо интересные работы/проекты/идеи для меня. Всегда рад вас выслушать.

Для денежной поддержки моей работы следуют мои Venmo и Paypal. Любая сумма приветствуется и очень помогает. Пожертвования открывают эксклюзивный контент, такой как анализ бумаги, специальный код, консультации и специальные тренировки:

Венмо: https://account.venmo.com/u/FNU-Devansh

Paypal: paypal.me/ISeeThings