Musings on technical writing
Technical writing is a job of contrasts. It can be interesting, challenging, and financially rewarding. It can also be frustrating and infuriating. This blog post is a great look at what's involved in being a technical writer.
I really like this list of goals for technical writers from the post:
- Think about what's important. Throw out everything, take a couple hours off with the team early on a Friday afternoon, and figure out what's important. Work on that.
- If you have any design input, try to make the product give the information, or figure out the information, not the person. Maybe rename some menus, try to get things organized logically.
- Make the documentation task-oriented, not feature-oriented.
- Talk to a user. Talk to a lot of them. It'll change your life and how you approach documentation. Go to a training class with real customers. When I taught my first class with my first workbooks, I….well, let's just say the workbooks have changed a lot since then.
- Try to get to those product meetings.
- Get to know the developers. It's not fair that they have all the info and you don't, but if you get to know them they'll tell you stuff. Just basic human interaction. It's a lot more effective than rules and processes and meetings.
- Dare to skip stuff. If people can easily see that the Badger dialog box displays the name and ID of the current badger, why spend time documenting it?
- Remember good techwriting is harder but more fun. Otherwise you're just filling out TPS reports and thinking, as you sit in the bathroom killing time til you get back to your desk, that you only have to do this for 20 more years.
- Keep a quoteboard. It doesn't help with your techwriting but it's fun.
To that, I can add "take your job seriously, but don't take yourself (too) seriously." More on this in a future post.
Related posts:
Great post – you aptkly documented the spirit of good technical writing!