2 ms·

There was a paragraph in that article that made me think of something >”But engineers (like everyone) see the world through their lens. Engineers look at code

by bborud 6y ago

There was a paragraph in that article that made me think of something >”But engineers (like everyone) see the world through their lens. Engineers look at code all day. And when they see two pieces of code doing roughly the same thing, they immediately think about ways they could eliminate the wasted effort by combining them into one piece of code that performs both functions”. I shudder when thinking of all the times I have wasted time trying to generalize something only to end up with code that is harder to understand, awkward to use, more complex, more prone to bugs, or all of the aforementioned, just because there is a stupid voice in my head going “do not repeat yourself”. With maturity comes the insight that not repeating yourself is good. But sometimes avoiding it makes things worse and costs a lot more.

berkes 6y ago
In software there is the distinction between visually DRY and functionally DRY. The latter should be collapsed, but might not be duplicate code at all. Automated code analyzers will often not even see these. And the former must be kept duplicate. Unless you can make it functionally duplicate too. Automated code analyzers will often flag these wrong. Don't get me wrong: I love automated analysis in a CI or my workflow. But it is not binary like a linter: pass or fail. It requires context and interpretation; I see e.g. CodeClimate as suggestions, not laws.
- bborud 6y ago
  I think we talk about slightly different abstraction levels. I wasn't thinking of the things a compiler will tend to optimize. It was more the times when I have tried to do too much with some higher level abstraction and suddenly you find that the abstraction isn't a good fit for everything you need to do inside it and that you may even be writing code that becomes very awkward (hard to understand, "abuses" the abstraction, or just very slow). These things tend to hit in the "oh shit" phase when you have enthusiastically convinced yourself (and your team members) that this is the way to do it, you have written a lot of code where the abstraction still fits and then you stumble upon the cases where it doesn't fit and things get awkward. DRY is a good principle, but duplication of code that does nearly the same thing may have significantly lower cognitive overhead, be easier to maintain and easier to evolve in some cases. (The trick is to silence that little OCD voice in your head when you come across those cases).
1_player 6y ago
> I shudder when thinking of all the times I have wasted time trying to generalize something My programming life has improved for the better when my threshold to generalise and DRY is not when I need to use some piece of code in two different places, but when I need to use it in three different places. I am not joking, that was life changing advice for me.

by bborud 6y ago

berkes 6y ago

In software there is the distinction between visually DRY and functionally DRY. The latter should be collapsed, but might not be duplicate code at all. Automated code analyzers will often not even see these. And the former must be kept duplicate. Unless you can make it functionally duplicate too. Automated code analyzers will often flag these wrong. Don't get me wrong: I love automated analysis in a CI or my workflow. But it is not binary like a linter: pass or fail. It requires context and interpretation; I see e.g. CodeClimate as suggestions, not laws.

bborud 6y ago
I think we talk about slightly different abstraction levels. I wasn't thinking of the things a compiler will tend to optimize. It was more the times when I have tried to do too much with some higher level abstraction and suddenly you find that the abstraction isn't a good fit for everything you need to do inside it and that you may even be writing code that becomes very awkward (hard to understand, "abuses" the abstraction, or just very slow). These things tend to hit in the "oh shit" phase when you have enthusiastically convinced yourself (and your team members) that this is the way to do it, you have written a lot of code where the abstraction still fits and then you stumble upon the cases where it doesn't fit and things get awkward. DRY is a good principle, but duplication of code that does nearly the same thing may have significantly lower cognitive overhead, be easier to maintain and easier to evolve in some cases. (The trick is to silence that little OCD voice in your head when you come across those cases).

1_player 6y ago

> I shudder when thinking of all the times I have wasted time trying to generalize something My programming life has improved for the better when my threshold to generalise and DRY is not when I need to use some piece of code in two different places, but when I need to use it in three different places. I am not joking, that was life changing advice for me.