Category Archives: Technical Writing
Agile got (at least) one thing right: stop writing documents no one’s ever going to read. If you want to honestly assess what will or won’t be read – and therefore what should or shouldn’t be written – you should … Continue reading
First let me clarify – I’ve nothing against HR and their involvement in the hiring process. What I object to very specifically are two habits: letting HR choose who gets interviewed, and letting HR do the first interview and veto … Continue reading
Three things some technical writers say that should serve as a warning sign that you may not want to hire them: “I only need to understand it at the UI level”. If you don’t understand how and why things happen, … Continue reading
Technical writers have a very clear goal: explain the interface. That means they notice, instantly, when it’s inexplicable. If your interface is a confusing mess with overly-complicated procedures, buttons that make no sense, important options hidden in sub-menus and related … Continue reading
The only way to improve, the internet keeps telling us, is to push yourself past your comfort zone so that you’re always learning new things. Writing day in and day out, however, can mean you start to churn out documents on … Continue reading
Here’s a quick writing tip for user manuals: don’t add your images to the manual until you’re done writing your text. This has two advantages. The first is that when you add images one at a time over the long … Continue reading
There is a general problem in software, more pronounced in minimalist Agile efforts, of documents that look good at the time of writing, but do a poor job of transferring information. I call these “stump” documents because readers are stumped … Continue reading
I’ve written about good questions to ask technical writing candidates. There are, of course, many more good questions you could ask. There are also many bad questions you shouldn’t bother with. Here are five types of questions you should avoid.
Lessons I Learned as a Tester, 4: Testers Should Write the First Draft and Approve the Last Draft of Release Notes
You might say I learned this lesson as a technical writer, too.
These questions are for experienced candidates, not aspiring writers, and are meant to reveal general attitudes and methods. You want to see how people think, and how they act and react to other writers.