1. 11
  1. [Comment removed by author]

      1. 5

        If you look over his other blog posts he mentions forcing his team to pull 7-day weeks with 12-hour days FOR EIGHT MONTHS.

        I looked briefly but didn’t find that. Can you point me where you saw that?

        In this article, the author mentions that Rick was working like that. That’s the only 12/7 reference I’ve found, though:

        Rick was churning out code faster than ever. He was working seven-day weeks, twelve hours a day.

        1. 12

          Can you point me where you saw that?

          https://medium.freecodecamp.org/our-team-broke-up-with-instant-legacy-releases-and-you-can-too-d129d7ae96bb :

          It took eight months of seven-day weeks and twelve-hour days to complete our last legacy system overhaul.

          1. 2


      2. 19

        TL;DR - Author brought on by CIO as outside consultant to deflect career ending blame for failed project onto single, unlikable employee, saving multiple layers of incompetent management from same fate. Author appears not to understand this ruse, and is proud to write about his role in it.

        1. 11

          This kind of writing personally disgusts me. I’d like to highlight some of my own thoughts around the four things this manager cites as the “problem”:

          First, he created a cult of dependence. Any problem eventually became a Rick problem, a myth he encouraged. Developers learned to stop trying and just wait for Rick.

          Where did this dependence originate? Were there no senior-enough engineers to help out with this code/system? How were the projects structured around these systems that Rick contributed to? How was the situation handled when other developers just stopped working to wait on just Rick?

          Second, he didn’t write maintainable code. He never documented or tested anything, and so failed in spite of his own intelligence. His belief in his personal infallibility trumped common sense.

          Not maintainable according to whom? Was it just unapproachable to more junior engineers or from other teams? Lack of documentation and testing can certainly make things more difficult, but definitely not an unworkable situation to manage on an individual level. This here sounds ultimately like a failure on the part of management to really exemplify good software engineering practices.

          Third, he was personally destructive. Team members didn’t want to speak up and offer their own ideas because he always berated them for it. Rick only respected Rick and went out of his way to make everyone else feel small.

          This is definitely not a good thing in a professional setting, but to me also sounds like the result of some kind of frustration or resentment, all personal issues aside. Again, likely these things grew over time as the result of a failure in leadership to help exemplify a better way to discuss ideas.

          Fourth, he lacked all personal accountability. No failure was his fault. He sincerely believed this, and it prevented him from learning from his own mistakes.

          So Rick’s mistakes should be his own, but management’s mistakes are also his? Not sure I understand this management mal-practice of blaming him for both any failures at a technical level in addition to his failures in working together with a team.

          I don’t believe Rick started out this way. I saw him at his worst. This was after years of working escalating overtime and facing increasing criticism from customers and colleagues.

          And so after years of management failing to help a talented but renegade programmer to grow into an even more adept software engineer, they chose to fire him. Maybe next time, those so-called “leaders” around him should be better examined for their own ability to set the example and be a role model that talent can look up to.

          1. 4

            I’m a bit surprised at all of the people rushing to defend Rick. Should the situation have never gotten that far? Sure. Does that absolve Rick from being very bad at his job? Not at all. Especially if you read some of the followups (e.g. Why Rick couldn’t come back from the brink), he was afforded ample opportunity to not be an asshole martyr.

            Are we so attached to the solo hero coder idea that we can’t help but defend it even when it’s as toxic as Rick is?

            1. 7

              I wouldn’t call the comments here as defending Rick as much as trying to be more critical of the author, who chose to exemplify his firing of an employee as an example of good management. I mean, it’s in the freaking inflammatory title: “We fired our top talent. Best decision we ever made.” Would you expect that to be the statement of a well-meaning, constantly-reflecting leader?

              1. [Comment from banned user removed]

                1. 1

                  The concept of “solo hero coder” is really attempting to diminish those people as unique individuals and mocking their talents and skills, which suggests jealousy or inferiority

                  Would you prefer 10x/100x coder? Same concept. But I how you immediately jumped to assuming jealousy on my part. That’s a remarkable level of defensiveness.

                  Levy’s book was written over three decades ago, about an industry that had only existed for about three decades before that. It has very little insight into the work of today, where, unless you’re producing disposable code, you need to be able to work with other people to make software.

                  1. 2

                    But I how you immediately jumped to assuming jealousy on my part. That’s a remarkable level of defensiveness.

                    That’s not a fair reading–the concept of “solo hero coder” is very much an archetype being spread and deconstructed in programming and business culture today: you don’t need to infer accusation of jealousy. As @pushcx said, have charity towards other posters.

                    I think @simba was pointing out that (rightly) there is very much an movement to discredit and suppress the “genius solo coder”. Whether that is good or bad is a different matter altogether.

                    1. [Comment from banned user removed]

                      1. 5

                        I’m guessing the last time you read it was also 3 decades ago.

                        Please assume the best of fellow commenters.

                        1. 1

                          I’m guessing the last time you read it was also 3 decades ago.

                          I’ve been in the industry a long time, but not that long. I read it in the mid-90s. My recollection is that the book largely consists of stories of individuals in the 1960s and 1970s creating or hacking impressive things, tied together thematically under the “hacker ethos”. When it was published, many pieces of commercial software (perhaps most, though I don’t know how large the non-microcomputer market was) were still written by one or a small number of programmers.

                          That’s simply no longer the case. The vast majority of commercial software – heck, the vast majority of software that gets distributed at all – is written by a team.

                          But that isn’t the case, many of the most important and useful softwares were written entirely by one person

                          I’m curious to hear your (modern) examples.

                          When a musician is extremely talented, nobody uses phrases like “solo hero musician” to describe them. They just pay them millions of dollars for their work

                          That might not be an accurate portrait of the music industry. Talent does not equate to financial success, nor vice versa. That is even more true in the visual arts. It’s very hard to make a living as an artist, let alone make a fortune.

                          Extremely talented developers deserve the same level of recognition and reward for their contributions.

                          I mean, they do. Bill Gates, Linus Torvalds, John Carmack, Notch, are all examples of programmers who wrote successful software, and are now worth a great deal of money.

                          1. 2

                            I’m curious to hear your (modern) examples.

                            minecraft, redis, Dwarf Fortress, Ethereum, Buckmaster over at Craiglist, Whitney’s K, for a start.

                            1. [Comment from banned user removed]

                              1. [Comment from banned user removed]

                                1. 1

                                  Fabrice Bellard made ffmpeg and qemu (as a modern example).

                    2. 4

                      Code that nobody else can understand is not the mark of a good developer. If people are describing your code as “very clever” then you’ve probably over complicated it.

                      Real genius is being able to create simple solutions to complex problems.

                      1. 9

                        That might be case of different skill sets. Maybe that developer developed some “core functionality” which were really complex, and others were doing UI, auxiliary data processing, etc. Maybe other developers had less experience.

                        For example, almost everyone who has basic understanding of computer graphics will say that Quake source code is clean, simple and easily readable but those who developed only web apps might say that it’s completely unreadable, and it even doesn’t have MVC architecture, classes, comprehensive tests and other “baseline best practices”.