Early in my career, I was studying the code of an application written for the Apple II in preparation for developing something similar on the PC and would often ask questions of the original programmer. Most of the time, I'd get valuable information about the purpose of a routine or why something was done a particular way. But every once in a while, when pressed for an explanation, the programmer would think for a minute, then simply utter, "For Historical Purposes" and walk away chuckling.
I was somewhat frustrated because I wanted to know the "WHY" of everything--there had to be a good reason for coding things a certain way, right?
Well, it turns out, I've had to use that very phrase many times since those early days. Sometimes there are good reasons why code turns out the way it does--sometimes not so good. It could be that new requirements are coming so fast, you don't have time to rewrite a routine to fit multiple scenarios so you have to duplicate the effort to fit each instance. Working on legacy code where there have been several developers touching various parts over the years, there are bound to be questions about the code that no one can answer--sometimes because not all programmers play well together and have very different ideas on how things should be done, other times, a new developer may not know about how something was solved previously and do it again--differently.
I was recently working on a legacy Delphi 5 project and needed to implement some checks in a data entry screen. There were several parts of the application that used this type of data and so the same check needed to be implemented in multiple places. Once I figured out how to use existing data fields in the first screen, I figured it would be a simple copy-paste to the other modules. But no, in the second screen I worked on, instead of a dataset ready to use, a function went out and grabbed all the necessary information and stored it in a class. That's a better approach but now instead of simply accessing some readily available data fields, I need to go modify the class, then modify the method that fills the class before I can use it.
The important thing is to be flexible and observant and figure out how things ought to be done but also keep a keen eye for reusing whatever constructs are already available to prevent re-inventing the wheel. Sometimes that involves searching with the right keywords, sometimes that asking the right person.
And if the answer is vague and involves some hand-waving with references to a distant pass, just smile and get back to work!