It’s very normal for a developer to worry that they may be staying too long or too short a time at their jobs. The field of software programming is notoriously fast-paced, and when you see others around you hop from one job to another on a less-than-yearly basis, you start wondering if you shouldn’t be doing the same.
But exactly how long is too long or too short a time, when it comes to staying at a software developer job?
While every individual case is different, in this article we will try and find a reasonably precise (and optimal) length of time to answer that question. We will look at some of the pros and cons of changing companies or sticking with them, and at the most important criteria you should keep in mind when making such a decision for yourself.
No, Sticking Around Is Not A Good Idea
Let’s start by explaining the premise. There are two main reasons why you as a developer should be wary of occupying the same position for too long.
The first is that it risks being detrimental to your skill set. You may find yourself always doing the same things, or always working with the same technologies, and as a result you stop learning and bettering yourself professionally.
Making sure that one’s skills are constantly improving should be one of the top priorities for any developer conscientious about their career.
The second reason is that the company you stay with will not spontaneously raise your salary to adapt it to your changing market value. A programmer’s potential asking salary will rise significantly as they add years of experience to their CV, and dramatically in the first few years of their career (the phase in which they transition from junior to senior developer). But if they stay at the same place, they will keep getting the same salary.
Sometimes you can stay where you are and ask for a raise, but often the most efficient way to fatten that payslip is simply to move on to the next place.
You’re Not Looking For The Mean
The answer to the question of how long a developer should stay at any given position cannot be determined as a mean average (i.e. years of experience divided by number of jobs held).
The reason is that in many cases – dare I say most? – the career of a successful developer will look uneven. The first half is most likely to include some very short stints, while the second half will be composed of much longer contracts. In other words, a developer may work for 1 or 2 years at their first 6 companies, then 5 and 7 years at their 7th and 8th.
This is not an aberration, but a reflection of the fact that when a developer goes job-hopping, they should have something like an end game in mind. Paradoxically, the reason you should change frequently is precisely to put yourself in a position where you no longer have to change.
Of course, you should be looking first and foremost for a job that makes you happy and fulfilled – this is priority number one and no other consideration trumps that. But, thinking for a second purely in career terms, your end game should be a company with the following two qualities.
Firstly, they are among the top players in their field, and their salary range is among the highest, meaning that you can’t get a better pay simply by going somewhere else. Secondly, they are large and dynamic enough that there is room to evolve and develop your career within their ranks.
Once you find yourself in a place like that, and as long as you are happy, the average of how many years a developer should stay at a company no longer matters. The end game has been reached, and you can stay there, if you please, as long as a British monarch.
What If My End Game Is Not In Sight?
For developers in the first 10 years or so of their careers, the ideal duration of any given contract is roughly 18 months. And I mean very roughly – 1 year or 2 years can work equally well, depending on the case.
Why specifically that length? Because that’s usually how long it will take for you to learn most (not all, but most) of what you can learn at any given position.
You will complete your training and preparation, go through one yearly evaluation, and eventually become highly competent at your tasks (if you still aren’t, then maybe it’s worth staying a bit longer). This means there won’t be much left for you at that company, and then you can probably move to the next one – and ask for more.
Keeping each job for 18 months generally makes for a good look in your CV. You will have a very healthy-looking 4 positions in 6 years, which demonstrates both variety and consistency.
Imagine, instead, that you kept each job less than a year. Not only is it much less likely that you will learn as much as you could from each position, you will also end up with a CV that shows something like 6 jobs in 4 years, and that’s not great. Recruiters will understandably be hesitant about taking you in if they feel you’ll drop them just as quick.
Naturally, all of the above assumes normal levels of job satisfaction. If you come across an abusive boss, or your position is leading you to burnout, or if you have any other very good reason to leave your company, then the ‘ideal 18 months’ be damned – just get out of there.
Conclusion
Overall, you should look for the job-per-year ratio on your CV to approximate 2:3, allowing for flexibility (so it’s fine to have a job you kept less than six months and one you kept more than 3 years) for about the first 7-10 years of your career as a software developer. Past that, this ratio matters less and less.
My final recommendation, however, would be to keep these figures in mind, but not fuss too much about them.
Yes, a CV that shows both professional variety and reasonable reliability is a plus. At the same time, there are many other things that your CV can and should show, which can easily offset that quality.
If you find a job that keeps you happy and fulfilled, or if you are fortunate enough to find a position at a prestigious company early in your career, then by all means stay where you are for as long as you feel comfortable there. Remember: career serves life, not the other way around.