Lately, I had a conversation with an iOS developer who wants to change to the gaming industry and asked me how I switched my tech stack from iOS to backend and my experience. Today, I will talk about the tech stack change, its effects on your career, advantages and disadvantages you will get.
|Gaining technical breadth||Losing technical depth|
|New and transferred skills||Low-skill evaluation|
|Higher compensation in long-term||Lower compensation in short-term|
|Fresh perspective||Short-term stress|
|Always having a backdoor|
On top of these, there is a key difference between switching and sticking to a tech stack that is neither an advantage nor a disadvantage:
If you stay in one tech stack, your career progress toward more of a tech lead; if you switch, you progress towards more of an architect or manager.
How these pros/cons play out will differ for specific tech stacks and companies. But these are the most common ones that encompass various tech stack changes.
Let's dive into the advantages and disadvantages.
Technical Breadth vs. Technical Depth
I wrote about the difference in a previous Mektup, and I'm not going to go into details here. When switching tech stack, technical depth (expertise in one area) loses its strength. The moment you stop working in one tech stack, the knowledge gap starts to build. On the other hand, when you switch to another stack, you can still follow trends and novel features in your previous tech stack. Switching tech stack helps to build technical breadth (broad area of knowledge). While gaining new skills, you can stay up-to-date with your previous ones.
New and transferred skills
When you switch tech stacks, it's not like you lose all your knowledge in one day. You may stop using specific knowledge daily but transfer most of what you have learned. The fundamentals of software engineering and business are transferrable. Although how you work in a team might differ, soft skills and work processes are also often similar—or at least adaptable.
When you change your tech stack, you broaden your horizon. Working on one stack keeps you on track for tech lead-like roles where your expertise in one topic is needed the most and the enormous impact you can have.
When you have worked on multiple stacks, you progress towards architect-like roles where your technical breadth is more appreciated and expected. I wrote on a previous Mektup and talked on my podcast about expectations from software architects; check them out for more details.
When we think about managerial roles, it's up to the company's expectations. There are companies where managers are experts in one topic, and also there are companies where managers are expected to have more technical breadth than depth. So, both tracks can end up in management roles.
Impact on Compensation
Let's address the elephant in the room—money. The company in which you're changing the stack will play a critical role here. If you're joining a big company like Amazon, your leveling will be lower than your expertise if you're changing tech stack by joining Amazon. I had a friend who got lower level because they joined a team that was not working in their expertise area.
On the other hand, if you're staying in the same company, you may negotiate. I had a friend who did the change and did not have an impact on the compensation. The possible scenario is you won't get any raise for another year, and if you're up for promotion, changing the tech stack will probably delay it.
Long- vs. Short-term impact
When switching tech stack, you're making a move for your long-term career. It gives you new perspectives that will broaden your horizon in the long run. Yet, in the short term, it causes stress. In the short term, you must put extra effort into catching up and becoming proficient in the new tech stack. Simply put, you will become a newbie again. Some folks don't like this feeling, but I love it. Feeling stupid and learning something I didn't know amazes me and drives me to put in extra effort in the short term.
Can you go back? And if you go back, how will it be perceived?
In my first attempt to switch to a new tech stack, I worked on the backend after working on iOS. Six months later, I returned to iOS by changing companies. Although I didn't enjoy my initial backend experience, it gave me a new perspective and made me a better developer. I improved not only my technical skills but also my communication and empathy skills toward backend engineers. Working with backend folks became much easier, and everyone was happier.
So, returning is the option you will always have, and people will perceive you as a better engineer when you return. In case you have a chance to work on a different tech stack, I highly recommend giving it a try.
Updates from The Last Weeks
A new article is out:
I started reading Designing Data-Driven Applications. My notes from the first two chapters are out. More of them are coming soon.