3 myths about Technical Writing

Rinagreen
6 min readFeb 5, 2022

In Ancient Greece, people mythicized things they didn’t know much about. In the 21st century, people mythicize things that they think they know everything about. And in this article, we will take a look at what people ‘know’ about Technical Writing.

Myth #1. Technical Writers are needed only to create manuals

When we buy a product or download a new app on a smartphone, reading its documentation is the last thing that could possibly come to mind. All modern products strive to be intuitive and user-friendly, then who on Earth ever reads manuals and user guides?

Yet, it’s pretty challenging to assemble an IKEA piece without clear instructions or figure out the meaning of this E2 error code on a treadmill using just one’s intuition.

Ok, manuals can be helpful sometimes. So, let’s have a special person (Technical Writer) who will explain non-obvious things in simple words.

This is how most people perceive Technical Writers without thinking that this profession, along with any other one, is growing in scope proportionally to the complexity of modern technologies. And it’s especially relevant for the world of Information Technologies.

Any easy-to-use IT product hides sophisticated development solutions under the hood. When entering a request into a search line and getting relevant results in the blink of an eye, we don’t think about millions of operations performed during this blink. Multiple software pieces, each responsible for a part of the search request processing, are integrated to ensure a seamless user experience.

In order to maintain and enhance such a product, development teams need to see the whole picture of the underlying complex software system as well as understand the role of each system’s component. And here is where the biggest challenge for modern Technical Writing lies — to provide a holistic perception of elaborate software architecture in simple “human” words.

Not surprisingly, such giants as Google and Amazon have entire units of Technical Writers in their IT departments. And those guys do not create manuals on “How to google” or “How to register on amazon.com”.

Myth #2. Technical Writing is easy

After we debunked the first myth about Technical Writing, it would be wrong to label this job ‘easy’. However, I would like to present a couple more specifics about the profession to prove my point.

1. Technical Writing is not about writing from dictation

When it comes to documenting a product or creating an explanatory article on a complex concept, a Subject Matter Expert is an essential source of information. After an interview, where the SME shares knowledge about how things work, the only thing that a Technical Writer should do is to type the interview, right? But no.

First of all, you can’t create high-quality documentation without a deep understanding. So, the Technical Writer usually does additional research on the subject, connects the dots, and identifies what’s missing.

Then, content design. Who is the target audience, and what are their expectations? How to structure the documentation to convey the information coherently and provide a holistic perception of the concept? What visuals to create to give a better understanding of the idea? These and other questions should the Technical Writer answer before designing documentation. Taking into account strict deadlines, it doesn’t sound like a piece of cake.

Finally, before publishing the final version of the document, the Technical Writer has to define where this document belongs in the information architecture of the Knowledge Base. Making documentation easy to find and navigate is also quite an intricate task.

2. Changeable context as a permanent state

Here, we don’t speak about switching between numerous tasks during a working day but switching between product domains during a working week.

A typical working week of a Technical Writer looks more or less like this. On Monday, you may work on an article explaining the business logic of a particular software module. On Tuesday, you get a request to create a step by step guide on setting up a local development environment for the project. You start working on this piece because Developers are reviewing the first one. On Wednesday, a Product Owner, who you collaborate with for creating a communication map, suddenly has one free hour and is ready to answer your questions. So, you put aside other activities and take this precious opportunity to conduct an interview. Thursday is when you edit Monday’s article according to the comments and suggestions received from developers. And, finally, it’s this end-of-a-sprint Friday, when all development teams present what they accomplished during the last two weeks. You add new tasks to your backlog and finalize this how-to guide started on Tuesday.

What a dynamic week! Would anybody say that such a schedule is not intensive?

Myth #3. Switching from Software Development to Technical Writing is a downshift

This is my favorite one because it has been pursuing me since I made the switch myself.

Before I became a Technical Writer, I had been working as a Software Developer for 2,5 years. Not a significant period, so it was not too painful for me. And while I considered this change a brilliant opportunity, many people in my circle thought of it as a pitch-dark downshift. Some of them politely keep their reasonings by themselves, but others expressed them quite vocally:

  • Technical Writers do not make as much money as Developers;
  • there are no career perspectives and professional growth;
  • with mathematical education, one CAN’T be a Writer, even if it’s a Technical one.

I am pretty sure that I can’t bring those people over, but here is why I think I had one of the best and bravest decisions career-wise.

1. Not about the money but the quality

I admire dedicated Software Developers and well-written code. And at some point, I realized that, in order to become a programmer who writes high-quality code, money is not the right incentive. One has to love coding and be patient about polishing this skill every day, and it is not about me.

I could keep producing mediocre code (just for money) and make my teammates’ life harder when they would have to read this code. Or I could force myself into learning good programming, not enjoying the process (I wonder how long would it take to burn out). Instead, I decided to try myself somewhere else, where I felt I could bring much more quality to the table (I hope this is how it is).

2. Professional growth is not about profession but person

Regardless of what profession one chooses for themselves, it’s up to the person to learn and develop. I firmly believe that we all are creators of our perspectives, not that a particular profession can limit our potential.

Speaking about Technical Writing, the field is relatively young, and therefore there are so many undiscovered routes to pave. With a creative approach and self-discipline, it’s possible to build up a unique, unprecedented professional profile.

3. A background doesn’t define what profession to choose, it widens your horizons

Throughout entire life, a person explores themselves — what they like and don’t like; what people they are comfortable around and not so much; what are their strengths and weaknesses. The same applies to choosing a profession.

Some people know who they want to be from childhood, and they are lucky because they can make life choices that would contribute to the realization of their mission. Other people, including me, have to make some choices at first and, based on the consequences of these decisions, figure out their mission. And when exploring multiple opportunities, we gain valuable experience that will be useful regardless of the occupation we choose.

By the way, I still write code sometimes when it comes to creating add-ons or animations for Confluence articles. And the best part is — I do it without the risk to break Production.

In conclusion, I want to share some personal observations on Technical Writing I recently made. More and more companies all over the globe start seeing Technical Writers as a necessary part of their team. They realize the value that such experts can add to the development of their products. And most importantly, they are ready to invest in Technical Writers’ professional education.

So, Technical Writing is on the rise, and it is not a myth!

--

--