Advantages of Job Hopping
It isn't just a raise and a promotion for engineers
My first few professional experiences were at places where people spent decades at the same company. Job hopping was looked down upon for a variety of reasons. The tech sector has changed a lot over the past 20 years. I once told a colleague that I was at my last position for 3 years, which I thought was pretty short. He scoffed and said he had never been anywhere more than 2 years.
Today, it's fairly common knowledge that the best way to "grow" your career is to switch jobs. You could fight and claw for a 5%-10% raise. Or you could leave for a 50%-100% raise with a title bump. Pay and title are measureable benefits of switching jobs. What's less measureable and more important in my opinion is how switching jobs can make you a better engineer. As job hopping is a big topic, I'm going to focus solely on its effect on an engineer's skill set.
Let's get the negative out of the way. I use the singular because I can only think of one. It comes from leaving a job too quickly, say 12 months or less. Part of a software engineer's job is to design systems that work long term. Yet, how does an engineer get the necessary feedback of how their decisions turned out if they aren't around to see and experience the consequences of those decisions? One could talk to people that still work at the old job, but hearing things second hand is not quite the same as experiencing them first hand. The type of decision and system matters quite a bit as well. My tenures have usually been 2-3 years. That was plenty of time to see many decisions play out, but it was not long enough for me to see the result of others. As such, I have some gaps in my knowledge that will likely never be filled.
I also have no regrets when I think of the opportunity costs of needing to stay to have those gaps filled. In exchange for those gaps, I have gained other experiences and other pieces of knowledge. There are several advantages to leaving a job: breadth of technology expertise, situational expertise, and domain expertise.
Let's start with technology expertise. No two companies use the exact same technologies in the exact same way. I once went from a company using AWS to a company with its own data center. Those are two very different experiences. If I had just stayed at the company using AWS, or even just stuck to companies that used cloud, I would have never experienced the pros and cons of running your own data center. It would have forever been a notion of "uhhh that sounds really hard." Even though it is a terrible choice for 99% of companies, I may one day be in a situation where I will have to make that call and it may be at a place in that 1%. Or I could be in that 99% where someone will want to go data center when it isn't appropriate and instead of being armed with fear, I will be armed with arguments.
I could make similar statements about various programming languages, web frameworks, third party vendors, etc. The reality for most companies is that they only need a certain set of technologies to operate. Going beyond that set may be good for engineers learning new things, but impractical and potentially harmful to the business. Building a new feature as a microservice just so someone can play around with Golang or Rust is a lot more overhead than another package in the Java monolith (I can't believe I just wrote that). Even still, a new feature that may or may not see a lot of use is hardly at the same level of an entire system. Learning a new language isn't just about syntax. It includes managing the code base when it gets very large and a lot of people are in it. It includes dealing with issues that you only see at scale or in specialized situations (hello memory leak in Java class loader). Those require not just letting someone work in Rust on a microservice, but converting the whole code base to Rust.
I have heard of numerous instances where companies went through whole language transitions and few of them ended well. It just isn't practical for a business to conduct these types of big sweeping techonology changes unless the current technology is truly abysmal (e.g. Etsy was built entirely in postgres. Not use postgres. Built in postgres with stored procedures).
Switching jobs and going to a place with completely different technology is the only viable way for engineers to get to really learn that technology. This is something I've struggled with this fact. I've been in management for a while and a key part of that job is retention. The other key part of the job is training and I have not been able to reconcile the fact that at a certain point, the best training is to go elsewhere. I often think about resolving this point and come up short.
Big companies have the option of letting people transfer to other divisions. Don't like working in Java at Google? Go to a team using Golang at Google. This brings up a different issue however: situational expertise.
Working at a big company where your job is only at risk when the company is looking to boost profits is very different from working at a company where your job is at risk because the company may run out of money. The incentives are different and that makes your choices different. In the former, you can maybe save your job by trying to impress your boss or their boss. You also have the option of less savory tactics that I won't go into.
In a company about to run out of money, it doesn't matter what your boss thinks. They're going to lose their job too. You need to make choices that help the company make money (or raise money). At bigger companies, you can focus on engineering ideals and keeping code clean. At companies in a cash crunch, you just need to make things happen. Tech debt doesn't matter if you drown in financial debt.
Neither situation is better for you by the way. Being in both just helps you learn what is right for you. Lots of people I know would get stressed out at a company that could run out of cash. I happen to enjoy having a cash constraint and time constraint.
It's not just big company versus small. B2C companies operate differently than B2B. I remember being so used to random scaling spikes at B2C companies that going to a B2B one where traffic matched up with sales deals was really refreshing. Knowing the exact day traffic would spike is a luxury compared to "random thing went viral".
Companies in regulated industries operate differently than companies that are not. Fully remote teams work differently from hybrid or in office teams. VC funded companies operate differently from unfunded ones. Pure software companies operate differently than ones with physical locations or products. You can't truly know what you like or don't like until you go and try it.
A cross between technology and situational expertise is domain expertise. An e-commerce company is going to use a different swathe of technologies and have a different way of interacting with customers than a company selling accounting software to CPAs. The immediate thought that comes to mind is that by sticking to a domain, you can be better at said domain. There's a lot of truth to that. However, there's also a lot of knowledge that's transferable. Some industries get stuck in a way of doing things and having a new perspective can spur innovation. I'm certainly taking everything I learned from e-commerce, education, healthcare, and even gaming into the work I'm doing now in accounting.
The value of new perspective has made me rethink the classic notions of retention. Hiring and onboarding new staff is expensive, but there's value in their new perspective. That new perspective could be the difference between struggling with a problem versus having a solution. That new perspective could raise the skill level of the rest of your engineering team. It's a hard calculation to make, but staff turnover isn't always just a cost.