3 ms·

Far worse for the industry than all these supposedly awful programmers out there is the rampant egotism that dominates developer culture, and that's where this

Far worse for the industry than all these supposedly awful programmers out there is the rampant egotism that dominates developer culture, and that's where this ridiculous 10x obsession comes from. As good as some developers can be and as bad as others can be, even the best will routinely make severe mistakes and write bad code. Aspiring to be some sort of god among programmers won't actually make you great, it will just make you arrogant and unable to see your own failings and ignorance, which will always be vast compared to your skills and knowledge. On the other side, it isn't fluffy snowflake talk to say that every human being has his or her areas of strength and exceptional insight. Helping less experienced programmers on a team learn and grow, and figuring out how they can contribute productively without causing problems is likely worth a much bigger bonus than one guru who thinks his shit doesn't stink and talks down to everyone else. According to Zen, the beginner's state of mind is ideal because it is free of preconceptions. Someone who believes the ideas of a novice are beneath him will be blind to a lot of wisdom. As a last aside, every team I've ever worked on that inherits code thinks the code is shit and rewrites it. Then when some other team inherits the rewritten code, they proclaim it shit and rewrite it again. Some percentage of this is due to bad code. Some is because all complex applications which are developed in a hurry in shifting business environments end up pretty hairy. And the rest is because almost all complicated code looks like shit when it's unfamiliar, even if it's fairly well engineered. So you'll throw it out and run into all the same issues on your rewrite and your code will end up just as opaque, but you'll understand it now so you'll think it's brilliant, and then you'll write self-congratulatory blog posts about how great you are and how terrible everyone else is, blissfully oblivious that in 3 months, a new developer will take on the project and rewrite it and write the same exact blog post out of imperious disgust for your work.

fuuuuuuuuuuu 14y ago
The difference only matters at scale. I've met people I think would deliver a quality product in 4-6 months I wouldn't get done in 3 years. (6-9x) When you're talking project arcs that are on the scale of at most a month or two, it hardly matters because most of our time is consumed with meetings about the start, end, check-ins, etc.
pdwetz 14y ago
I agree with a lot of your points; ego is a dangerous thing. However, I think it's important to differentiate between the two major types of rewrites (or claims as to why something should be rewritten): 1) The code is obviously subpar vs. 2) the programmer doesn't understand the code. I've had to deal with code written by 3rd parties where I doubted the person was actually a programmer who wrote it; nonsensical or nonexistent naming conventions, large methods of dubious logic that were often never actually called (anymore?), and a general avoidance of best practices (and I don't mean advanced code; even simple things like code comments along the lines of "this is a for loop"). #2 is a different beast altogether and I think this more applies to your last paragraph. Is the source code too advanced for the programmer reading it, or is the code/architecture too obtuse? Unfortunately, I think it's often primarily programmer laziness more so than the design itself. I've been told by devs they don't understand a system and when asked what they don't understand, they simply shrug their shoulders. If you don't make an attempt to "get" the current system, in no way should you be allowed to rewrite it from scratch. You need to at least learn the mistakes of the current system.
- lukeschlather 14y ago
  Personally I think it's rare that rewriting subpar code is a great idea. Some refactoring is frequently in order, but that's true in general. Even understanding the faults of an existing system, it's a big undertaking to rebuild it and make it better in one go. There is a certain class of code that is not merely subpar but actually can be easily rewritten with 1/10th the code and will be less buggy as a result. We may be talking about the same thing, but if so I think "subpar" is being too polite for code that will actually benefit from a rewrite.
  - pdwetz 14y ago
    Sorry, I could see how my use of subpar might have been a little vague. I meant horrible code that induces physical pain just by reviewing it.
michaelochurch 14y ago
Far worse for the industry than all these supposedly awful programmers out there is the rampant egotism that dominates developer culture, and that's where this ridiculous 10x obsession comes from. In comparison to the psychopathic, dishonest, and often destructive class of narcissistic "executives" who run the mainstream business world, I'd say that the mildly-annoying social mediocrity of "10x developers" is a non-concern. Often, when a software engineer says "this won't work", it's because it actually won't work.

fuuuuuuuuuuu 14y ago

The difference only matters at scale. I've met people I think would deliver a quality product in 4-6 months I wouldn't get done in 3 years. (6-9x) When you're talking project arcs that are on the scale of at most a month or two, it hardly matters because most of our time is consumed with meetings about the start, end, check-ins, etc.

pdwetz 14y ago

I agree with a lot of your points; ego is a dangerous thing. However, I think it's important to differentiate between the two major types of rewrites (or claims as to why something should be rewritten): 1) The code is obviously subpar vs. 2) the programmer doesn't understand the code. I've had to deal with code written by 3rd parties where I doubted the person was actually a programmer who wrote it; nonsensical or nonexistent naming conventions, large methods of dubious logic that were often never actually called (anymore?), and a general avoidance of best practices (and I don't mean advanced code; even simple things like code comments along the lines of "this is a for loop"). #2 is a different beast altogether and I think this more applies to your last paragraph. Is the source code too advanced for the programmer reading it, or is the code/architecture too obtuse? Unfortunately, I think it's often primarily programmer laziness more so than the design itself. I've been told by devs they don't understand a system and when asked what they don't understand, they simply shrug their shoulders. If you don't make an attempt to "get" the current system, in no way should you be allowed to rewrite it from scratch. You need to at least learn the mistakes of the current system.

lukeschlather 14y ago
Personally I think it's rare that rewriting subpar code is a great idea. Some refactoring is frequently in order, but that's true in general. Even understanding the faults of an existing system, it's a big undertaking to rebuild it and make it better in one go. There is a certain class of code that is not merely subpar but actually can be easily rewritten with 1/10th the code and will be less buggy as a result. We may be talking about the same thing, but if so I think "subpar" is being too polite for code that will actually benefit from a rewrite.
- pdwetz 14y ago
  Sorry, I could see how my use of subpar might have been a little vague. I meant horrible code that induces physical pain just by reviewing it.

michaelochurch 14y ago

Far worse for the industry than all these supposedly awful programmers out there is the rampant egotism that dominates developer culture, and that's where this ridiculous 10x obsession comes from. In comparison to the psychopathic, dishonest, and often destructive class of narcissistic "executives" who run the mainstream business world, I'd say that the mildly-annoying social mediocrity of "10x developers" is a non-concern. Often, when a software engineer says "this won't work", it's because it actually won't work.