When I was in university, every homework program was written fresh. There was no maintenance; the code was as new as definitions allow. For every problem, I read through the math or science (or common sense in some cases) required, thought up the logic, and proceeded to write the code.
Since copying was generally frowned upon, when helping fellow students, I had to come up with explanations that they understood, sometimes even coming up with new code.
When I first joined the workforce as a professional, all that changed. I was introduced to numerous programs and scripts, each with hundreds of lines of code. Each program was filled with business logic that was partly stored in documentation and partly stored in the heads of my colleagues and manager.
And I didn’t write a single line of that code.
The programs and scripts were run on a monthly basis, and generated lots of output reports. So the first order of things was to learn the broad idea of the whole system. That was over in, I don’t know, a few days?
Next came supporting the users. I had to look at reports and make sure the relevant numbers tally. I was dealing with financial data, so if there was a difference of even 0.01 cent, I needed to know and correct the error before the users look at the reports (there’s still enough time buffer).
The programs dealt with massive amounts of data. I’m talking millions of database records. Sometimes, something fails. I get to be the one being paged (yes, the pager was still around then) by the operators on shift duty. A few Saturdays and Sundays were spent at the office looking at data files, scrolling through lines of code and doing update statements in the database for correction.
As each month went by, my familiarity with the programs and business logic grew. I reached a point where I no longer needed to be hand-held by my then mentor colleague. Occasionally, I still ask for help, but I was trusted enough to maintain the code myself. Which was fortunate, because there was a new project then, and my manager and colleague were full into the meetings and request evaluations.
There were support calls to answer and user requests to fulfil. The new project required new programs to be written, and involved changes to existing programs. It was at this point that I learnt something due to task and time management.
I didn’t need to know everything about my existing programs to make useful changes.
The new project, new business rules, new code to be written, and support calls from users and operators, forced me to be effective in identifying lines of code for change, for maintenance or for correction. I didn’t have to be familiar with every program, every line of code, every nuance of business rules to do maintenance work. I just needed to know enough.
That required that I understand the code as was understood by the original coder. To the point where I not only know where to look, and also where not to look.
You must understand that when companies hire you, they want you to become productive as soon as possible. Spending months understanding framework code and business logic while you basically did nothing useful is a waste of resources. It’s not full understanding and then start being useful. It’s incremental steps to understanding and small increases to productivity, back and forth, in a cycle.
So what’s the takeaway lesson for you? Don’t get bogged down in the immensity of the code you’re facing and maintaining.