4 ms·

In a wicked way, people who write that kind of code never get credit for it, and often lose leverage of their job. I am not saying that writing convoluted code

• waterlink 8y ago
  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.
• collyw 8y ago
  Yes, good code is a lot harder to spot than bad code.
  • mmt 8y ago
    At the risk of sounding too glib or reductio ad absurdum: The best code is impossible to spot, because it's not even there. Put another way, a truism I've often heard from the most senior programmers (especially in the context of critiques of LOC as a measure of productivity), is that their best work is often writing less code, or outright deleting existing code. It stands to reason that this kind of work is much more difficult to spot if all one looks at is the codebase in its current state.
    • jibal 8y ago
      See "The Most Beautiful Code I Never Wrote" by Jon Bentley.
• hinkley 8y ago
  The real value of that sort of person is in the leadership they can provide and not the mountain of dramatic code that everyone mistakes for brilliance. I would and do advise anyone who possesses that sort of clarity to push for more responsibilities. They should be involved in all of the major problem solving discussions.