Throwback Thursday posts in social media often deal with something from a couple of years ago, usually to make fun of how outdated some technical thing from 2015 looks to our 2020 eyes. But this week I’m going waaaay back.
We’re talking 1987-1988. I was a very green tech writer on her very first full-time technical writing job. The company that hired me had a contract to supply documentation for IBM Santa Teresa Lab in San Jose. My first project was to write the Getting Started guide for the 11th release of DFSORT, a mainframe software tool for sorting datasets.
Writing A Manual
I didn’t have any personal knowledge about mainframes, other than “don’t drop the punch card stack” (which I learned from watching a college friend waiting for computer time when we both attended University of Oregon). I knew a teeny tiny bit about sorting data — a previous boss had shown me how to sort columns in Excel, so I at least knew words like ascending and descending and could build on that. I was part way through my tech writing classes at DeAnza, and knew how to write instructions for making sandwiches (a typical class project) so the idea of writing “instructions” didn’t scare me, but I’d definitely never written an entire manual by myself.
Most importantly (for me), I didn’t know diddly about how big companies like IBM operated, since most of my work experiences to date had been at small companies or small subsidiaries. (For example, I spent several months working as a desktop publishing contractor for 3Com in 1987, but the small documentation production team I worked with were the only people I interacted with.) Working for small, cozy, or family-owned companies didn’t prepare me for IBM at all. The very thought of doing work for a company that big was overwhelming. Even in the 80s Santa Teresa was a sprawling campus with multiple buildings, and Sykes Enterprises Inc. (the company I worked for) only had a 6-room office suite on a middle floor in a typical San Jose office tower.
But I was a writer with a couple of bylines to my name, and I was armed with a journalism degree, half of a tech writing certificate, and a style guide. I enjoyed computer tech of all sizes, shapes, and languages, and I thought (and still think) that learning new software was fun. I had a talent for asking questions, and didn’t care if my questions made me look stupid just as long as I got an answer. As a bonus, at that time in my life I owned multiple blue suits complete with white shirts and the requisite silk scarves. So my employer shipped me off to team meetings, gave me a short deadline and a desktop computer to use, and crossed their fingers.
Working with Engineers
Five foot tall me, still a little bit too un-California after less than three years in the Silicon Valley, with my inner-cynic still nicely tamed from growing up in Oregon’s relaxed attitude, and with more fluffy curls than the entire cast of Hair usually sported…I probably drove those poor engineers nuts with all my chipper, naive, air-headed questions. But I got it done. The engineers even liked my work and told my boss.
Writing mainframe software documentation isn’t glamorous today, and wasn’t even back then. It got me zero street cred, and I had to fight hard to even get interviews for my next technical writer job. But I learned a ton about the documentation process, and I definitely learned about working with engineers during my time writing for IBM. I enjoyed the job itself and liked my co-workers. Best of all, just a few months in I knew I had found a type of work that I was actually good at and that was complex enough to keep me interested over the long run.
It’s been 32 years since the first time I saw a manual page with my name in the credits. It’s been 32 and a bit years since my first big meeting with a whole team of IBM engineers, all armed with black pens and three-ring binders. But I still very clearly remember the senior writer who went with me to that first meeting asking me afterwords if I had any questions. All I could say was “Why were they all in the same blue shirt?”