Sometimes, the IT department can be really small. At this 50-person or so company, it was me (the software guy) and my boss (the hardware and network guy). As a developer, I was also release engineering, software QA, complaint department, and manager of in-house beta testers (it should be noted that our software was only used in-house).

It was the late ‘80s and the ‘90s, and my world was C code and batch files running on pre-Windows DOS, with distribution of new software releases done by going to computer by computer with a floppy disk in hand. Optimizing templates to the next lowest multiple of 512 bytes was a big deal, as bundled records were distributed on floppy disks.

I learned many lessons at this company, and like my predecessor (same first name!), I would last for over a decade before finally getting fed up and needing a change. My continued interest in the industry (which declined from 3 companies to 2 during my time there, due to us buying out the third) would occasionally have me crossing paths with my old company.

Anyways, here are some lessons that I learned while there:

  1. Release engineering’s builds must at least always be happy-path tested before being released. My first boss there was not a big fan on testing new builds before release, which confounded me as much as the in-house users. Before the network, he tended to do this at night, frequently moving the person’s chair and whatever was in the middle of their desk as he proceeded. I vowed to leave no tracks and to make sure that whatever I built worked. It was an important lesson to learn.
  2. User experience and usability are very important. Today this is a very obvious statement. But it was not always that way. Anything faster than a typewriter or writing on paper was a wonderful thing – why should speed and ease of use need adding at all? Well, it was obvious to me. I remember being told that people should memorize fields of 2-character codes for data entry, and only be able to edit records upon entry or before entering the next record. I knew better, and designed a way to display what the codes stood for, and allow anytime CRUD access with multiple lookup methods, and use of dropdowns that match what you type in place of codes. Likewise, designs that saved keystrokes and gave better control were important. Having selected text to populate in (instead of needing to be rekeyed) is important. Totally automating steps that never needed human intervention is good too. And having easy-to-find help files before wikis ever existed was very helpful.
  3. When in doubt, go to the source. When a user has a suggestion, it is tempting to read what they say and program it. But it is more important to talk it out with the suggester, make sure you understand, and think about how to expand what may help the user experience (“You know, if as long as I’m adding X, it is easy to implement Y too — would that be beneficial?”). Here at QualiTest, the art of collaboration work definitely leads to better results, while silo-ing your thoughts can cause you to accidentally drift down a wrong path. Sounding boards help.

I see myself more as a software QA professional these days than a developer, although I am always ready to dabble in code or automation if necessary. But being able to sit back and ask “What would the user want?” helps keep my focus where it needs to be.