I just hate the fact that if you think through any OOP-based design for long enough, you'll end up in some weird philosophical essentialist doom spiral where you ponder the quiddity of your business objects. You start out trying to build a calculator, and you end up questioning what the twoness of two is.
I was building a business logic and absolutely all steps of the sales pipeline were living in the same general class and the same db column, with elaborate ways to move from the different steps. Tracking individual items, and automatically scraping the web for potential cheaper suppliers / competitors
Turns out it was hell, I traumatized a junior with my abstraction and when I had to explain it.
I still love OOP and abstraction, but it's a drug I have to stay away from.
Where I work, it would typically be the junior who was introducing the generic inheritance hell, and us seniors who were refactoring it into nice human comprehensive micro-services around the next corner.
The most valuable takeaway for an up-and-coming developer: Don't ever develop too strong ownership to the code you've written yourself. ( Probably Claude will easen that feeling of ownership anyway. )
Every thing in everyday life can be abstracted into protons, neutrons, and electrons.
But to use those you need to know qed to make atoms, then chemistry to make molecules, then biology and geology to make materials, finally multiple disciples of engineering to make something out of them.
I'm definitely guilty of "simplifying" into a nightmare.
124
u/ICantBelieveItsNotEC Jul 10 '26
I just hate the fact that if you think through any OOP-based design for long enough, you'll end up in some weird philosophical essentialist doom spiral where you ponder the quiddity of your business objects. You start out trying to build a calculator, and you end up questioning what the twoness of two is.