It's a bit strange that this sort of job-hopping isn't a red flag to employers. You'd think managers would be reluctant to hire an employee who has jumped ship many times before, just as they were becoming useful.
Someone who job hopped five times in ten years has convinced five different employers to give them a significant pay raise to poach them. Someone with one job in ten years is likely in the "I'm just lucky to be employed" category and is less of a hotshot.
In my experience, good candidates ramp up very quickly (<1 month) and having them on board for 2 years is plenty of time.
Making bigger changes takes longer; taking leadership on a new top-level feature without breaking other parts of the app or distorting the architecture isn't going to happen in a few months for a codebase of any real size. The question is: is a developer who ramps up quickly going to be able to do that eventually?
I work at a wholesale insurance company (middleman); we have over a hundred individual systems, some simple, some quite complex. Some of those systems can be maintained by any programmer that comes in. Others really shouldn't be maintained by someone who doesn't have good experience in writing maintainable code.
But many projects require domain-specific knowledge---and not just to specific parts of and companies within the insurance industry, but _our specific company_.
For a few years, we hired less experienced candidates with the hope of training them, because the talent in Buffalo NY is hard to come by (which could also be an outreach problem, but our last three hires were from out of state). Our team's consensus is that it takes approximately two years of experience with our systems to have a good, balanced grasp on them. Because of the small team size (five at our highest, two right now), we place great value on team members who have been around long enough to know the systems, the rationale and design decisions, history, etc.
This relates directly to Peter Naur's concept of Theory Building.[0]
We've had the past four candidates leave in ~2, <2, <1, and ~3 years. Because of the upfront training cost and distraction from the more experienced programmers (the two that remain at the company today), and in some cases the degree of maintenance problems ("technical debt") introduced, I consider three of them to be a wash: we're no better off having hired them than we would have been not hiring them. Possibly worse off.
Because we have the tendency to lose employees at around two years, I'm no longer in favor of hiring more "junior" candidates---having to train in both domain knowledge _and_ general programming is too risky and hasn't panned out well. So hopefully we can hire programmers that can immediately get into the code from a general programming perspective, but it's going to take them quite some time to really understand what the systems are all about.
I've been there for over eight years, and the last programmer that remains with me has been there for six months longer than me. One of our programmers transitioned to technical director, and has been there for over ten years. My supervisor dropped programming for project management responsibilities, and he has been at the company for nearly ten. Our sysadmin has been there for over ten. We just lost an employee that was there over ten years. We're a close group. Would I be making more money job hopping? Probably, yes. My point here is that the company I work for---the team I work with---values experience with the company, and so long-term employment history is attractive.
What I maybe _should_ have said is that I may have been able to make more money more quickly if I job hopped. There's an unfortunate disconnect between a development team that understands value (and is responsible for all hiring decisions) and a non-technical upper management. I'm fortunate to have a supervisor that fights on my behalf, and I'm pretty aggressive in pushing it myself.
It's very easy to say you value experience, but if you wont allocate resources towards employees with experience then your company is signalling that they don't actually value it.
The other programmers didn't leave for more money, though.
It sounds like you have far too few developers to cover those systems. My company is similar, although with much fewer individual systems. The biggest problem we have is that we expect developers to be familiar with all of them and it's simply too much ground to cover, especially when you add in decades of technical debt. I've been there over a year now and picked up almost no domain-specific knowledge because the cognitive load of all the projects and their intricacies and the constantly switching between them is just to high to learn anything in detail.
The second you aren't working on something your knowledge begins to fade. If I have to pick up something I haven't touched in three months then it's pretty close to being a new product to me.
We definitely do. Unfortunately, it's difficult to hire in our area.
We've settled into our specialties, but that gives a terrible bus factor---the more senior the employee, the more the company suffers if they get hit by a bus. And goes back to the concept of theory building. We do what we can to try to mitigate certain aspects.
> The second you aren't working on something your knowledge begins to fade. If I have to pick up something I haven't touched in three months then it's pretty close to being a new product to me.
Yes---it's very useful to have people who have been there long enough to jog eachothers' memory. There are some core projects that are touched frequently enough to stay mostly fresh in our mind. It's always fun to look back 5--10 years and think about the history of the projects, or joke about the hardships. That's where the real knowledge lies.
So, you're saying that you get paid a lot more than you would make at other companies, and so do your other team members? That's what placing a high value on your knowledge would look like to me.
Most employees don't want to change jobs if they can help it and employers use that "static friction" to pay them less than market.
However, I don't think it's a good fit, both from mine and the company's perspective - do I stick it out to ensure my resume doesn't have a half life, or would a next employer understand it was something I had to jump to, but was in everyone's best interests not to drag it out? (we're talking <5 months)
If it takes that long for a employee to become useful then the company has much bigger issues and the need to compensate for whatever it is that makes those 2 years of experience so vital.
He has been there for around 10 years. The fact that he has stayed on for 10 years while mistrusting people who have worked for him for the same time doesn't make sense. But neither does it for managers who have nice offices to promote open office arrangements for their workers. Hypocrites are everywhere.
based on my unpublished anecdata
Much more important are skills, experience, and team fit.