The Accidental Technical Writer

Image credit: Alexas Fotos via Pixabay

Internal and UX technical documentation were always just a part of the job during my computing decades. However, two self-inflicted projects that were not part of the job stand out and are why I humorously label myself an 'accidental' technical writer.

When Innovation is Needed
At my first computer programming gig while taking my first programming course, COBOL II, I kept encountering textbook instructions that made no sense - or worse, made me feel dumb. I believe in taking initiative to change what needs to be changed for the better, and it starts with analysis of the problem.

Break It Down
I asked questions of the pros. I broke down the process. I played with the parts until I figured it all out. Once clear, I rewrote the instructions in a logical and intuitive way - and I no longer felt dumb.

Make It Accessible
I put those many technical rewrites in a “Cheat Sheets” file and let the directors know, just in case. Much to my surprise, it was the college's computer professors who needed help with the very same instructions that had baffled me! Over the years, it felt good to get a call and have the director ask, "Do you have a cheat sheet on x?"

Sometimes, Be a Rebel
At another company I worked for, our computer coding designs kept getting rejected by management. This stalled our system contracts into overtime. Managements' rejections were based on unwritten rules that changed from manager to manager – and sometimes from day to day. So, I solicited and received permission to write a coding standards manual. It worked. Programmers stopped getting their code rejected, and a system design was written that was so uniformly- and well-documented that the company received a commendation letter from a major government client. Not everything should be standardized, but that which benefits from standardization should be.