Agreed, and that had a happier ending where they moved him to a sort of R&D position. I think this article pats itself on the back too much. They didn’t manage “Rick” and let him work 7 days a week 12 hour days, and then act hurt when he explodes. As a former programmer who now manages programmers this whole situation made me angry reading it. This was avoidable.
It's a tough thing because say "Rick" worked on 5 things every day. 3 things he did very well and nailed, and the other 2 things didn't work right. As a team it's very hard to balance those two things against those three things and eventually come to the conclusion that you need to let the guy go.
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.
I'm not saying it's irrelevant. But it's standard practice to put the (YEAR) in the title of HN submissions of older articles. For example: https://news.ycombinator.com/item?id=32211063
It's not snarky. How many times do I have to say that it's standard practice on HN to put the year in the title of article submissions? There are literally 4 examples of this just on the HN front page right now, 2 of them from 2021:
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.
spacemanmatt, you joined Hacker News 9 years ago, and you have a lot of upvotes, which means not only that you have been helpful but that you have been here thousands of times.
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.
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.
This also may be an argument for splitting up teams and services with micro services.
If you read the story, Rick wasn’t always this way. He started out differently and sort of became a monster over time but who’s fault is that? Why did he become the only person who can solve the problems? That should have never been allowed to happen. It’s dangerous for the team and bad for Rick since now all the problems go to him. As much of an ego trip as that might seem, no one wants to be flooded with problems all the time. It will burn you out from the stress and time pressure.
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”.
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.
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’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.
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.
Poor management suffers from the problem on not fixing things if they do not seem broke. They will get Rick to overwork himself into burnout if it helps them.
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 don't. Power Law distributions will create situations where-in the Ricks are doing 90% for the real work when they're not deliberately surrounded by other/better Ricks. This is what made Xerox PARC the most productive computer company of all time; great thinkers playing together with little interference.
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!
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.
The headline uses the words "top" and "talent" in unconventional ways.
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 had to assume "top talent" and "genius" were used ironically because neither applies to the Rick in this post. He has the megalomaniacal cowboy bit down, though.
I would caution against applying a label like "Narcissistic Personality Disorder". That is a clinical term, only applied after diagnosis by a qualified professional. You have not met "Rick", nor had a chance to examine him. I'm assuming you're not a qualified mental health professional either, or you'd know this.
I see it differently. Rick understood the product. He was not bothered about writing code properly, he wanted to get working product out of the doors.
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.
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...
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...
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.
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)
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!
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.
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.
30 comments
[ 2.8 ms ] story [ 70.8 ms ] threadNot 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.
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.
This also may be an argument for splitting up teams and services with micro services.
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”.
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.
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.
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...
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.
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.