15 Editing Habits That Separate Professional Technical Writers from Amateurs
The gap between amateur and professional technical writing is rarely talent — it is habits, most of them applied during editing rather than drafting. Amateurs publish their first draft. Professionals treat the first draft as raw material and do their real work in the revision passes, where clarity is actually manufactured. Almost every tip in this article is something you do to a draft, not something you do instead of drafting.
What follows is a set of concrete, repeatable habits used by working technical writers. None require special tools; all require discipline. Apply even half of them consistently and your documentation will read as noticeably more professional. For the foundational skills these habits refine, start with our beginner's guide to technical writing, then come back for the polish.
Write Ugly First, Then Edit
The most important professional habit is separating drafting from editing. When you try to write and perfect simultaneously, you stall — the internal critic freezes the internal generator. Professionals draft fast and ugly, getting the complete shape of the content down without worrying about word choice, then switch modes entirely and edit hard. The messy first draft is not failure; it is the required input to good editing.
This separation also produces better structure. Once the whole draft exists, you can see that section three should come first, that two procedures are really one, that the introduction is unnecessary. You cannot see the shape of a piece while you are still generating it sentence by sentence. Draft to discover what you are saying; edit to make it clear. Treat these as two distinct jobs done at two distinct times.
The Sentence-Level Habits
At the sentence level, a handful of edits do most of the work. Prefer active voice — "the system sends an email," not "an email is sent by the system" — because it names the actor and is shorter. Use second person and imperative mood for instructions — "click Save," not "the user should click Save." Cut filler: "in order to" to "to," "is able to" to "can," "at this point in time" to "now." Turn nominalizations back into verbs: "perform validation of" becomes "validate."
Keep one idea per sentence and aim for an average well under 25 words — long sentences hide the action. Put the condition before the instruction ("To export, click Download"), because readers who don't need the action can stop reading sooner. The Google developer documentation style guide is an excellent free reference that codifies most of these at the sentence level. For deeper cutting technique, see our article on textual efficiency.
Structure and Scannability
Professionals structure for a reader who scans, not one who reads every word. Use descriptive headings that state what the section delivers — "Configure SSL certificates," not "Configuration." Lead every paragraph with its point (the topic sentence), so a reader skimming left edges still gets the gist. Convert any sequence of actions into a numbered list and any set of parallel options into a bulleted one; prose paragraphs are where instructions go to die.
Break dense content with code blocks, tables, and screenshots so the eye has anchors. Keep procedures to one action per step — if a step contains "and," it is probably two steps. Add a short "expected result" so readers know they succeeded. The goal is that a competent reader can complete the task by scanning the numbered steps alone, treating your prose as optional backup.
Getting Terminology Right
Amateurs vary their word choice for elegance; professionals repeat the exact same term every time. In technical writing, using "delete," "remove," and "clear" interchangeably for one action forces the reader to wonder whether the differences matter. Pick one term per concept and never deviate. Maintain a short glossary or controlled vocabulary and, ideally, enforce it with a linter like Vale so banned synonyms get flagged automatically in review.
Match your UI exactly: if the button says "Sign in," write "Sign in," not "log in." Define specialized terms on first use, then use them consistently. Beware unexplained jargon and undefined acronyms — spell out an acronym the first time it appears. Consistent terminology is also what makes documentation cheaper to translate, since translation memory tools reuse identical segments. This discipline is the heart of any good style guide.
Testing Your Instructions
The habit that most separates professionals: they actually follow their own instructions on a clean system. Reading a procedure back is not testing it — your brain fills in the missing steps because you know what you meant. Following it literally, on a fresh install or account, exposes the assumed prerequisite, the skipped click, the step that only works because you were already logged in. Every gap you find this way is a support ticket you prevented.
Better still, watch someone unfamiliar attempt the task and say nothing while they struggle. Their hesitations pinpoint exactly where your documentation is unclear. For developer content, run every code sample yourself — copy it from the rendered page, not your editor, and confirm it works. Untested instructions are guesses, and readers can tell. Documentation is a promise that these steps work; testing is how you keep it.
Building a Repeatable Editing Pass
Turn all of this into a checklist so quality does not depend on how alert you feel. A repeatable pass might run: first, structural edit (is the order right, anything missing or redundant?); second, scannability (headings, lists, topic sentences); third, sentence-level (active voice, cut filler, shorten); fourth, terminology (consistent terms, defined jargon, UI matches); fifth, testing (follow the steps, run the code); sixth, a final proofread ideally after a break so your eyes are fresh. Running the same passes every time makes your output reliably good rather than occasionally good.
Read the draft aloud on the final pass — your ear catches clumsy rhythm and run-on sentences your eye skims past. Darlo Technical Writing's Professional Editing for Technical Writers course teaches this exact multi-pass workflow with graded exercises, and includes a downloadable editing-pass checklist you can pin beside your keyboard. Explore all our programs at /courses.
The Technical Writer's Editing-Pass Checklist
A pin-it-by-your-keyboard checklist covering the six editing passes — structural, scannability, sentence-level, terminology, testing, and proofread — used by working pros.
What's the single most impactful technical writing habit?
Separating drafting from editing. Write a fast, ugly first draft to get the whole shape down, then switch modes and edit hard. Trying to write and perfect at once stalls you and produces worse structure, because you can't see a piece's shape while still generating it.
Why should I repeat the same term instead of varying my word choice?
In technical writing, using synonyms like delete, remove, and clear for one action makes readers wonder whether the differences are meaningful. Pick one term per concept and use it every time. Consistency reduces cognitive load and makes documentation cheaper to translate via translation memory.
How do I test documentation before publishing?
Follow your own instructions literally on a clean system or fresh account — reading them back doesn't work because your brain fills in gaps. Better yet, watch an unfamiliar person attempt the task in silence; their hesitations reveal exactly where the docs are unclear. Run every code sample yourself.