Comment by progmetaldev

One of the best things I could do for myself is to go back in time and tell my younger self not to care so much about the "right" design pattern, or the perfectly DRY way to represent a piece of code. I was definitely my worst enemy for a long time, because I thought SOLID and the GoF design patterns were more important than writing code that is easy to understand without hopping across multiple files in case one day in the future your system needed to do something totally different with a new database or filesystem, etc. I started to look for places to add design patterns, rather than letting them develop naturally. Most of the software I built had no need for such heavy abstraction and complexity, and I've only ever had to switch database systems twice ever in 20 years, and the abstraction did not help reduce time or complexity all that much in the end. It definitely wasn't worth the up front planning compared to just rewriting the sections that directly handled the database.

Maybe it's a right of passage to burn yourself badly enough over-architected solutions, where you finally start to understand you don't need all the complexity. Write the code for humans, as simple as you can. Keep large performance issues in mind, but only code around them when they become a problem or are extremely obvious. If anything, it's helped me to steer junior developers away from complex code, while encouraging them to try it out in their own time. Go ahead and figure things out on your own, but let's not do it on a shared codebase, please?