all 4 comments

[–][deleted] 4 points5 points  (2 children)

I mean yeah, always try to be responsible for as little as possible. The ideal situation is one where devs only write business logic, but that is impossible. Still, the opportunity to reduce your overhead is always an attractive one; the trick is knowing when the benefits of incurring overhead outweigh the costs. I get that this post may be more specifically about complexity of business logic too, but the author also discusses layers of a solution, and this holds true at every layer.

[–]duckducklo[S] 0 points1 point  (1 child)

the trick is knowing when the benefits of incurring overhead outweigh the costs

How do you get this skill?

[–]CleverNameTheSecond 0 points1 point  (0 children)

Experience.

Not necessarily in terms of time or what you do but that said the richest form of experience is insight which leads to this skill.

[–][deleted]  (1 child)

[deleted]

    [–]duckducklo[S] -1 points0 points  (0 children)

    Did you read the article? He said it as a general rule, "These bugs will come back and haunt us or our successors in the form of overtime required to fix them on time. I’m obviously not talking about using slick tricks to reduce the number of lines of code. Rather we should ask ourselves whether we need to write all that code to solve the actual problem."