When Coworkers Complain

My first programming job was writing code in an Assembly language for NCR Century minicomputers, called NEAT 3, for a trucking company.  For the record, the first day of my career was the Ides of March in America’s Bicentennial year: March 15, 1976.

We wrote the code on paper forms using pencils, used a key punch machine to punch cards, which were then read into one of the computers when the computer operator was able to get around to it.  We had two computers, and each had only two partitions, and only one of the partitions was capable of “cowpiling” programs.  (Our operator, Al, had a rather cynical sense of humor!)

Along with some enhancement and bug fix tasks, for example, changing the number of digits needed to represent a terminal – the equivalent of a primary record key in today’s terminology – from two digits to three, I remember working on a system to process claims for items damaged during transit.

And along with some other people, I worked with a woman whom I will call Carol, who was constantly complaining about how hard it was to understand the programs she had to make changes to.

This made a huge impression on me!  The last thing I would ever want to be is the type of person my coworkers complain about!

Specifically I remember her complaining about how the original author managed tables.  NEAT 3 provided a mechanism for iterating through tables, but the original author of the programs Carol was working on was too smart by half to use it.  Instead he  chose to “bump registers,” which means he would:

  1. store the address of the current row in the table in a register
  2. process the current row, saving the new values if required
  3. add a literal offset, such as 123, to the register, to access the next row in the table

So when Carol wanted to add or remove a field to or from the table, or change the size of an existing field, she had to find all occurrences of the current offset (123 in the example above) and change it to the new size.

That means that Carol had to find every piece of code in the entire system that iterated through these values, and update that offset, every time the length of the table changed.  In all of today’s modern programming languages, all a programmer should (!!!) have to do is change the contents of the table – which we hope should be defined only once – and they should be good to go.

This might not be so bad, if we had an Integrated Development Environment (IDE) or even a fancy text editor like vi (aka. “six“) but we were using punch cards.  Yeah.

The lesson I learned from that experience is that writing programs with an eye towards maintainability can not only help keep future programmers from being aggravated and hating you, but also save your employer a lot of money down the road!

As this recent post on slashdot, and even more so the responses to it show, Carol’s situation was hardly unique, or by any means antiquated.

When coworkers complain, valuable lessons can be learned!

My First Code Review

My second job was writing IBM Mainframe Cobol programs for the City of Richmond.

I started out making some changes to some existing programs: enhancements and bug fixes, nothing major.  We had Systems Analysts then who were familiar with how the programs worked and who would spec out the changes quite thoroughly.

Then I got to write my very first entire program.  I was so proud of it!

During this time I’d identified a couple of colleagues as being sharper than the rest (mainly because the were not part of any of the gossip gangs).  So I asked them what they thought of my program, hoping that they would like it, because I had learned at my previous job that maintainability is important.

They tore my little program to pieces.  I thought I might cry — but I didn’t.

They taught me how to use structured programming techniques to organize my code.  Many mark Edsger W. Dijkstra’s famous paper GoTo Statement Considered Harmful as being the beginning of structured programming techniques, but it is much more than using Perform statements instead of GoTos.

Because it strives to read like English, Cobol does not have the syntactical mechanisms that many other languages do, control structures that allow developers to break things down and organize code into components.  So they showed me how to precede all functions with three- or four-digit numbers, that would reflect the function’s place in the flow of logic.  Although foreign to me at first, after seeing how it worked, it made a lot of sense.

As it turns out, I learned more in that hour than I did in many of my classes at school!