How a Software Engineer went from SW2 to Principal in 4 Years [StoryTime Saturdays]
How To Get Promoted FAST. How an engineer received 4 promotions in less than 4
Happy Saturday my amazing readers,
I hope you’re all having an amazing time. I’m flying to India tomorrow, and am super excited about that. Will be seeing my family and some friends, and have an amazing time. I will be traveling quite a bit. Continuing with the theme of meeting my amazing audience, drop your locations to me by replying to this email/my social media. If you’re in India, I might just drop by your city.
In this post, I will cover a very interesting story that I came across. It is the story of a true Rockstar Software Engineer. He went from a measly Software Engineer 2 to a Principle Tech Lead Manager in less than 4 years. Today, we’ll cover how.
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.
-According to Glassdoor. This goes all the way upto 322K for more well-established companies.
Background
This story was first covered on Rahul Pandey’s YouTube channel here. A team was struggling to reduce their operational costs on their services. While the engineering team focused on engineering heavy solutions, one creative engineer started digging into the problem. He noticed that there were a few clients that added a lot to the costs and not as much to the revenue. By dropping the costs from these clients, this problem would be fixed. Without the need for expensive engineering. And much quicker. This was allowed him to gain lots of promotions.
The highlights
This story will cover the following ideas
Sometimes you have to cut the Gordian Knot. Software Engineering can often be about untangling a large set of problems. Sometimes engineers have to come up with intricate solutions to untangle the threads. Other times, you want to cut right through. Featuring a story about Alexander the Great.
Engineering is good. Engineering in the context of economic solutions is much better. Instead of approaching things as a pure engineering problem (which would have been hard), this engineer tried to fix the economic aspect (make the solution more sustainable). This was much better.
Broaden your horizons. The solution that our beautiful rockstar came up with is one of the major examples of Pareto Principle (80-20 rule). Every software developer serious about their career has to read a lot. Or expose themselves to different ideas. Being able to code is cool. Making the correct decisions is much more important.
This is not a post you want to miss. Let’s get funky.
[FREE SUBS]To buy access to this post, use any of the following links. The price is 3 USD. Once you send the payment, message me on IG, LinkedIn, Twitter, or by Email:
Venmo: https://account.venmo.com/u/FNU-Devansh
Paypal: paypal.me/ISeeThings
Or you can sign up for a Free Trial Below. Get 2 weeks FREE at no risk to you.
Alexander the Great and the Gordion Knot
I would like to start this post with one of my favorite historical stories. This story is the peak example of changing your battles to come out the war.
Back when Alexander The Great started his war against the extremely mighty Persian Empire, many people thought he was insane. The Persians were a powerful empire, and Macedonia was a comparative nobody.
Thanks to early victories, Alexander arrived at the town Gordium. There lay the famous Gordian Knot, a tangled mess of rope. Legend had it, that anyone to untie the rope would rule the world. Keep in mind, that the Greeks were huge believers in this stuff. Thus it was very important to get untie this.
Alexander struggled with this for a sec. The more time he spent, the more uneasy his soldiers (and he himself) would become. In the end, Alexander declared that the legend didn’t state that the knot had to be untied in a particular way. So he drew his sword, and cut the knot, untying the thing in the process.
Why am I telling you this? Software Engineering is very similar. Real world problems don’t come with an instruction booklet. However, our minds are experts at going into autopilot and attempting what they’ve always done. This is efficient when the problem is similar to others we’re familiar with. However, when it comes to new problems, this can be a detriment. Chances are you will be stuck in the same old kinds of thinking. The assumptions and constraints that helped you get to the problem, will stop you from solving it.
So how can we make sure that we don’t fall into this trap? Let’s cover that next.
Take a breath, Drink Water, and Zoom Out
When presented with a problem that we think we know, it is tempting to jump right in. However, sometimes it can be useful to take a step back and look the problem and solutions in the context within which they will be applied. Most people approached the cost reduction problem as a problem of pure engineering. However, our rockstar took a step back. He saw that whatever engineering solution would be built, would ultimately have to be used by clients. Client usage was ultimately what determined profits and costs. Tackling that would also lead to a high ROI solution.
Zooming out will allow you to look at your system as a whole. You will become cognisant of your assumptions, and how different things fit together. You will become exponentially better at solving problems once you start developing this skill.
Zooming out is important. However, if you don’t have the knowledge to know what you’re looking at, zooming out won’t help you much. That is where the next step will be a game-changer.
Read Read and Read some more
Bad software engineers don’t read at all. Good engineers read lots of technical stuff (blogs, talks, papers, and books). Phenomenal engineers read all of this but also learn how about more “soft” skills (communication, learning, organization) or more “liberal arts” (economics, history, sociology, etc.). Remember, whatever code we build, we build for people (either directly or indirectly). If nobody can use what you build, it is worthless. Learning how to build solutions that add a lot of value and working with others to create your solutions are crucial skills for you to get to the top. Ignore these at your own peril.
Most of the advances in tech have had inspiration from other fields. Boolean algebra was inspired from Chinese philosophy. Machine Learning has taken a lot of inspiration from Biology. Much of Computer Science comes from Math. The examples are endless.
So how can you develop your foundations? The first step is to figure out what you’re interested in. Then start reading up more on such topics. It doesn’t have to come just from big books. Movies, Podcasts, Audio Books, Lectures, and Talks are some of the many of the ways that you can learn about topics you’re interested in.
Believe it or not, this process doesn’t have to be boring. For example, I am a huge fan of manga/anime. The stories often express rather interesting philosophical themes about nature vs nurture, the ideal ways for societies/groups to run, and deliberations on economics, power, and responsibility. If you’re a beginner to these subjects, these will provide a great entry point.
And ofcourse, this make sure you check in with the newsletter. I will cover the most important aspects to allow you to build a foudation that will help you level up your career, sharpen your theoretical knowledge, and ace them interviews. :))
Make sure you share your thoughts on this question/any interesting questions/developments in the comments or through my links. If you liked this post, make sure you tap that heart button and let the world know.
Reach out to me on:
Instagram: https://www.instagram.com/iseethings404/
Message me on Twitter: https://twitter.com/Machine01776819
My LinkedIn: https://www.linkedin.com/in/devansh-devansh-516004168/
My content:
Read my articles: https://rb.gy/zn1aiu
My YouTube: https://rb.gy/88iwdd
Get a free stock on Robinhood. No risk to you, so not using the link is losing free money: https://join.robinhood.com/fnud75