I’m sorry but this isn’t a problem with “Rick”. This was first and foremost a management problem. Yes I know they fired the management too but the focus of the article is still on everything that’s wrong with Rick but you can see how management failed him. He was first a great employee who helped others but over time he was given more and more responsibility until he became a single source of failure and didn’t have time to help. They place everything on his shoulders and even encouraged it by giving him a production server spec workstation and not reining in his bad tendencies or corner cutting, which he might have been forced to do given the time pressure.<p>This is a scenario that’s all too familiar where management hires a great talent and then just uses that person to solve all their problems instead of actually managing and building a team that can handle the problems.<p>Management failed the company and Rick. The article author clearly failed to see that and focused entirely on the wrong root cause.<p>A much better story would be to tell it with a focus on management who was either too incompetent, too lazy, or both to properly build, manage, and grow/mentor a team.
The headline uses the words "top" and "talent" in unconventional ways.<p>When the writer examined Rick's code, it is revealed as messy, buggy, and long-winded --- "a lot of copy pasta", laden with "thousands of hours of technical debt", "bells and whistles", and speculative programming for requirements needed in "five years".<p>Rick was not a good programmer with a bad personality. He was a bad programmer with a bad personality.<p>More specifically it sounds like Narcissistic Personality Disorder, with certain telltale signs like gaslighting, the inability to accept fault, and dependency injection of the self into the lives of everyone else. The writer says, "I don’t believe Rick started out this way." I think he's wrong. Narcissistic Personality Disorder starts in childhood. So Rick was like this when he entered the business. In fact it is probably how he became "universally recognized on the team as the top talent" --- not because he was, but because he bullied his way up to that with his own self-aggrandizement, and his coworkers were too timid or inept to suggest that he was never actually a good programmer.
This is, "why all the elves have left Middle Earth;" The software industry is just about the only industry where a basically smart person can work and end up making as much as a doctor or lawyer. This results in power law/pareto distributions of talent. Due to the fact that 80-90% of the workforce is technically incompetent from a, "went to school and learned vetted skills and disciplined critical thinking" perspective you end up with a kind of paradox where-in innovation is stifled through toxic democratization. Creative genius doesn't manifest, "good employees." Sorry.<p>Consider that he might be right from his perspective; he's probably just a douchebag. Either/or (remembering dear Kirkegaard and saintly James) this is partially and mostly why computers suck in 2022, Google doesn't work anymore, and user interface design is suffering as there aren't enough people with cross-sectional culture skills (consider Brenda Laurel: PhD in Theatre; Alan Kay was a competent jazz guitarist before Xerox PARC) + necessary computing expertise to design useable software and as a result our technical infrastructure has suffered immensely despite gains made from Moore's Law and data collection (I'm looking at you ML geeks)<p>This is going to get worse before it gets better.
Arguably the organization was not well managed. You don’t have one person make design decisions or push code without review. The organization surely lacked proper process. However, this is probably all too common.<p>This also may be an argument for splitting up teams and services with micro services.
This says more about the company. Keeping the bus factor high is company management 101. Employee training and development is a fundamental part of it.
This seems to be a side effect of the environment.
From my experience, if you do your task well, you get more.
If you do that additional workload well, you get even more.
You start to be the guy for everything...<p>You can say he got himself into that position by acting like that, but I think the environment shaped him to become this way. It's easy to say he should have looked for a different company the first time he had to work overtime...
Enablement is also a problem. Each time the group had a chance to intervene, they didn't.<p>Not to say Rick isn't at fault, he is, 100%, but he was clearly in an environment that want healthy for his mental health or productivity.
I've encountered a few Ricks. The dirty little secret is, they aren't actually as good as they think they are. Have you ever looked at a solo developer project? It'll be full of strange code that matches the mind of the solo developer. THAT's what's happening here. One you let a Rick go, they'll fuck up the codebase, rewriting everything into their own style and pushing everyone else out (because who wants to work on Rick's weird code?). When other developers try to become involved, the Rick will effortlessly jump through layers of abstraction (which Rick wrote) and help them solve the problem. It would take them 10x as long to solve it on their own. Oops - shouldn't have let Rick loose to begin with!<p>It isn't a matter of stacking more Ricks. Ricks don't like working with Ricks. That'll lead to high drama and one or more Ricks flaming out in a blaze of glory. Each Rick has their own code style, why would they work with someone else's code? If multiple people are all claiming that "The existing design is terrible, let me rewrite it", while the person who made the existing design is still there, and is a Rick, then you'll just have a codebase being torn in multiple directions.<p>Yes, poor management enables this. If you know how to handle these people, you can surround each Rick with non-Ricks and force them to document their code, and justify every rewrite, etc. Like a nuclear reactor surrounded by graphite. But ideally you want to turn a Rick into a non-Rick. Usually that involves taking them down a notch. Maybe you can set up a John Henry vs the Machine style situation. Have the Rick try to out-code a team of non-Ricks. The Rick can't compete, despite writing 10x as much code. It's almost like layers of abstraction aren't a universal benefit. Huh.
I've never had the misfortune to work with somebody like that, or indeed let myself become like that, but I've seen this in open source projects.<p>One got forked after years of misery, another eventually became obsolete technology-wise. They were genuinely instructive as an example of how not to behave.
I've also been working half of my career in 1-person silos. The freedom was great but the stress lead to more than one burnout and said belligerence. Luckily not that extreme but it obviously took me a while to realize how much better it is to work in actual teams that are managed and where responsibility and knowledge are shared. At 2 workplaces I had to own everything from Desktop IT over actual development to product. There's much to hate about Agile and Scrum but I think the mentioned work mode is becoming a thing of the past.