3 ms·

I feel like I post a link to this comment [1] every time the abstraction vs. DRY topic comes up, but it’s just such good advice. I consciously try to remember i

I feel like I post a link to this comment [1] every time the abstraction vs. DRY topic comes up, but it’s just such good advice. I consciously try to remember it whenever I’m programming. > Dependencies (coupling) is an important concern to address, but it's only 1 of 4 criteria that I consider and it's not the most important one. I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code. > The reason I put stateless code as the highest priority is it's the easiest to reason about. Stateless logic functions the same whether run normally, in parallel or distributed. It's the easiest to test, since it requires very little setup code. And it's the easiest to scale up, since you just run another copy of it. Once you introduce state, your life gets significantly harder. > I think the reason that novice programmers optimize around code reduction is that it's the easiest of the 4 to spot. The other 3 are much more subtle and subjective and so will require greater experience to spot. But learning those priorities, in that order, has made me a significantly better developer. Dan Abramov also has a good talk about this [2]. [1] https://news.ycombinator.com/item?id=11042400 https://news.ycombinator.com/item?id=11042400 [2] https://overreacted.io/the-wet-codebase/ https://overreacted.io/the-wet-codebase/

nmfisher 6y ago
That’s a really insightful comment, and also the reason why I think my code quality improved considerably after learning Clojure and F#. I discovered that immutability in functional programming made it far easier to reason about state - something goes in, and you know exactly what comes out. No verbose checking logic, no bugs because something wasn’t set that should have been. I’d personally switch coupling and complexity (though it really depends on your definition of the latter). Coupling is usually much less of a problem than you expect it to be, and is easier to identify/rectify in retrospect.
- jakelazaroff 6y ago
  Well, there's certainly a lot of overlap in the Venn diagram of coupling and complexity! The really insidious thing about coupling is that it can transcend module barriers — you can make changes that cause problems in places that seem to be entirely unrelated. Whereas e.g. cyclomatic complexity can be tough to tease apart, but it's at least limited to a single module that you can work on in isolation.

nmfisher 6y ago

That’s a really insightful comment, and also the reason why I think my code quality improved considerably after learning Clojure and F#. I discovered that immutability in functional programming made it far easier to reason about state - something goes in, and you know exactly what comes out. No verbose checking logic, no bugs because something wasn’t set that should have been. I’d personally switch coupling and complexity (though it really depends on your definition of the latter). Coupling is usually much less of a problem than you expect it to be, and is easier to identify/rectify in retrospect.

jakelazaroff 6y ago
Well, there's certainly a lot of overlap in the Venn diagram of coupling and complexity! The really insidious thing about coupling is that it can transcend module barriers — you can make changes that cause problems in places that seem to be entirely unrelated. Whereas e.g. cyclomatic complexity can be tough to tease apart, but it's at least limited to a single module that you can work on in isolation.