This is exactly what I've been doing. I'm trying to make it an every day ritual, time permitting of course. My main approach for this is to create a long term

This is exactly what I've been doing. I'm trying to make it an every day ritual, time permitting of course. My main approach for this is to create a long term goal for a relatively small unit of untracked work. For example I've identified that our common folder for our front end code is not broken up into logical units. So every day I try to hop in there and simply reorg the folder structure. While I reorg I'm exposed to the files, what they do and whether or not they are actually being used as well as how they're being used. This is enough to learn about what other people are doing/have done and helps me to identify other refactor goals as well as architectural goals. Another idea that I've found if you're on a longer release cycle is a post release mental hook. Once the team has deployed the latest bits, I try to hop into main and rip out or refactor code that may be more sensitive. This gives your more risky changes a much longer time to get eyes on them before the next deploy.