4 ms·
I have been thinking about problem (1) off and on for the last year. The best strategy I've come up with so far is to set up a ritual that I will end the day wi
by brown-dragon 10y ago
I have been thinking about problem (1) off and on for the last year. The best strategy I've come up with so far is to set up a ritual that I will end the day with 10-30 minutes of code cleanup. Being systematic about it helps me get acquainted with a lot of the code while clearing technical debt.
- _virtu 10y agoThis 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.
- brown-dragon 10y agoI love the "post-release" mental hook strategy. I'll try it out :-)