I like your unit test example. I find that when approaching something new, like a codebase, API or framework, the most important thing to do after getting a cu

I like your unit test example. I find that when approaching something new, like a codebase, API or framework, the most important thing to do after getting a cursory lay of the land, is establishing a tight feedback loop for determining if something is functioning/breaking/improving. In the case of refactoring, that's often adding test coverage as in your example. When experimenting with a new technology it's usually building a 'tracer bullet', the smallest e2e working piece of functionality to ensure that your mental model matches with the reality of how it actually works. The tools and processes of a technical org can have a big impact on how easy it is to take this approach. Enabling the engineers in your organization to create tight feedback loops and easily experiment is a huge boost to productivity. Test execution speed, ease of deploying dev instances of services or whole clusters of services, logs that are easy to access and query, distributed traces. At larger companies it can be a huge pain to simply spin up or get access to an instance of a service that you can poke, change, break and throwaway much less a cluster of interacting microservices.