People tend to create stereotypes about things they don’t have much insight into. I broke into information development from a different industry, and I’d like to share my own experience of mythbusting.
Before starting my career as an Information Developer, I was a translator and had little awareness of the role and its responsibilities. As a philosopher once said, “Theory without practice is empty”, and I’m glad I got a chance to fill the void and break my stereotypes during the first month of practical experience. Let me share some of them with you.
Technical knowledge is an absolute must
Before stepping into the role, I wasn’t too tech-savvy. I always thought that the level of technical competence of a translator would not be enough to become an Information Developer. It was so NOT true! When I started as an Information Developer, everything was indeed brand new and unusual for me. It might not be an easy nut to crack, but with proper initial training and your desire to dig deep, the sky is the limit. At this job, you are constantly learning, and not only the technical side of the software you are dealing with, but you also delve into the target industry, such as finance, law, military, banking and so on. The knowledge you gain with every new project is invaluable.
Information development = technical writing
It is one of the most common misconceptions that information development is just about writing the documentation. In fact, the actual writing part takes up to 30% of the time, while there are a lot more functions that an Information Developer performs on a project, such as:
- Creating training materials for all kinds of users
- Keeping and processing project knowledge
- Interacting and helping other team members with documentation
- Assisting Business Analysts with writing user stories
- Testing the software and detecting bugs as a QA Engineer
- Cooperating with UI/UX Designers regarding the wording for the UI
Information Developers could also provide some ideas about how to improve the software to make it easier and more convenient to use because after documenting every feature of a program, they know all the ins and outs.
Hard skills go before the soft skills
I must admit that I largely underestimated the role of soft skills for an Information Developer. I falsely believed that in order to be successful in the job, my main goal was to master the language. But I couldn’t be more wrong. Soft skills, such as sociability, ability to work in a team, critical thinking, and active listening, go arm in arm with linguistic and technical knowledge. Without people skills, you wouldn’t be able to get any information about the product from your knowledge holder on a project. And not just from them. You need to participate in all team discussions and meetings (including informal ones!) to get the most updated and accurate information. Otherwise, you could end up figuring out what, why, and how on your own.
Writing docs isn’t as important as writing code
Many people undervalue the part of the overall project load that falls on the Information Developer’s shoulders because documentation is often considered secondary to the application and its functionality. I can now strongly disagree with this – there will be no worth in an application if the users have no clue how to use it.
Another misconception is an Information Developer being a secretary for engineers who just automatically copies the information onto a document. What is missing here is that you actually ask how and why, use critical thinking and creativity to give just enough details in a comprehensible form.
The more scholarly and sophisticated the text is, the better
I used to belong to those people who believed that technical documentation should be technically intricate, and plain language would show your lack of professionalism. But in fact, the situation is the exact opposite! Your level of skills is determined by the ability to cut the clutter and simplify even the most complex information. Your major weapon should be minimalism. Information Developers treat documentation as a means of helping users, without overwhelming them with long chapters full of unnecessary details. Sticking to the main principles of global English will make your writing clear and engaging for any reader, regardless of their background. And that’s the main goal, isn’t it?
There probably exist more myths about the job, but I hope I’ve managed to debunk at least some of them. Please share in the comments the misconceptions that you had and your own mythbusting experience!