As director of engineering, I gladly gave generous raises to retain people, because it cost way more in lost productivity to read resumes, interview candidates, and onboard new devs, not to mention the $30k check you have to write to the recruiter. And you're right, one bad hire can be disastrous...apparently the guy that replaced me wanted to prove his value by rewriting the whole architecture. So they spent a whole year doing that which I'm sure is much cleaner than the original under the hood, but to the end user, it is not apparent.
> apparently the guy that replaced me wanted to prove his value by rewriting the whole architecture. So they spent a whole year doing that which I'm sure is much cleaner than the original under the hood, but to the end user, it is not apparent
Anecdote: We had a guy show up, he claimed that we had to do a rewrite. We spent 2 years catching up to the base product. Complete waste of time, had to fire him 1 year into the rewrite. Gained no value from it. He was simply too arrogant, vain, and/or unskilled to bother to read other people's code.
What position did he come in as? Seems awfully odd to have a new-hire making such a decision. From the sounds of it, he effectively tied up resources for almost a year before being pushed out?
There are two problems there, from what I can ascertain:
1. The guy wanting to rewrite your product.
2. Management that allowed him to do so without proper motivation and/or cost-benefit analysis.
I was a noob at the time and had assumed he was a minimum of 1 year experience better than me and really knew what he was talking about. He used great business terms and convinced the non-techies, too. In retrospect, it's a very obvious mistake. He convinced us the open source project that we based our business on for the 6 months before hiring him had limitations, but it turns out that the open source project was packed full of features, well polished, well designed, easily extensible, etc. and we spent 2 years catching up to where that product was, just in a different framework.
In 2011 we had to rewrite a backend which was architected by a guy who left after his plan didn't work which was effectively a rewrite of the rewrite. I left the company in 2013 and in 2014 they hired him at my new workplace (we had no contact before and this decision was oblivious for me). I left that company when they put him as team lead on my team and several years later I heard from an ex-colleague that they dumped a backend which was architected by this guy.
Very similar story to mine! :) I was hired together with a guy like this, knew all the fancy keywords and didnt want to touch the old code. We were lucky to refuse him, but it was just by chance. He left the company few months later.
It's always a risk, but it comes with the tiny chance that the new hire will be the guy who designs the next iPod.
From the employer point of view, keeping someone aboard who is willing to jump on every opportunity for leverage is also a risk. You might want to have the fiercest of negotiators in sales, but the same thing is not a trait you want to see in developers. Bad for their earnings, but that's how it is. The most capable developer in the world would not be a someone you want as an employee if you suspect that he could use his powers for extortion tactics. (It's bad enough already that the worst developers become "irreplaceable" without even trying)
The new developer needs to familiarise himself with everything and what happens if he's actually worse than you?
Of course no sane boss will ever tell you this. Just nag them and don't accept "no" for an answer.