We fired our top talent. Best decision we ever made

I've seen both sides of this table. We had one Rick where i worked, above average coder, very bad ego. When one team had been working on a module for weeks, Rick would review it, declare it as crap (loudly), throw all of it out and rewrite the whole thing in in a day and it would genuinely be better than the original. This was a huge waste of time for both the team and Rick. He would give himself veto to break backwards compatibility in public APIs and was against all forms of automated testing for this reason, this allowed him to produce a lot of code quickly on the expense of everyone else. Management considered him genius which made his ego even bigger, he worked over time often and produced the majority of all code, whenever something was not working he would blame modules not produced by him and management would believe it even though that was usually not the case. End result: working morale was shit and almost all other developers including myself left.

I've also been close to becoming one myself, one of few with whole stack server setup on desk and all, being able to answer questions from team members in a few minutes which would take them hours or days to investigate they love coming to me for questions and during planning they say i'm the only one who can solve certain tasks. To avoid becoming a bottleneck and to give me time to work on my own tasks i just say i don't have time and let them solve their own problems, this makes the whole team more independent and happy and everybody is able to debug their own code.

As others have already noted, management allowing it to go as far as it did in the article is the original source of the problem.

There's a cautionary tale here for developers. If you're productive, hard-working and have enough grit to complete projects, you'll get noticed and handed even more responsibility.

Eventually it will be more than any single developer could handle and you'll burn out.

Often, if you bring it up with management they'll do very little to fix the problem. Projects that could be completed in a few days when delegated to other teammates will somehow languish for weeks, at which point you get roped in anyway to hit the deadline, except now you have to do it ASAP and you're working nights and weekends.

At the end of a project like that mgmt will consider it a success, since the project was completed, and the whole thing will happen all over again.

The only thing they'll actually notice is failure. But who wants to let something fail?

So keep your head low. Get a sense for how long it takes others to complete projects, and aim to be in the same ballpark. To get management to make rational scheduling decisions you need to control what they see.

Which for this type of engineer is going to be really hard. Management should be better at this, but in general they're not, so it's either constrain your productivity or be successful for a year or two till you're overworked out of a job.

It's hard to recognize a bubble if you are in the middle of it. Not impossible, but it's much easier to do from outside. That's why I think every software company needs a good manager, who is able to detect situations like this early, no matter how small the company is.

on the contrary, many good developers do know what to write. They understand what the software does, and why, and they are capable of explaining it. They know what decisions were made, and why they were chosen over other options. Above all, they know where the tricky bits are (because they solved them), which are, for the most part, going to be the tricky bits for anyone following.

Anything you talk to the rubber ducky about probably deserves writing down.

Firstly, I don't see this guy being scapegoated - he appears to have been given the option of being part of the solution, but refused, and he appears to have worked himself into a corner by refusing to work with anyone.

More generally, while I don't know any more about this case than what is in the article, I have seen something matching the description given here, and the situation there was not as you describe, except in that the fault lay both in the developer and his managers.

He thought he was an exceptional developer and he was going to prove it by writing really complex code, even if the application did not need it (he did not, of course, describe it as complex - it was, in his mind, elegant, object-oriented (it was a time when that was still the one true way), efficient, reusable... but in reality, it was mostly a mixture of unnecessarily complex and confused.)

Naturally, he was averse to working with morons who could not immediately follow what he was doing, so he worked alone, obsessively, and incessantly. As time went by, more of his explanations for why some feature could not be made available now were based on the complexity he had introduced earlier in the process.

Management takes the blame for allowing this situation to develop. His initial managers were insecure about their technical ability, and deferred to his judgement - it was a case study in why technical managers need technical knowledge (to be fair, they were also snowed by a load of non-technical responsibilities that sucked up the time for running the project.)

In the end, he precipitated the issue by resigning (presumably, he had found some other manager impressed by his apparent mastery of all things technical.) By then, I had moved on and I don't know it ended up.