Pure programming knowledge is not enough

I’m short-sighted. The degree of blurriness isn’t terrible, so I can still make do without glasses. When I first started working, I thought working with computers the whole day warrants the wearing of glasses, so I got myself a pair. Turns out to be more trouble than it’s worth…

Eyeglasses
[image by Gene Chutka]

Anyway, I found out about it when I was in university, when I couldn’t see the notes on the projector screen or on the board properly. I’d have to sit in the first 3 rows if the words were to be clear. But the first 3 rows were occupied by uhm, zealous students, so I took seats slightly further away.

Since I couldn’t see much of the notes, I squinted. To forestall some of the obvious questions, no, vanity had nothing to do with not wearing glasses. Glasses were expensive, and so were contact lenses. And they’re really troublesome to wear on a regular basis. So yeah, no glasses.

To compensate for my “loss” of sight, my other abilities stepped up to take on the responsibility. After 2 and a half years of serving the nation (National Service in Singapore), I was suddenly very productive. I paid better attention to the lecturer. I listened carefully.

Since I can’t see very well, I got context from surrounding words. My language skills helped a lot, filling in grammar, spelling and sentence structure. In both proper and “broken” English no less. I was studying math, and my math background helped in making sense of the symbols and the esoteric language used, filling in gaps where my language skills were useless.

With perseverance, lots of context filling (from language and math), I got most of the lesson. I actually took very little notes, since I couldn’t copy them fast enough anyway. I opted instead to understand what the lecturer was teaching and try to quickly absorb them.

I’m not so much concerned with seeing the words correctly, but interpreting them correctly.

The squinting… Now the squinting seemed to blur the words even more. But I saw the words more “clearly”. It’s like holding a picture close to your face. It’s blur, and you can’t make out anything. Take it further away and you can see the picture. It’s something like that. I needed to “blurrify” the words so they became meant for far viewing in my case. Sort of like Nazca Lines.

After I graduated and started working, I got myself a pair of glasses. Then I stopped wearing them. I haven’t needed to read words at a fair distance. And the computer screen seems to read fine. I take regular breaks to rest my eyes. Besides, wearing glasses gives me a headache and dries my eyes easily. Sometimes, I still wear them, and only for reading books and playing video games (otherwise I can’t see the dialogue on the TV screen).

The lesson?

When I read code, be it other people’s code or mine, I use a lot of context filling. Half the time, I’m using my knowledge of business logic, human psychology and languages (English or otherwise) to understand the code. The other half is programming knowledge.

It’s when I do this that I figure out patterns, of decisions made (where devoid of comments). That I understand where I needed to make changes for new business logic. That I can do simple refactoring (the refactoring is simple. It’s the understanding that’s hard. Different programmers do the same thing differently).

I found that when reading code, whether because of debugging or adding changes, pure programming knowledge isn’t enough. For example, if I knew the original programmer wrote that piece of code far in the past, I could make a guess as to why he wrote it that way. Say he’s trying to optimise a piece of code, but the optimisation is no longer relevant in modern times.

It bears repeating. Pure programming knowledge isn’t enough.

You just need to know enough to maintain code

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.