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!

Leave a Reply