I just stick to the rule of three: if I see the same pattern three times I consider the abstraction I’m missing. This surprisingly leads to “future proof” code

I just stick to the rule of three: if I see the same pattern three times I consider the abstraction I’m missing. This surprisingly leads to “future proof” code. I didn’t anticipate the needs of the business. I just wrote what needed writing. Yet over time I build the abstractions in that the code is actually using. I say surprising because code written this way looks obtuse and... messy. You get very senior and very confused developers asking you why you didn’t apply The Singleton Factory Pattern or use the XYZ architecture. So you say, because I didn’t need it and they just don’t get it. But that’s part of the reason why I like Haskell so much these days. And why I liked Python for so many years. I like languages that bake in good ideas and abstractions for you. Python baked in the iterator pattern, the decorator pattern, etc so that you could use them in the language with little ceremony. Haskell bakes in the most powerful abstractions of all: type theory and algebra. And still the idea of only writing the code you need to solve the problem; nothing more or less; stands up. People may look at you like you’ve lost your marbles. But if you can get them to stick around in the codebase for a year or two they’ll start to see it too.