3 ms·
I've experienced this first-hand in a Rails app, last week in fact. The result was a messy, hard-to-understand hierarchy of classes and abstractions--just becau
by ahallock 4y ago
I've experienced this first-hand in a Rails app, last week in fact. The result was a messy, hard-to-understand hierarchy of classes and abstractions--just because two workflows shared some similarities. Usually I find this happening with hardcore OO programmers or bored programmers who feel the need to start creating and don't know when to stop. I prefer boring code at this stage in my career.
- ParetoOptimal 4y ago> just because two workflows shared some similarities. Usually I find this happening with hardcore OO programmers or bored programmers who feel the need to start creating and don't know when to stop. I prefer boring code at this stage in my career. As a Haskeller, when I do this it's about getting certain guarantees about the semantics of related workflows and knowing they must behave the same in X, Y, and Z. This aids in reasoning about inevitable production issues. I find boring code easy to modify but hard to reason about from a higher level and that it typically requires nastier solutions to maintain backwards compatibility. That last point is contradicted by this posts example though, so it has me reflecting on things.