Hacker News Reader

Comment by crdoconnor | Hacker News Reader

>I dove into the source code. Rick was right: no-one could possibly understand what Rick had created. Except for Rick. It was a reflection of the workings of his own mind. Some of it was very clever, a lot of it was copy-pasta, it was all very idiosyncratic, and it was not at all documented.

That blog post is embarrassing.

They fired an average to poor performer who somehow managed to convince them he was some sort of genius until it became evident that he was not.

Either that guy was not their top talent (in which case why did they call him that?) or their other developers are even worse, which is terrifying.

View on HN

He was their top talent, because he did knew more then others in the beginning and had more merit in the beginning. He became untouchable, so any disagreeing collegue got blamed and any criticism of got ignored. It became his way or no way, so everyone else became passive.

He ended overworked, but the root problem is not in his tech skills. It was in his social skills, in the inability to cooperate leading to doing it all alone and in the way management enabled all that due to his past performance.

IMO that was a massive management fail. They had a great workhorse doing miracles for them, the guy ended up surrounded by lazy/complacent/incompetent colleagues that just wanted to have good time, he was evidently on the verge of burnout for over a year and then finally fired and blamed for all that was evil in the company. The replacement team of mediocre employees created a very dumbed down version of what they were aiming for and management called it a success. The author of that post should be ashamed of himself they let it go that far due to their complete incompetence. Now reading that HN readers take it as a recipe for their own companies... Oh well.

The author mentions that they fired his management before they fired him.

To me that post seemed like an exercise in shifting the blame. The author should have fired himself.

The author was new to project.

Negotiating/clarifying requirements is seniors job. Delivering working software instead of something that never seem to be finished and has still bugs is superior leadership.

Management aimed at 6 months project. Which got longer due to bugs and mismanaged analysis. Saying that they aimed for something complicated is untrue. They wanted 6 month project and were happy with delivered smaller scope.

For that matter, spending a lot of nights in work should not beat "having superior actual results". He did not had results by the end. And he is adult. Managing your own overwork, especially when you have strong negotiation power, is part of what you are expected to do. He failed at that, he was not ready to work independently.

Your comment sounds like very willful misreading of original article. There is nothing to suggest that other collegues very lazy or complacent or stupid - zero.

Yes, I agree he should have communicated better and likely his own pride got in the way of suggesting he is overworked. However, management should have never allowed so much strain on a single employee; if one works nights for so long, likely they must have seen his health deteriorating and all kinds of warning signals. That's simply mismanagement at its finest. Ask some top athlete to run marathons every week and see what a shell of a person they become, even if they do that voluntarily. They should have sent him to 2 weeks retreat on Seychelles instead, even forcefully.

I inferred lower competence of colleagues from the project they delivered with, as you say, smaller scope. There was also an insightful comment on that article from somebody describing point of view of high performers surrounded by mediocre developers, how they purposefully isolate themselves from dysfunctional teams in order to deliver something and not having their motivation destroyed by complacent teams comprised of people that stopped evolving the moment they got their graduate degrees.

As for your next comment, thanks for spotting the author was a "new guy", I confused him with somebody from upper management in that company that was there from the start.

You inferred lower skill from them being able to manage scope and from finishing the project within alotated time.

Literally.

Project planned originally for 6 months took 2 years and still was not delivered and that is somehow proof of superior ability. Much wow.

Simple fact is that Ricks approach failed and people he considered less then him succeeded - through they still have to be coupled with someone assertive enough to be manager.

Last note: a lot of pointless overtime in this industy is result of celebrating Ricks and calling teams able to manage work schedule lesser. So people.instead of trying to learn how to manage scope and expectations look down on those who are capable to do it.

> less then him succeeded

They didn't succeed; they finished a significantly reduced project, likely for management to finally show some results to investors. If you were ever writing some complex project, there are things you might not have anticipated that need a lot of care to be resolved, which is why making estimates is so difficult in creative industries.

Let's have a different take: imagine "Rick" was working on proper distributed transaction support in e.g. inter-banking communication from the scratch, as that was what business needed. He underestimated the complexity in the beginning, finding more and more corner cases that would reduce high availability that was crucial for the product. This led him to work days and nights in order to solve every single issue that appeared, if he wanted to be honest to himself, his conscience, and not sell a fraud as his final product. Unfortunately, he didn't see anyone in his team capable of actually helping him share the burden. He could have probably done a PhD thesis with the amount of work it required.

Now, investors/management after plenty broken deadlines for this overly optimistic project decided to fire Rick and move on with the rest of the team. In order to ship anything, they decided to remove transactions completely, making it a simple CRUD app, that cannot be used for financially critical tasks and was appealing to a much smaller market (imagine small banks vs large multinationals). This app was what the team delivered quickly. They finally could show the results to their investors, and were supper happy and proud of their achievement. As some investors still had a bad taste in their mouth from broken promises, management decided to blame/shame Rick publicly to identify proper scapegoat.

Rick is now burned out, soon to be homeless, trying to recover from the 2 insane years, and likely out of doing any great work for the foreseeable future, if not forever. Moreover, his name is now blacklisted, because everybody in the industry took the side of management/investors and will never hire him.

Have you even read article? Customer was happy with smaller scope and it was agreed upon in advance! The original project got large also due to change requests and conflicting requerements, these got managed this time.

I did worked on complex projects and estimations, negotiation and communication about delays is more important there, not less. So is ability to work with people you don't like or consider lesser.

Given that the same team was able to produce smaller scope project, it is pretty sure they were able to do at least some parts of original project.

The rest frankly reads like fanfiction. As heroic as decision to spend nights in work and do it alone was, it was not rational decision.

Obviously I was using a hyperbole, amplifying some angles, to get my point across as I thought that in your replies there was a lot of one sidedness. Frankly, I have seen many companies normalizing mediocrity and chasing away their best developers, or even blaming them for their own shortcomings, instead of fully utilizing what they could offer them, which IMO is a tragedy. So instead of just agreeing to what most replies alluded to, i.e. the Rick was a mediocre, uncommunicative and disorganized asshole with a heroic complex, I offered an alternate point of view that maybe the bigger problem was on the other side, for the sake of balanced view.

>the root problem is not in his tech skills.

It doesn't seem to me like there was a root problem. There were several. The primary problems being that he was a bad developer, an asshole and non-cooperative.

He wrote idiosyncratic bad code, copy pasta and documented nothing - that wasn't about him being an asshole - that's a lack of basic tech skills. Those are actually the things that led to the company not being able to deliver. I know plenty of perfectly nice junior developers who have done the same thing and if unchecked it causes the same problems they experienced.

It doesn't say it, but it's strongly implied that it wasn't just others that had a problem understanding and maintaining his code because of his poor skills - he likely inadvertently made it difficult for himself too.

I hear you, but those failing happen to pretty much everyone who overworks himself too much and don't have feedback. You loose sigh of it, because your brain get it. And you are tired and sleep deprived. Everyone makes mess occasionally and we should not judge people by their worst performance. (Meaning here that he produced both bad and good code).

When he did get initial good reputation, he was able to solve problems, he was able to help etc. I think that we should not expect perfection of him nor we need to convince ourselves that he was completely incapable.

He was unable to estimate how much time will maintenance of everything take and from there on, he could not win.

Reply on news.ycombinator.com