- How to refactor legacy code in a team setting.
- How to prevent more bad code from being written in a team setting.
- How to architect applications at a higher level.
- How to mountain bike like a beast.
- How to prevent more bad code from being written in a team setting.
- How to architect applications at a higher level.
- How to mountain bike like a beast.
Having a document external of your brain helps others to feel like they have a tangible set of goals instead of some arbitrary set of goals that nevon wants to have happen. I made my team's style guides repos on github so it's super easy to edit since it's straight markdown. Keep the pedantic discussions to a minimum. Sometimes it's just best to choose something because it's a single way of doing it.
I feel your pain...
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.