3 ms·

The energetic stupid programmer is the single most destructive thing you can have on your team and in your codebase. They make messes for everyone else, and a

The energetic stupid programmer is the single most destructive thing you can have on your team and in your codebase. They make messes for everyone else, and a dummy writing bad code can produce more volume than even the best coder writing good code. Eventually, guardrails and processes get put in place to protect against their damage, and the whole team slows down. Good coders walk, and you're left with the dummies, cranking out a high volume of low quality code. It's absolutely tragic. When you build a flexible high-performance templatized system, hand it off, and realize a few weeks later that an energetic stupid coder has "written" more than 50 copied and pasted hard-coded classes from that codebase for the different places it was called from, only to have him and the non-coding manager push hard for sticking with that approach because the work is "nearly done", that's when you brush off the resumé and walk. Teams need workaday coders sometimes, and every coder should know how to just grind out a big refactor or massive change. However, I aim for coders who are lazy enough to find a cleaner way to do it and smart enough to know they can.

yarg 6y ago
But who reflects those values at company wide scales?
paulie_a 6y ago
The codebase is probably not that good to begin with and quite frankly doesnt need to be I think programmers have a chip on their shoulder about the importance of the work they do. You are not painting the sistine chapel Most programming is what you refer to as "workaday"
- chaboud 6y ago
  When you’re trying to scale teams of thousands of programmers, the dynamics of sloppy ones leaving traps and cruft in the codebase become the things you care about. At least, it’s the stuff I care about now. Much of what we do is mundane, and, if we do it right, more of what we do should feel mundane because the right abstractions and metaphors already worked their way into the tools and systems we use. However, I still contend (and I’m far from the only one to hold to this) that the worst thing you can have on your team is someone with a lot of energy but poor judgement/awareness. Doing it well is hard. Doing it poorly is far easier, to the point that there are folks that will be a team net negative.
- poisonborz 6y ago
  > You are not painting the sistine chapel This is very uninspiring and destructive thinking. Just think of detailed and pristine handworks of everyday tools found at excavations, or the charters of guilds in the middle ages. It's not about what you do. It's about you doing it.
  - paulie_a 6y ago
    > this is very uninspiring and destructive thinking Good! The code most people write are not things that will last the ages. the romantic notion of guilds in the middle ages is silly and what I was referring to regarding the chip
    - poisonborz 6y ago
      It was referring to coding as being the same as any craft. You are being hired to do a job, you don't know how long your code lives and needs to be maintained. "The buyer is a lady, I will not make the effort to make that hammer last long, how often will she use it" is not someone I'd do business with.
      - paulie_a 6y ago
        My point is do your job well of course but dont pretend the output is something more than it is At the end of the day, it's a paycheck for something you hopefully enjoy. And no matter how well crafted you think it is. Someone else is going to come along in the future and think its crap Again going back to the chip on the shoulder
        chaboud 6y ago
        Somewhere there is a line between pragmatic and negligently flippant. There are reasons to care about code quality beyond a chip on one's shoulder. Scalable, extensible, and readible systems retain optionality and can provide substantial business upsides that were unknown (and often unknowable) at creation. Conversely, analysis paralysis can prevent progress. It's a balance. Organizationally, energetic stupid programmers (those who fail to see around corners and fail to carry the lessons of these principles with them in their work but still have high "output"), left unchecked, will drain organizations of talent. We work hard to avoid this heavy delivery bias on our teams because the metrics-focused race to the bottom is a very tough thing to undo. Quality is much easier to keep than to add.

yarg 6y ago

But who reflects those values at company wide scales?

paulie_a 6y ago

The codebase is probably not that good to begin with and quite frankly doesnt need to be I think programmers have a chip on their shoulder about the importance of the work they do. You are not painting the sistine chapel Most programming is what you refer to as "workaday"

chaboud 6y ago
When you’re trying to scale teams of thousands of programmers, the dynamics of sloppy ones leaving traps and cruft in the codebase become the things you care about. At least, it’s the stuff I care about now. Much of what we do is mundane, and, if we do it right, more of what we do should feel mundane because the right abstractions and metaphors already worked their way into the tools and systems we use. However, I still contend (and I’m far from the only one to hold to this) that the worst thing you can have on your team is someone with a lot of energy but poor judgement/awareness. Doing it well is hard. Doing it poorly is far easier, to the point that there are folks that will be a team net negative.
poisonborz 6y ago
> You are not painting the sistine chapel This is very uninspiring and destructive thinking. Just think of detailed and pristine handworks of everyday tools found at excavations, or the charters of guilds in the middle ages. It's not about what you do. It's about you doing it.
- paulie_a 6y ago
  > this is very uninspiring and destructive thinking Good! The code most people write are not things that will last the ages. the romantic notion of guilds in the middle ages is silly and what I was referring to regarding the chip
  - poisonborz 6y ago
    It was referring to coding as being the same as any craft. You are being hired to do a job, you don't know how long your code lives and needs to be maintained. "The buyer is a lady, I will not make the effort to make that hammer last long, how often will she use it" is not someone I'd do business with.
    - paulie_a 6y ago
      My point is do your job well of course but dont pretend the output is something more than it is At the end of the day, it's a paycheck for something you hopefully enjoy. And no matter how well crafted you think it is. Someone else is going to come along in the future and think its crap Again going back to the chip on the shoulder
      - chaboud 6y ago
        Somewhere there is a line between pragmatic and negligently flippant. There are reasons to care about code quality beyond a chip on one's shoulder. Scalable, extensible, and readible systems retain optionality and can provide substantial business upsides that were unknown (and often unknowable) at creation. Conversely, analysis paralysis can prevent progress. It's a balance. Organizationally, energetic stupid programmers (those who fail to see around corners and fail to carry the lessons of these principles with them in their work but still have high "output"), left unchecked, will drain organizations of talent. We work hard to avoid this heavy delivery bias on our teams because the metrics-focused race to the bottom is a very tough thing to undo. Quality is much easier to keep than to add.