Once upon a time, when Gutenburg cranked up his press, it was critical that poets and playwrights fit their lyrical genius onto a finite amount of space. The full bloom of your prose must fit onto the folio – too short and it was a waste of space; too long and it was a wasted expense for the extra page. It was an exact art to find the balance between your message, and the space you had to share to with the world.

Fast forward 550+ years.

Last week, my son made an offhand comment about my not being technical. And I’m thinking “Child, I was earning a paycheck in technology before you were even born.” And then I’m thinking “ZOMG, we’ve reached the milestone when I used I’ve-been-[doing a thing]-since-before-you-were-born to defend myself.” I might as well have said something about uphill both ways in the snow. Sheesh.

But the truth of it is, I have been doing this for a long time. I started my technical writing career in 1997. I know. That’s eleventy thousand years in Technology Time. My first gig was at a company that produced supply chain software. I was on the skeleton crew team that did upkeep on their legacy product while most of the company worked on the heavy lift to get the Shiny New Product out the door. The work I did was documenting a Franken-product that randomly had new modules sewn onto the main code stem. The interface was awful, there was no consistency in design or nomenclature, but it was software that paid the bills until the new product started generating revenue, so we’d all need to drag the Franken-product forward, like good cogs in The Machine.

In those days, software came in a box. There was a CD or two, perhaps a tri-fold Getting Started sheet, maybe some minimum requirements printed on cardstock. And there was a guide. An honest-to-goodness printed document. In those days, people who purchased software often weren’t the people who used the software. And the folks with the checkbooks determined the worth of the user documentation by the quality of the “thunk”. Money was well spent if the User Guide made a “thunk” when you slapped it down on a desk.

In those days, the dominant theory of product documentation development was “If some is good, more must be better”; all in the pursuit of getting a good quality ‘thunk”. If there was something to read, click, type, browse, enter, select, verify, press, or navigate, we included that in our task instructions. On top of that level of granularity, we could only include one action in each step

Thing was, it meant that there were some terrible instructions:

No wonder it became a source of pride to NOT read the directions. Even if there was good information in there, it was buried under reams and reams of unnecessary content. But it made a glorious “thunk”.

Then, it seemed like someone woke up and realized that 4 pages (and 35 steps) of instructions could be replaced with something waa-aaay easier:

Complete the fields, then verify and save your information.

Done and done.

My profession had successfully slayed the “Thunk”. Huzzah!

It seemed like we’d be entering a golden age of Technical Writing. Only create content in bite-size pieces. Salient information only. Succinct. If there were two ways to achieve a goal, only document one of them, Brevity became the new sheriff in town. Under this new banner of minimalism, writers would be freed up to spend our time writing more valuable content. But alas, we entered the era of the Ikea Instructions. Trust your user – give them what they need to complete the task, but not a syllable more.

We eventually realized that we’d traversed the continuum to the polar opposite problem. Classic Goldilocks principle: Too much isn’t right; not enough isn’t right either.  Now, we’re in a constant hunt for the sweet spot, and the sweet spot is usually a moving target. Some tools or features are inherently more complex, which means they require more robust documentation. Some are less complex, so they require less. Sometimes we can either recycle similar content or cannibalize older content to update it for new releases. Sometimes, a feature that is very complex under the covers impacts the knowledge team as an extra bullet point in an existing task or a new sentence woven into an existing paragraph. Sometimes the opposite is true.

My writing team isn’t constrained by the cost or space of a printed document. We produce soft-copy Word documents and online HTML-based help. Both deliverables are generated from a single source of content. Still, the *just right* amount of content is sometimes elusive.

With a monthly release cadence for most of our content, our constraints are around timelines:

• When the development team is code complete so that we can do a knowledge transfer and use that information to write and test new features.
• When we can get content pushed through the review process to ensure technical accuracy and adherence to corporate style standards.
• When we need to be documentation complete so that we can localize content into languages for our non-English speaking clients. And a week later, when we can import translated content to publish and post for general availability.

Based on our collective deadlines, if the development team, reviewers, or writers get pinched, even for just a few days, we might need to prioritize content, and make trade-offs to meet our deadlines. Perhaps there aren’t as many images because we were still struggling with the final UI as the localization deadline loomed.

In DayJob-Land, my team is highly skilled at self-regulating and load balancing to provide the best content we can for the our monolith product release every month.

But that’s not all we do. In a previous part of my career, Child participated in Take Your Child To Work with me. Take Your Child To Work is a career-exploration event for Grade 9 kids, and it happens (global pandemic notwithstanding) in November. The place I worked then I brought Child in had a pretty great program set up for them (as does the company I where I now work), and he got to see several parts of what High Tech looks like. I availed upon the good graces of my friends in different departments and he got to shadow a developer for a while, and a QA person, and our very personable office admin. But he said the was pretty surprised by the things I did (and do) that aren’t solely stringing together words into sentences. In my current role, in the background, unrelated to the monthly release, there’s a flurry of other activity going on.: In any given week, our team is working on better ways to deliver information, sifting through search word analytics, making updates and improvements to our templates, learning more about our authoring tools, prospecting additional ways to give our clients what they need when they need it, creating/testing/rolling out new processes to be more efficient on the content creation side, content improvement strategies, corporate goals, professional development for our own career development, assessing our accessibility compliance to international standards, being lent out to other teams’ projects to help meet their goals, and wordsmithing and review services for one-off projects, like blog posts or usability testing. So when, a few months ago in the aftermath of the seizure, my language processing was impaired, it was a scary thing. I depend on the words. But I’m on the mend, and my team has been supportive along the way, That’s what you want in a team, and I’m grateful for it.

I mean, don’t get me wrong, sometimes I still want to run away and join the circus, and I did, once, find a tech writing position *at* a circus. So yeah, word nerds aren’t just the Grammar police (I mean, we’re totally the Grammar police, but that’s not *all* we are…) I personally have worked in email forensics, cryptometrics (facial recognition) for airport security, security camera evidence review software, and a local Canadian-based telephone then-tech giant, and presently, Educational Technology.

Remember when you were a kid, at the top of a hill with your purple banana seat bike? Remember how you believed to the core of your being that you could make it to the bottom? You could picture the streamers on your bike handles flying triumphantly in the wind. You couldn’t see the rutted shoulder or the scattered pebbles or the dozens of other obstacles between you and neighborhood bragging rights. That’s kind of what it’s like to get from our monthly Assignments day to Release day. The path is littered with unexpected coding complexities, vacation days or unexpected sick kids, competing requests for our time, and technology goblins waiting to wreak havoc on what you’re trying to accomplish. You’re picking up speed as you go, and you’re hoping that you don’t get the high-speed wobble (or worse) before you clear the finish line. You have confidence in your bike-riding prowess, but you still wear a helmet.

Not everyone can be (or even wants to be, for some unfathomable reason) a wordnerd. But everyone on my team plays their part in getting over the line at the bottom of that hill. Sometimes we get our knees or elbows skinned on the way, but we always carry the release over the line. We haven’t lost a rider yet. Including me.