Job hopping is not considered an admirable trait, at least by employers. There is not much for them to like about a developer that leaves after a short tenure. Hiring people is an expensive process since it requires the expense of recruiters as well as time spent by the existing development team for interviews. Time spent in interviews is time that could be spent building software. This makes a developer with wanderlust extremely costly for a company.

There’s also the issue that developers tend to take a while to become 100% effective at a new company. Software systems are complex and it takes time to learn how a company’s systems work. Depending on the company it can be as short as a couple of months, or it can take a year. A developer who leaves a company soon after gaining that context on a company’s dime will deny that company from getting the full value out of that developer.

That’s from the employer’s perspective. Here’s the developer’s perspective:

Job hopping is advantageous most of the time.

Software development is complex. There are many tools a developer can choose to use for a problem at hand. The more technologies and patterns a developer uses, the more tools they have. That enables them to make better decisions.

Starting a new job is a huge opportunity for learning new things and getting new tools. A developer learns the most while gaining the context in how a company’s systems work. They experience technologies that they may not have experienced at previous companies since every company tends to do something that is different. There is always something a developer doesn’t know, but can learn: be it a new programming language, framework, database technology, cloud provider, etc. More importantly, there is the opportunity to work with other developers who have different experiences and knowledge that can be shared.

Yet most of that learning happens as a developer is just starting out at a new company. The developer will experience a diminishing return on time spent at a company the longer they stay. They could learn more by moving on to another job and repeating the learning process.

The exception to this is the fact that developers need to balance making technical decisions that benefit a company in the long term versus the short term. But there is no magic button for “make this work for the long term.” Sometimes what you think will work in the long term ends up not working as well as you thought. Developers learn to make good long term decisions by seeing the results of their earlier decisions. Getting feedback on whether you are right or wrong about something is essential to making better decisions in the future.

A job hopping developer will never have the opportunity to get the feedback on their long term decisions. They simply aren’t at a company long enough to see how their decisions will play out. All they will ever have to go on is what sounds good on paper. They will lack the experience required to know what will actually work.

Making good long term decisions is one of the most important tools in a developer’s toolbelt. Not having this will severely hinder a developer’s ability to do good work.

So companies clearly benefit from developers sticking around for a while. Developers can benefit both from sticking around and hopping from place to place. Companies can collectively choose not to hire developers with a history of job hopping. However the job market is clearly in favor of developers these days. The laws of supply and demand have made it so that unless that company is Google, Microsoft, Amazon, or any other hot name, a company can’t afford to be picky. A great developer with a history of job hopping is better than no developer or a developer who does negative work.

I’ve had recruiters contact me my first week into a new job asking me if it’s working out. That is how little companies care about job hopping because of how hard it is to hire a developer in this job market.

What needs to happen is that companies should make it just as advantageous for a developer to stick around. That means creating plentiful learning opportunities.

Conferences and meetups sound great, but they are not sufficient. You can get introduced to a lot of new ideas at a conference, but it won’t help very much until you get to put the ideas into practice.

Hackathons and side projects can help sometimes, but those tend to be of limited benefit. A lot of software development is adapting to situations that come up when lots of users are using the application. There’s also the level of motivation involved. “Don’t feel like it” is always an option to avoid working on a particular feature in a side project. It is less of an option for a job.

Unfortunately there are no easy answers to this problem. Every company is in a different situation and that affects what they can afford to do.

A larger company with multiple teams could allow their developers to switch teams every 6-18 months. That will allow the developer to try new things since different teams tend to work with different technologies. It also helps to work with new people that have different experiences to share.

Google made famous “20% time” which allowed developers to spend 20% of their time working on a project that they come up with. This can fall into the same issues as side projects though unless those projects are going to actually have users using them.

A company could allow a new technology to be used for a new project solely for the sake of trying something new. This is a very poor reason to do something from a project management perspective. But it may be worthwhile from a human resource perspective.

Some companies are in complex businesses that requires a wide variety of technical solutions. This complicates the development of their project(s), but it does provide the advantage of giving their developers variety in the work.

In the end, most ways of providing developers with learning opportunities will have a cost to a company. The short term math of letting a developer try something different rather than do what they do well will never work out in favor of letting a developer learn something. Spending time learning will always be an immediate productivity hit. But that cost needs to be balanced against the cost of a developer leaving in order to improve their skills.

I would love to hear from you if you have experienced a company that handled this situation well!