This is a genuine question for developers out there. When you encounter code written by another team member and there are no inline comments or proper docs explaining it, do you find yourself looking through previous commits, pull request discussions, or using git blame to understand the context?
I’m wondering if this approach actually gives you the answers you need or if you still end up making educated guesses about what the original author intended.
Also thinking about whether having improved tools to show the thinking process behind code modifications would actually make our workflow more efficient.
Wanted to see how often other people run into this same situation.
I actually spend quite a bit of time digging through version control history, probably more than I should. The issue I run into is that you often have to go back several commits to find the original implementation, then trace forward through various refactors to understand how it evolved. What I’ve found helpful is using git log with the -p flag to see the actual code changes alongside the commit messages. Even when commit messages are vague, seeing the diff can reveal patterns about what the developer was trying to accomplish. The real challenge comes when the code has been moved between files or heavily refactored - then the trail gets much harder to follow and you end up investing significant time for minimal insight.
honestly git blame is my go-to when im confused about some weird code logic. doesnt always help tho since commit messages are usually garbage like “fix bug” or “update function”. sometimes the PR comments have better context but half the time those are just “lgtm” responses. still better than nothing i guess
Version control archaeology has become part of my regular workflow, though I approach it differently than just diving straight into git blame. I typically start by checking if there are any related tickets or issue numbers referenced in recent commits around that code area. The key insight I’ve gained is that understanding the business context behind the change is often more valuable than just seeing the technical implementation details. When commit messages fail me, I look for patterns in the timing of changes - were multiple files touched simultaneously, were there follow-up fixes shortly after the initial commit. Sometimes reaching out directly to the original author is faster than spending hours reconstructing their thought process, especially for complex business logic where the reasoning might not be obvious from the code changes alone.