I often search for a clearcut answer to a technical question and I'm met with a 2 hour history lesson into a decade of company politics and failed replatforming projects.
Yeah, thanks for telling me why John from accounting was a dick 10 years ago and you had to code this module in a certain way. I really don't care. I'm new to the codebase and I just want to know how it (the codebase) works.
I'm currently in this situation and a colleage never gives straight answers to anything. It's always some little rant about something and when it's done, I still haven't got my answer.
> I'm new to the codebase and I just want to know how it (the codebase) works.
You should want to know _why_ it works that way too if you want to do any meaningful work with it. Context matters. I’ve seen many cases where the way something works seems dumb, only to learn later they had already tried the “smart” way but ran into some obscure problem which the “dumb” way solves.
This is important. As soon as we come to the understanding that the coders that came before were not all idiots then we are forced to ask the "why". There is generally a decent reason why something is coded the way it is. Could be as simple as it was an emergency and meant to go back and fix it but never had the time or it could be a valid business edge case that absolutely had to be wedged in. There is almost always a why. Otherwise you tell everyone about a fix you made that 3x performance and you see their faces go gray as they explain you just shut down some archaic but mandatory process in Singapore.
It probably depends on the person, but I personally enjoy such tales. Gives me more context about why a piece of code was written the way it is now. But then again, I also enjoy scrolling through the commit history of a repo like it's an archaeological dig site, so I might be the weird one here ahaha.
It's full of "fix" or "fix typo" or "update blah.c"... tiny commits straight to the master branch without CI.
Anyway, I really don't care about the past in this way. A simple "accounting needs this for that" is enough for me. No need to explain that Adam was getting divorced at the time, so he was grumpy, and, and, and...
Easier said than done, but try telling them that. "I appreciate you sharing context, but it's too much to take in at once. It would work better for me to get a more clear-cut answer."
Sometimes, the 2 hour story isn't worth the time it's told. Sometimes, the 2 hour story gives you the insight necessary to satisfy Chesterton's Fence. It seems like in this instance, that's not the case, but I'd definitely encourage you not to dismiss stories in general because you don't think you need the history to achieve your goal.
Because I don't want to hear about personal stories? How is that related? I do very much want to know how code works. It's the very core of my argument.
And this propagates the problem. Getting an answer without understanding. Sometimes the history is necessary in order to not repeat botched attempts at "fixing" something that people have already tried.
I often search for a clearcut answer to a technical question and I'm met with a 2 hour history lesson into a decade of company politics and failed replatforming projects.
Yeah, thanks for telling me why John from accounting was a dick 10 years ago and you had to code this module in a certain way. I really don't care. I'm new to the codebase and I just want to know how it (the codebase) works.
I'm currently in this situation and a colleage never gives straight answers to anything. It's always some little rant about something and when it's done, I still haven't got my answer.