We fired our top talent. Best decision we ever made
freecodecamp.org
freecodecamp.org
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.
Management failed the company and Rick. The article author clearly failed to see that and focused entirely on the wrong root cause.
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.
Now, what would the management do? How do you make him work with the team?
When Rick feels betrayed and is belligerent because they are taking basically everything he is away from him (at this point this is his work).
So what could they have done? easy! They could have stopped rick from getting this far by actually managing him, having people actually look at his work and make sure he was actually collaborating with others. Rick would likely be a better and less stressed worker.
You can't maintain a SaaS application this way though. The issue isn't management or Ricks; it's the lousy business infrastructure that's privatized science and technology in the United States and kept the Ricks from doing their natural work so that 90 untalented people can have jobs in the software industry.
The oxymorony is that the growth that we create from letting the normie douchebags have their salaries and cargo shorts actually is a net win for society from a macroscopic perspective. It's a societal con but it's a con that keeps families fed; and there can't be, "Ricks" without, "stable societies." Also worth considering!
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".
Rick was not a good programmer with a bad personality. He was a bad programmer with a bad personality.
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.
I am writing that, because once I was maintaining code after similar Rick. In the code were lot of "dumb errors" which turned out to be undocumented edge cases and thanks to those "dumb errors" code performed much better than competitors code. So I would take with a massive grain of a salt an evaluation of a code by a person who took over the code of such Rick when this person also had antipathy towards said Rick.
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)
This is going to get worse before it gets better.
This also may be an argument for splitting up teams and services with micro services.
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...
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.
In hindsight it's very easy to make a determination but hindsight 20/20, you're always second guessing if removing this person is going to help your project or totally doom your project.
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.
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.
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.
Right?
Right?
Hm.
This is clearly a failure of management, who they fired but the focus of the story is wrong.
Rick started as a talented and helpful engineer until he was mismanaged and burned out and twisted into a monster.
It’s not an uncommon sight in tech so let’s focus on the real source of the problem. Management isn’t there just to make sure the product ships on time. They need to build, manage, and take care of a team. The culture and mental health of the team matters a lot. Otherwise even the best people end up like “Rick”.
https://news.ycombinator.com/item?id=32222683 https://news.ycombinator.com/item?id=32219776 https://news.ycombinator.com/item?id=32213825 https://news.ycombinator.com/item?id=32202751
More examples on page 2:
https://news.ycombinator.com/item?id=32213468 https://news.ycombinator.com/item?id=32217511 https://news.ycombinator.com/item?id=32210438
Typically when someone notes the article year in a comment — which happens all the time — the year is added to the title of the submission, either by the submitter or a HN moderator (who are the only ones with the ability to edit the title), without complaint. These complaints here are really out of line.
So I am mystified by your comments. On the first page of Hacker News right now are seven submissions with a year at the end. It is standard practice to tag a submission with the year if it isn't this year. This is regardless of relevance. If it is on Hacker News, it is assumed to be relevant in some way. Else why would someone post it? If someone posted an article from 1888, they must think it relevant in some way.
Putting the year at the end has absolutely zero bearing on whether we think it is relevant. To me it is just another piece of metadata, like tagging videos, PDFs, polls, etc.