I use a painting/art metaphor for my practice. Usually when i want to develop a new major function or approach - or adopt a new technology - I do a "sketch". T

I use a painting/art metaphor for my practice. Usually when i want to develop a new major function or approach - or adopt a new technology - I do a "sketch". The sketch is a standalone project that embodies what I want to understand. It could be React with a basic router and a test framework. I'll iterate on that. Sometimes several times. Then I integrate into the projects I'm working on. Usually this is verifiable in some form. Being reliably testable is one. But others could be micro-benchmark performance. Occasionally the aim is just to re-write in a different language. In the future, if I wanted to make a structural change (e.g. a different router) - I'll go back to the sketch and make the change. Sometimes I also do a sketch from scratch. However, I find working on the original sketch informs changing the production code a lot better. In "deliberate practice" terms that's a very macro-level approach, but it's a balance that's worked for me.