Do you ever feel like the hardest part of working in a codebase isn’t understanding the code… but understanding why it exists at all?
I’ve been trying to figure out if this is a real, shared pain or just something that feels more dramatic in my head than it actually is in day-to-day dev work.
When you’re inside a codebase long enough, reading the code itself is usually not the hardest part. You can follow functions, trace data flow, and eventually understand what something is doing. But what keeps bothering me is something slightly different. It’s the feeling that even if you understand what the system does, you still don’t really understand why it was built that way in the first place.
Like you open a service and it clearly does something important, but you have no idea why that logic wasn’t just added somewhere else. Or you see a strange workaround and you can’t tell if it’s still necessary or if it was solving a problem that doesn’t even exist anymore. Or you look at a dependency and think “there has to be a reason for this,” but there’s nothing in the code that explains it.
And then when you actually try to figure it out, it usually turns into digging through old pull requests, trying to find Slack messages from months or years ago, or asking someone who “might have been around when this was built.” Sometimes you get an answer, but a lot of the time it’s just partial context or nobody really remembers anymore. What feels interesting (or maybe frustrating) is that this layer of “why things exist” seems to disappear over time, especially in larger or older systems. The code survives, the system keeps working, but the reasoning behind decisions slowly fades away.
So I’m curious how real this is for other devs actually working in production systems.
Do you run into this often, where understanding the intent behind architecture decisions becomes harder than understanding the code itself? And does it actually slow you down in meaningful ways when you’re trying to make changes, or is it more of a background annoyance that teams usually manage around?
I’m trying to understand if this is a normal part of working in software at scale, or if it’s something that’s just unusually painful in certain environments.