To me, a big part of my mental shift was just realizing how much code or process I follow doesn't actually deliver customer value. I want to make things that affect people or improve lives and the longer I spend polishing what I'm making, the less I'm getting feedback.
I used to work in a large company on a team that essentially developed frameworks for other teams to use. I would often think through designs from several different angles and try to create an API that could work in any scenario. After shipping our frameworks, I often found that the "customer" (i.e. the other team) would use what I made in a different way from what I had expected. That meant a lot of the thinking I poured into the project was unnecessary. I really just had to look at that one particular use case and design for that.
After a while I started working backwards and went directly in the customer team's codebase to start integrating potential API designs to ensure it would work for their use case. That saved a ton of guesswork and eliminated a lot of code waste.
So I guess my advice is to question everything you work on and ask if there's a simpler/cheaper way to build just what you need. I usually aim for creating a proof of concept now to ensure that I only build what I need. It often means hacking things to make it work, and then afterwards clean up the hacks, but to be honest, a lot of hacks are good enough, if they are isolated. Also, try to develop a mindset of always aiming to deliver an output to ensure you don't get bogged down with analysis paralysis.