Technical Writing is Different from Other Positions in IT
How it is different from other jobs in IT (development or QA)
- There are no automated or pre-defined parameters to test your documentation. Developers can run their code and see if it is fine, test engineers can run scripts and map their test cases against the system functioning. However as a technical writer, you CANNOT verify your document against a pre-defined set of parameters’ to see if it is correct. You use your experience. Of course there are facilitators such as Style Guide, Templates and Process, but it all comes to your experience and writing skills. There is no way you can have a system that ensures that the language is correct and meets its objective. Does it mean that you are at a disadvantage? Certainly Not!
- In development, a software engineer who has developed many ecommerce sites and Facebook applications can feel frustrated or stagnated if one continues to get same kind of product development tasks, or to fix bugs in same or similar products (of course exceptions are there). In technical writing, you are constantly doing something new. Even if it is same product, you get to write fresh instructions. Some procedures are always new and at least you write new sentences. You do not have a for loop or a once-written login module that you can use in every document (like many developers do). You have the scope to be creative, within the parameters. And you get to learn and update yourself on new technologies just as other professionals.
- A technical writer works with astonishing attention to details. You cannot afford to miss a full-stop even in a 140 page manual; it is a crime. It is a huge satisfaction when you tell your documentation manager that the document is complete IN ALL RESPECTS.
- Research suggests that technical writers are generally more satisfied and enjoy greater job satisfaction as compared to professionals in development, QA or UI design.
Where it is REALLY DIFFERENT!
- Technical writing is quite an individualistic job, and every individual thinks differently. No two individuals can write a procedure or a paragraph in exactly the same manner. So while working in a team, one needs to agree somewhere that they are not doing documentation for themselves. Rather, they are doing it for the business, and then the organization whom they work for. When I compare it to development, there is a difference. To write code of a feature, there can be one particular way where different team members can agree that this is the best (most effective or optimal) way to do it. This is not always true in technical writing. You can think why not the way ‘I write it’ when there is nothing wrong in it? This is a dangerous sign if the individuals fails to realise that somewhere, they all need to agree on ‘how to write’.
- When a Documentation Manager reviews a document, the original writer who wrote instructions should:
- Understand that sometimes there is no reason or justification of ‘why this way’ because there are no definite answers. The most valid answer is ‘this is so’ because ‘this is how we do it here’.
- Understand that the comments are not to highlight writer’s mistakes. The comments are for the ‘document’ and not the ‘writer’, so writer should not take it personally. Many newbie’s find it difficult to accept comments because they think that they are right (or that they are not wrong). But when they revisit these situations after 2-3 years of experience, they laugh at themselves, they have learnt many valuable lessons the hard way.
The career graph is upwards for experienced as well as for newbie’s. The demand for good technical writers is increasing and is expected to increase in next few years. However, it also calls for diversified skills in tools and deliverables.