Redefining Career Growth: Why Job Hopping Isn't Always the Answer

I’ve been working for the same client since 2015. 8 years at the same company is way longer than the 2–3 years that you stay in one place while job hopping. Let’s analyze the possibilities we have as developers in our careers.

What is job hopping?

Job hopping is the practice of changing your workplace as often as possible, without looking suspicious on your CV. So, you get a job, learn technologies that the company uses and the internal process, and the product they build, and then you start searching for a new job.

Advantages for employees

Job hopping is often recommended to devs as a way of making sure your compensation is up to the market rate. When you look for a job, you’ll naturally pay a lot of attention to the job market. If you are lucky, you’ll get offers from different companies and make them pitch against each other.

Another advantage is expanding your professional network: when you change companies or even teams, you can meet new people who work in the industry. If they have a good experience working with you, they can be a valuable connection later on in your career.

Value of a long tenure

Staying a long time working on the same project is more productive. It can take a few months to get onboarded on a new project, and during this time you need a lot of oversight—or you make a lot of mistakes. Staying long-term is an especially good match for companies that maintain and develop their own products. The projects are never-ending, and they always need someone around to make sure the necessary changes can be made to the code.

Similarly, even companies that deal with shorter projects benefit from developers staying a long time. With time, you get experience with the technology stack that the company uses, and you can be very productive when some of the projects you built are reopened for updates or maintenance.

Institutional knowledge

By staying at the same company, you contribute to its institutional knowledge. You remember the past discussions and reasoning behind all the decisions that shaped the current state of the code and the infrastructure. The same goes for emergencies and fixes. Something that would take hours for a new person can be just fifteen minutes for you if you remember similar problems from the past.

Deep understanding

In time, you develop a better understanding of everything related to your job. You understand the product and how it’s helping the customers. Maybe you met some customers and over the course of that relationship, you developed a better picture of the users of the application. You get to know the terminology of the industry in which the product is working, and there is less that has to be explained to you as you start building new features.

Knowing the code

After 8 years in one place, I have an advantage over any other developer: I know a lot about our codebase because I wrote a big part of it. In our repository, I’m the author of more than half of the commits, and at least half of the rest went through a thorough review with me. This knowledge is something specific to the project I work on—were I to change jobs, neither I nor my employer will get any use from it.

Sharing the value of long tenure fairly

So, we have seen the advantages of job hopping for the employees and the value the long tenure has for the companies. Creating a lot of value for the company could be a common goal for both parties—after all, if the pie becomes bigger, there should be more for everybody. To make it work in the long term, both parties need to find a way to share this value fairly so that the employee will not leave.

Salary negotiation

Job hopping feels a bit like a workaround for a lack of well-prepared salary negotiation. From the employee's perspective, negotiating your salary is stressful:

• plenty of things depend on it
• it can feel closely related to your self-esteem (am I worth the salary I’m asking for?)
• at best, we do it every few years

At the same time, for the company representatives:

• they do it often: every time when somebody asks for a raise or applies to the company

• the stakes are low—it’s not personal and in most cases, they don’t spend their money

• they know the market well—they know how much people at the company make, and what salaries new people ask for or accept

  
  

This means that you need to prepare well. My go-to recommendation for that is resources from fearless salary negotiation. It’s a good, actionable guide that helped me a lot.

Baseline salary

The company you work for knows exactly how much you earn—or for how little you accepted working for them. But there is no reason for your new salary to stay within some relation to your current salary—especially if you were severely underpaid for a long time. Getting a 50% pay raise is not generous if after it you are still below the market.

The only reasonable baseline salary is how much people with your experience are paid on the market. You will need to do some basic research to make sure your information is up-to-date: what is paid now for your current skill set. You most likely learned something new since you started your job, and the market changed as well.

Best alternatives

While preparing for the negotiations, it’s good to analyze the best alternative to a negotiated agreement for both you and your employer. For the company, not reaching a deal with you can mean:

• having to find someone new for the market value and without your company-specific experience

• spending months on searching for and onboarding a new employee

• if they use a recruitment firm, they will have to pay the fee for people they hire—it can be a few months worth of the new person’s salary

  
  

For you, the alternative can be as easy as getting back to the original idea of looking for a new job. In that case, you already have some market research done, and you have your negotiation skills refreshed.

Reduced hours

Another possibility to find common ground with your employer is to negotiate working fewer hours, for the same pay. When you ask for a significantly better salary, you will very likely get either a straight no, or some version of “we would love to pay you better, but we have no budget for it”. Working fewer hours is a perfect solution for getting a better rate for you, and not affecting the company budget too much. Because you already know the project well, in the short to mid-term, you will always be more productive than a possible replacement that would join full-time. And based on my experience, freeing a few hours or a whole day every week makes more of a difference to the quality of life than money.

When to leave a company

We’ve spent a lot of time thinking about how to stay with the same company. Not all companies are worth the effort.

Let’s see a few good reasons to leave:

• bad atmosphere—a company that not only takes your time and energy but hurts your mental health as well
• inflexible negotiation—a company willing to keep all the surplus of your experience for itself, while using guilt or loyalty to trick you into working for less than fair compensation
• getting a much better offer in another place, especially from companies with stronger foundations