I learned just about everything I know about writing computer code from a man named Carl. I met him in the early 90s when we were working on creating a digital, automated way to transmit raw union payroll data from my company (a sound postproduction studio) to his (a payroll processing company). The idea was simple. When work orders were “actualized” in my OpsPro software (i.e., updated to reflect what actually happened as opposed to what was scheduled to happen), the system would have data that reflected who worked on what and for how long. Obviously, this fed billing in the receivables module.
Every week, the person responsible for payroll would manually compare employees’ timecards (written in their own hand) to the actualized work order(s) (this step was to ensure they weren’t “cheating”), record each employee’s hours in a spreadsheet, and then fax that to the payroll company, where data entry clerks would manually input the names and hours to produce paychecks. It was a tedious, cumbersome process prone to errors, and one ripe for automation.
Since the actualized work orders contained the who and for how long data, this could be transmitted electronically to the payroll company. They simply needed to write code on their end to receive it and feed it into their system. That was Carl’s job. Mine was to fine tune the work order actualization process to eliminate as many errors as possible and extract the “hours worked” data on an employee by employee basis.
I would say that 90% of computer programming is code which keeps end users from doing something stupid; catching their mistakes before they corrupt your data is essential, and critical where something as sensitive and important as a paycheck is involved; you try explaining to an angry union crew why their pay is short by ten hours and see if you get out of there alive! So I was keenly aware of the mission-critical, no room for error(s) nature of the work order reconciliation (actualization) module I was coding – and this meant “predicting” the likely errors users were prone to make (what Carl and I called “Stupid User Tricks,” a not-so-thinly-veiled homage to Late Night and Late Show host David Letterman’s “Stupid Pet Tricks” and “Stupid Human Tricks”).
There’s the obvious ones, like associating a crew member with the wrong work order which might result in an over- or underpay, but then there’s the not so obvious ones where you’re thinking “this would never happen.” I would protest, “this would never happen,” and invariably Carl would hit me back with, “but what if it did?” Sometimes that annoyed me, even though he was right.
Then, as now, I did my best work in the early morning hours (it is 2:17 am as I write this sentence). We both believed that the best tester of a program was someone unfamiliar with how it had been coded, so I tested his and he tested mine. And to make this fun and less monotonous, we both coded wildly inappropriate, offensive, and vulgar error messages to be displayed if the error was triggered by a test, obviously replacing those messages with something more professional and appropriate before going live with a program to be used by actual users.
The work order to payroll interface was a triumphant success and a huge time-saver for both our companies. On my side, it meant no more manual compilation of crew hours and the time-consuming task of recording then transmitting that, freeing the employee up to work on other tasks. On Carl’s side, it meant eliminating some data entry positions which decreased his company’s overhead affecting their bottom line (without having to raise the price they charged for their service). A win-win.
About two years later I was sitting in my office on an otherwise unremarkable weekday afternoon when my phone rang. It was Mary from Scheduling – the department responsible for actualizing work orders. We exchanged some polite pleasantries, and then she said, “the system just said the strangest thing to me.” I was pretty matter of fact; since I’m the one who wrote all the error messages, I was smugly confident I’d be able to pinpoint the problem and tell her how to correct it in short order. I was not wrong nor was my confidence misplaced.
So I said, “oh yah? What did it say?” And she replied, “it said ‘Are you a fucking moron?’ and then only gave me a button that says ‘Yes’ to push.”
Obviously, one of my early morning messages meant for Carl testing my code had been overlooked and included in the live program. What’s amazing is I remembered the exact error I was testing for there.
So, tears rolling down my face, stifling back laughter, I calmly said,
“check your work order’s END time, it’s chronologically before your START time, and that is impossible, unless the crew on the work order invented time travel.”