6 ms·

Responding to your last two paragraphs... James's suggestions about ignoring code form, DRY, etc resonate with me because I'm someone who is usually inclined t

Responding to your last two paragraphs... James's suggestions about ignoring code form, DRY, etc resonate with me because I'm someone who is usually inclined to spend too much time on those things. I consciously try to reduce the effort I put into those things and instead focus on trying to get the code to actually do something!

damon_c 10y ago
There is a good place, somewhere in the middle.
- pacaro 10y ago
  Always, but with regards to writing clean code, it pays to just learn how to do this upfront. An analogy is of cooking. I used to be a very messy cook, the food is just as good, but when I was done the kitchen looked like a bomb had hit it. Cleaning becomes intimidating at that point. Learning to be cleaner in my processes didn't change the end result for the food, but made the rest of the evening much more pleasant. Professional cooks and chefs learn to optimize this, they are neat and clean where this is most efficient, and offload cleanup to a plongeur where necessary. Secondly I believe that with practice, DRY can become second nature. Back in the mid 90s I wrote a lot of COM code in straight C (for reasons). This ends up being extremely verbose, so repetition carried a sufficient penalty that I learned to avoid it, to carry a sufficient mental model of the code base to know when I could avoid repetition. [edit] plonjeur -> plongeur
  - couchand 10y ago
    I love your use of the cooking metaphor here. Are you expanding on Uncle Bob's discussion of it in The Clean Coder or was that just a coincidence? If I remember correctly, he uses it there to describe the difference between delivering quickly once (and making a mess in the kitchen) and reliably producing over the long term (by taking a little extra time to clean as you go). Adding the spin about the learning process really (forgive me) sweetens it.
    - pacaro 10y ago
      I'm thinking more of the "You cannot be Mommy!" scene from the movie Ratatouille
couchand 10y ago
Thanks for providing your perspective here, I'd guess that he has a similar mentality, which is why he wrote that. In my (admittedly anecdotal) experience, devs who tend to overemphasize formatting and DRY are already self-aware about it, whereas those who give it far too little care and attention regularly shoot themselves in the foot by overlooking simple mistakes that get camouflaged in poor formatting and excessive repetition. My concern is mostly that the latter group would see this article as evidence that they can safely ignore code review comments and such.
- _petronius 10y ago
  I think this is a really good point. I am probably far too guilty of overemphasizing formatting etc., but by the same token, have seem the chaos that a lack of care in that department can cause, especially on big projects. Coming back to a big pile of code that someone else wrote, which is difficult to read or make sense of, six months after the fact to do maitenance is, like, top three things that make my professional life difficult. Formatting, DRY, and good code organization don't solve business problems, but they do make solving those problems (and keeping them solved) a lot easier.
BurningFrog 10y ago
The time to clean up the code is when it already does what it should. That is: Make it pretty and readable and DRY once the code works. Until then my code can have several ugly and improvised things I've left for later.
- smp_ 10y ago
  That's ok assuming that time ever comes; pressure to deliver new features or just the possibility that you move on and it stops being your code and becomes someone elses means you may never get a chance to look at those ugly things. I think there's a middle ground that takes that kind of uncertainty into account and is pragmatically wary of 'ugly' and 'improvised'
- fauigerzigerk 10y ago
  >The time to clean up the code is when it already does what it should. I'm a bit skeptical of that as a general principle. I want code to be a consistent representation of my mental model of the solution at all times. I use code to help me think, remind me of my thinking and communicate with others. It's not just a series of commands that make a machine do something. As long as any ugliness is not in conflict with this purpose it's fine. I can totally live with functions that are a bit messy and probably need cleaning up later.
  - tshannon 10y ago
    Yep, I agree. I see it more as a list of priorities, not necessarily sequential steps. 1) Make it work 2) Make it maintainable 3) Make it fast All three should be on your mind when developing something, but if you have to choose between 2 and 1, go with 1.
    - AstralStorm 10y ago
      And you end up with the 60+ year old TODO this way. Or lack proper reason comments (the why) and end up in a gaggle of legacy code. My rule is simpler: never write instant legacy code. If it feels like something you won't understand a month later, it likely is legacy code. If it reads badly (and I'm not talking about this or that brace or whitespace choice), then it also provably is in that category.

damon_c 10y ago

There is a good place, somewhere in the middle.

pacaro 10y ago
Always, but with regards to writing clean code, it pays to just learn how to do this upfront. An analogy is of cooking. I used to be a very messy cook, the food is just as good, but when I was done the kitchen looked like a bomb had hit it. Cleaning becomes intimidating at that point. Learning to be cleaner in my processes didn't change the end result for the food, but made the rest of the evening much more pleasant. Professional cooks and chefs learn to optimize this, they are neat and clean where this is most efficient, and offload cleanup to a plongeur where necessary. Secondly I believe that with practice, DRY can become second nature. Back in the mid 90s I wrote a lot of COM code in straight C (for reasons). This ends up being extremely verbose, so repetition carried a sufficient penalty that I learned to avoid it, to carry a sufficient mental model of the code base to know when I could avoid repetition. [edit] plonjeur -> plongeur
- couchand 10y ago
  I love your use of the cooking metaphor here. Are you expanding on Uncle Bob's discussion of it in The Clean Coder or was that just a coincidence? If I remember correctly, he uses it there to describe the difference between delivering quickly once (and making a mess in the kitchen) and reliably producing over the long term (by taking a little extra time to clean as you go). Adding the spin about the learning process really (forgive me) sweetens it.
  - pacaro 10y ago
    I'm thinking more of the "You cannot be Mommy!" scene from the movie Ratatouille

couchand 10y ago

Thanks for providing your perspective here, I'd guess that he has a similar mentality, which is why he wrote that. In my (admittedly anecdotal) experience, devs who tend to overemphasize formatting and DRY are already self-aware about it, whereas those who give it far too little care and attention regularly shoot themselves in the foot by overlooking simple mistakes that get camouflaged in poor formatting and excessive repetition. My concern is mostly that the latter group would see this article as evidence that they can safely ignore code review comments and such.

_petronius 10y ago
I think this is a really good point. I am probably far too guilty of overemphasizing formatting etc., but by the same token, have seem the chaos that a lack of care in that department can cause, especially on big projects. Coming back to a big pile of code that someone else wrote, which is difficult to read or make sense of, six months after the fact to do maitenance is, like, top three things that make my professional life difficult. Formatting, DRY, and good code organization don't solve business problems, but they do make solving those problems (and keeping them solved) a lot easier.

BurningFrog 10y ago

The time to clean up the code is when it already does what it should. That is: Make it pretty and readable and DRY once the code works. Until then my code can have several ugly and improvised things I've left for later.

smp_ 10y ago
That's ok assuming that time ever comes; pressure to deliver new features or just the possibility that you move on and it stops being your code and becomes someone elses means you may never get a chance to look at those ugly things. I think there's a middle ground that takes that kind of uncertainty into account and is pragmatically wary of 'ugly' and 'improvised'
fauigerzigerk 10y ago
>The time to clean up the code is when it already does what it should. I'm a bit skeptical of that as a general principle. I want code to be a consistent representation of my mental model of the solution at all times. I use code to help me think, remind me of my thinking and communicate with others. It's not just a series of commands that make a machine do something. As long as any ugliness is not in conflict with this purpose it's fine. I can totally live with functions that are a bit messy and probably need cleaning up later.
- tshannon 10y ago
  Yep, I agree. I see it more as a list of priorities, not necessarily sequential steps. 1) Make it work 2) Make it maintainable 3) Make it fast All three should be on your mind when developing something, but if you have to choose between 2 and 1, go with 1.
  - AstralStorm 10y ago
    And you end up with the 60+ year old TODO this way. Or lack proper reason comments (the why) and end up in a gaggle of legacy code. My rule is simpler: never write instant legacy code. If it feels like something you won't understand a month later, it likely is legacy code. If it reads badly (and I'm not talking about this or that brace or whitespace choice), then it also provably is in that category.