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?
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?
[Comment from banned user removed]
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.
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.
[Comment from banned user removed]
I’m guessing the last time you read it was also 3 decades ago.
Please assume the best of fellow commenters.
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.
I’m curious to hear your (modern) examples.
minecraft, redis, Dwarf Fortress, Ethereum, Buckmaster over at Craiglist, Whitney’s K, for a start.
[Comment from banned user removed]
[Comment from banned user removed]
I think the advice is pretty clear. Stick to something until it is finished, and don’t let your mood dictate your work schedule if you are building something.
You also need to learn to, in the words of a now-famous new-generation Disney princess, “let it go, let it go.”
I’m adding (what will hopefully be) a smooth history-diving workflow to vgit, to help track down when sheet joins were broken in VisiData. If anyone wants to play with an experimental git TUI (or help design), I’d love to get some feedback!