5 ms·

Let me get this straight: Person A, a programmer, who writes easy-to-understand code, but takes a bit more time to finish their tasks Person B, a programmer,

Let me get this straight: Person A, a programmer, who writes easy-to-understand code, but takes a bit more time to finish their tasks Person B, a programmer, who writes dirty code, but takes much less time to finish their tasks The current non-technical manager will see only one part of the picture and promote Person B. Moreover, Person A might get in trouble, and pressure to “compromise on quality.” Within a short-term, it is understandable. Within a long-term, this is a disaster scenario! So should the “code quality” be part of a performance portfolio of the developer when it gets to promotion time? And how do we get there?

monocasa 8y ago
I've also seen Programmer A writes straightforward code that's easy to change and understand. Programmer B writes convoluted "clever" code that completely falls apart when requirements change, or even just in production because their clever solution didn't account for all of the edge cases. Now Programmer B has to save the day consistently, and therefore is seen as the person saving the company, when the problems were all of Programmer B's construction to begin with.
- zenogais 8y ago
  ^ This is pretty much standard at any startup in my experience.
- linuxftw 8y ago
  I would expand upon this and say that Progammer B doesn't ship the code at all, it wouldn't pass code review muster. Unless we're talking about a seriously silo'ed org, or Programmer B is actually "Team B"
  - waterlink 8y ago
    Yeah, that is probably a few first months of a start-up (or even first year).
  - monocasa 8y ago
    A lot of teams are a cult of personality around one developer. Particularly if there are a bunch of juniors on the rest of the team, Programmer B can usually get anything through code review with the 'ol "of course it's complicated, that's why _I_ am the one working on it. It's not for mortals to understand".
    - hinkley 8y ago
      Treat every question about your code as feedback. If multiple people ask the same question you have a problem that needs to be fixed. Documenting the gotcha should be your last resort. Implying incompetence isn’t even in the board.
- waterlink 8y ago
  This is not just bad. It is also unfair.
- hinkley 8y ago
  If you are a CTO and you haven’t had the “no more heroes” conversation with your employees, then it is my long reasoned opinion that you are being negligent. I can’t trust “leadership” like that. And if you don’t take “I can’t trust you” as the highest insult a developer can give, then you are in the wrong line of work.
phyller 8y ago
You have multiple engineers working with each other on the same code base, reviewing each other's code before it can be merged into the main branch. Then you start to find which engineers the other ones don't like to work with.

monocasa 8y ago

I've also seen Programmer A writes straightforward code that's easy to change and understand. Programmer B writes convoluted "clever" code that completely falls apart when requirements change, or even just in production because their clever solution didn't account for all of the edge cases. Now Programmer B has to save the day consistently, and therefore is seen as the person saving the company, when the problems were all of Programmer B's construction to begin with.

zenogais 8y ago
^ This is pretty much standard at any startup in my experience.
linuxftw 8y ago
I would expand upon this and say that Progammer B doesn't ship the code at all, it wouldn't pass code review muster. Unless we're talking about a seriously silo'ed org, or Programmer B is actually "Team B"
- waterlink 8y ago
  Yeah, that is probably a few first months of a start-up (or even first year).
- monocasa 8y ago
  A lot of teams are a cult of personality around one developer. Particularly if there are a bunch of juniors on the rest of the team, Programmer B can usually get anything through code review with the 'ol "of course it's complicated, that's why _I_ am the one working on it. It's not for mortals to understand".
  - hinkley 8y ago
    Treat every question about your code as feedback. If multiple people ask the same question you have a problem that needs to be fixed. Documenting the gotcha should be your last resort. Implying incompetence isn’t even in the board.
waterlink 8y ago
This is not just bad. It is also unfair.
hinkley 8y ago
If you are a CTO and you haven’t had the “no more heroes” conversation with your employees, then it is my long reasoned opinion that you are being negligent. I can’t trust “leadership” like that. And if you don’t take “I can’t trust you” as the highest insult a developer can give, then you are in the wrong line of work.

phyller 8y ago

You have multiple engineers working with each other on the same code base, reviewing each other's code before it can be merged into the main branch. Then you start to find which engineers the other ones don't like to work with.