The Lost Art of Code Reading
By Eric Alan Christiansen (2017-08-10).
When Coding was a Labor of Love
Not many people really realize how laborious it was to write programs in the "old" days.
When I started programming more than 40 years (at age 13) things were a lot different. My first programming experiences were via my junior high school computer club. We didn't have a computer anywhere in the entire school. However, there was an IBM mainframe computer at the school district headquarters. Students were allowed to submit programs on punch cards that the central computer staff would run overnight. Of course, my local school didn't have a card punch either! But that didn't stop hard-core geeks. It was still possible to use a #2 pencil to "bubble" in the spots where the punched holes should be. The "" Hollerith" code system specified exactly which spots had to be punched or bubbled. The card reader at headquarters was flexible enough to read either punched holes or #2 pencil marks (usually).
I bubbled in so many cards that I could read a punch card just by looking at the holes. After I bubbled all the cards for a program I put a sturdy rubber band around the card deck. Rubber band technology was very important in those days. If the rubber band broke prematurely it was a catastrophe. On the other hand, too many rubber bands or too tight a wrap and the cards might get bent. That was also very bad because not only would the program not run, but the card readers of the day often shredded bent cards in an effort to unjam. Programmers of the day usually had very strong opinions about rubber band brands and how to wrap up a card deck. A newbie programmer could always be identified when they pulled out cheap, thin, multicolored rubber bands.
After carefully banding my deck, I would drop it carefully into a big canvas bag in the math room. Often I had invested hundreds of hours into the program contained on those cards, and I had no backup. How do you backup hand-bubbled computer cards? Sometimes the decks I placed into that bag got lost and simply never came back. But after offering up a prayer to that great data center veiled computer-god I would go on my way.
Two days later, with luck, my card deck would return in that same canvas bag. It would be wrapped up in green and white computer paper like a butcher wraps up a cut of prime rib. No butcher's tape, however. Once again rubber bands were the preferred security method. All too often, even after going through all that effort and waiting all that time, the program would have a simple syntax error would not run at all.
Desk Checking
Considering the time and effort required to actually compile and run a program in the early days, it is not surprising that early programmers made considerable effort to check code before submitting it. We called this "desk-checking". When programs came back with compile-time or run-time errors, we also spent a lot of time desk-debugging.
Much of what I learned in my early software development days is useless now. Nobody really cares if I can read Hollerith codes or if I can resort a deck of cards. It is so much easier now to create and debug programs. This is a great thing. Even mediocre programmers today are far more productive than the superstar talent of yesteryear. I have no desire to go back to punch cards. But I think during this process something good might have been lost. When code writing was so difficult, programmers became great code readers. Now that code writing is so much easier (per line of code), it seems harder than ever to interest programmers in code reading. This is one of the reasons it is hard to get people interested in code reviews, which typically involve lots of code reading. Automated code review tools are already making this easier. Unit test summaries, test coverage reports, documentation coverage reports, and standards checkers make code reviews less tedious. Despite all this, I encourage all programmers to occasionally take a deep breath, get a cup of coffee, and sit down and just read through their code. Often subtle, but serious, logic problems just won't be detected otherwise. Generally, when I convince another programmer to do this, they later report that they found something significant, to their surprise. It's worth a look.
Ancient Programming Artifacts
Programmers of yesteryear needed briefcases for all their stuff. I used to be occasionally teased in high school for lugging around a briefcase full of books and all the tools below, except the card punch machine! Of course, before most of those who were teasing me graduated high school, I had graduated early and was working at an engineering firm helping to build the space shuttle, and teasing them for their exciting fast food jobs. Karma can be rough sometimes.
