jump to navigation

Real-World Programming 101 June 19, 2009

Posted by secondtimer in Computer programmer's memoirs.
trackback

My first venture into on-the-job programming–other than maintaining programs other people wrote–was pretty much a fiasco.  The boss told me he wanted an inventory program–I’m pretty sure he actually used the word “inventory”–but the two of us never got together on what an inventory program was supposed to do.  Ithought I knew:  our final project in Systems Analysis and Design was an inventory system.  With my mind running happily ahead, I said, “Okay, we’ll probably have to put a terminal in the parts room so the guys in the shop can debit the parts they’ve used…”

I didn’t get any farther.  There was to be no mention of a terminal anywhere in the shop area, nor any mention of the mechanics learning to keyboard.  What the boss wanted was for the girls in the office to be able to enter all the parts shipments as they came in.

“But we won’t actually know what we have in the parts room unless somebody takes out the parts as they’re used,” I said.

No matter: the guys in the shop could look at the shelves and tell what was there.  But then, what was the point of…

Mine not to reason why:  I wrote something, and they used it for a while, but to what purpose, I never understood.  I harbored uncharitable thoughts about my instructors, who didn’t make it nearly clear enough what management in the real world was like–although there was one who used to tell what he called “war stories” about his days as a mainframe programmer. After the inventory program debacle, I started writing my own to the head of the department, who had taught me in at least half the computer-related courses I’d taken.  He never wrote back, but when I ran into him on campus, he always let me know he’d read about my adventures–and found them more entertaining than I did.

My next opportunity to shine as a programmer was a long time coming.  The boss didn’t like the old transportation software, and the office manager didn’t like the old accounting program, which was written in BASIC, but furnished already compiled, without the source code, so there was relatively little I could do to change it, unless I wanted to violate that perennial license agreement thing about not decompiling, reverse engineering, disassembling, etc., and everything always had to be changed.  It had finally come to me that what small business owners and managers wanted was to do everything exactly the way they had always done it, but on the computer, so they could brag about it to their friends.  Sometimes the way they’d always done things wasn’t the best way, computer-wise.  At any rate, the old accounting program and the old transportation software needed to go; given my experience with the inventory that wasn’t, I wasn’t as upset as I might have been that they didn’t let me write the replacements.  Instead, we got a new set of consultants.

The entrepreneur in this one had actually worked for a trucking company and knew BASIC.  He had written industry-specific software he wanted to sell us, but had decided dBAse would be a better choice of language, so he’d talked his accountant wife into learning it so she could redo the system in it.  Being a startup operation, they were willing to do lots of customization, so she spent a good bit of time in my office for a while.  (It was originally intended for a board room, I think, and there was plenty of room for both of us, as there was, later, for me and whole teams of auditors.  The joy of having a room with a view was that I got to share it with anybody who came calling, including, occasionally, small children and Jack Russell terriers. I never really minded the Jack Russells.)

Before she left, our new outside programmer found us a new accounting package that could be bought module by module as we decided to implement it and could be had complete with source code–in dBase–so I could modify it.  She recognized the need for this because she had to do one set of changes to the check stub before she got away.  (She managed to talk the boss into getting a modem–about 8Kbps, I think–so she and I could communicate long distance and pass new bits of programming back and forth.  The modem was a step up from the network, but barely.) Out of curiosity to see if she understood the boss any better than I did, I asked the office manager how he liked the check stubs after the first payroll run following the changes. He didn’t, of course–check stubs had been a constant irritation to him with the old system as well; but I didn’t really think he’d push the issue right away, so I’d been spending my free time on the job flow-charting the transportation software, which was sprawling and multi-faceted and multi-moduled, so I would know where to look when problems arose, as it was quite certain they would do.  I hadn’t spent much time looking at the payroll program, except to see that it was written in a style I’d never seen used in dBase and that seemed a bit convoluted even for a bigger system than ours.  I nodded over the boss’s expected dissatisfaction with the check stub, hardly even listening to the catalog of things he wanted on that weren’t and things he wanted off that were and things he wanted in a different order, and was heading for the stairs when the office manager stopped me dead in my tracks.

“And he wants it all adjusted to fit on the old payroll checks,” she said.  “I told him you’d have it ready for next week’s run.”

Next week was a short week because there was a holiday tacked onto the weekend, and short weeks made getting the drivers, who were paid on commission and were sometimes late getting back with their paperwork, figured in time to have the checks ready to be signed before some of them headed out again.  If I hadn’t been heavily enough involved in day-to-day operations to know that, maybe I’d have felt more confident of having time to do the changes; as it was, I spent the holiday weekend with the manual for the new payroll program and printouts for several modules of code, trying to understand the data-flow in and out of files, strings, variaables and data-type changes well enough to do what amounted to a complete rewrite of the module that printed the check stubs.

When I went in Tuesday morning, I had it pretty much under control; but I wasn’t happy about it.  I had to cross boss’s everyday office–the messy one in the middle of everything–to get to the stairs to mine, and on impulse, I paused in the doorway and asked if he’d ever seen the code that print the check stubs.  He hadn’t, of course, and didn’t much want to, rightly suspecting he wouldn’t know what he was looking at; but I showed him anyway:  I let the end of the relevant printout drop to the floor in the doorway and unfold behind me as I walked across the room, past his desk and up the stairs.

I don’t know whose eyebrows went up higher, his or the office manager’s, but they started asking me how long a change would take before they decided when to implement it.

As big a job as the check stub was, it was still working on somebody else’s code instead of my own.  When my one-and-only chance to do a fair-sized programming job from scratch came along, it was appropriate, considering I’d started my career by learning COBOL just as the IBM PC came out, that it would be re-inventing the wheel.  The new accounting system didn’t suit, either.  We Payroll and maybe Accounts Receivable, as we had used Payroll and maybe Accounts Payable in the old one, but to trust the main accounting tasks to a computer was very hard for the O.M., another bookkeeper before her elevation, to do.  There were plenty of accounting systems available for desktops by now, but she didn’t like any of them I brought to her attention; still, the boss wanted his bookkeeping done by computer, so she was in a bind and tried to pass it on to me.  Exasperated, I asked if I wrote an accounting program if she’d use it.  You guessed it:  for my crowning achievement as a programmer, I pulled out my old Accounting book and wrote a general ledger program.  Whee!

The program I was proudest of, though, was a little shorty.  Figuring the drivers’ Christmas bonuses was always crunchy, given all the criteria upon which parts of them were based and the boss’s tendency to sit on the data he was evaluating beforehand until the last minute.  One year, he got the idea he wanted a program to make it easier on the girls in case he had to be out of the office at the critical moment.  I knew this was a program nobody was ever going to use, because he not only wouldn’t trust it to figure just the way he would, he didn’t even really want anyone else to do the evaluating or checking the figuring.  Still, it made him happy to think he wanted it, and it made me happy to write something exactly the way I wanted to, without benefit of forms, conventions or good sense, in the sense of what worked faster–case structures, which had never been as intuitive for me as good old “if…then” clauses.  I used a lot of them, one inside the other–almost as many, in fact, as the interpreter was supposed to be able to handle.  Of course the boss didn’t like it; he let it crunch the numbers only once, then redid it all himself with the help of the other girls; but I was pleased with it and showed the code to my old COBOL instructor–he of the war stories–and he allowed as how he’d never seen that many nested “if” clauses before–in a program that would run.

Comments»

No comments yet — be the first.