Advice for Technical Writing
In advance of a recent podcast with the incredible technical writer and Smashing Magazine editor-in-chief Rachel Andrew, I gathered up a bunch of thoughts and references on the subject of technical writing. So many smart people have said a lot of smart things over the years that I thought I’d round up some of my favorite advice and sprinkle in my own experiences, as someone who has also done his fair share of technical writing and editing.
There is a much larger world of technical writing out there. My experience and interest is largely about web technology and blogging, so I’m coming at it from that angle and many of the people I quote throughout are in that same boat.
Picking something to write about
If you want to write for CSS-Tricks and you ask me what you should write about, I’m probably going to turn that question around on you. It’s likely I don’t know you well enough to pick the perfect topic for you. More importantly, what I really want you to write about is something that is personal and important to you. Articles rooted in recent excitement about a particular idea or technology always come out better than dictated assignments.
My best advice:
Write the article you wish you found when you googled something.
— Chris Coyier (@chriscoyier) October 30, 2017
That said, I do maintain a list of ideas specifically for this site. Any writing can be done on assignment and sometimes that elicits the spark needed for something great and on-target for the audience of a site.
Write at the moment of learning
The moment you learn something is the best time to write. It’s fresh in your mind and you can remember what it was like before you understood it. You also understand what it takes to go from not knowing to knowing it. That’s the journey you need to take people on.
If you don’t have time, at least try to capture the vibe wherever you save your ideas. Don’t just write down “dataset.” Write down some quick notes like, “I didn’t realize DOM elements had a .dataset property for getting and setting data attributes. I wonder if it’s better to use that than getAttribute.” That way, you’ll be able to reload that realization in your brain when you revisit the idea.
What have you learned in just the last few days? I bet there is a blog post there. Manuel Matuzovic does an excellent job of putting this into practice with the “Today I Learned” (TIL) section of his blog.
Comparing technologies is an underused format
Here’s some advice Rachel shared that I don’t see taken advantage of nearly enough:
There is a sweet spot for writing technical posts and tutorials. Write for the professional who hasn’t had time to learn that thing yet, and link it back to things they already know. For example explaining a modern JS technique to someone who knows jQuery.
— Rachel Andrew (@rachelandrew) February 20, 2019
Tell me about how this new framework relates to Backbone. Tell me how this CMS relates to WordPress. Tell me how some technology connects to another technology that is safe to assume is more widely understood.
Technology changes a lot, but what technology does doesn’t change all that much.
Careful with that intro
The main comment I add on tutorials I review is to ask for an intro that describes what the tutorial is about. I’m 600 words in and still don’t know what the tutorial is about and who it is for. #writing
— Rachel Andrew (@rachelandrew) January 5, 2018
Not getting to the point right at the top of technical articles is a dang epidemic. The start of a technical article is not the time to wax poetic or drop some cliché light philosophy like, “Web design sure has changed a lot.” You don’t have to be boring, but you do need to tell me what this article is going to get into and who it is for.
“Does the title make the article sound interesting?” If the title interests a reader, they’ll typically read the intro and decide, “Is it worth my time reading the whole thing?” A common mistake I see in a lot of technical posts is either too much introduction or, alternatively, far too little.
A single well-written paragraph can set the stage for a technical blog post.
Careful with the title, too
I remember a conversation from years ago with content strategist Erin Kissane where she strongly advised me to choose boring titles for everything. Not just the title of blog posts, but for everything, including the names of sections, tags, and even subheadings within posts.
Here’s the thing with boring: it works. Boring isn’t the right word either; it’s clarity. The world is full of clickbait, and maybe that’s effective in some genres, but technical blogging isn’t one of them.
A nice clear blog post title: Getting Started with GraphQL, Phoenix, and React by Margaret Williford
A terrible version of the same: Build a web app with modern technologies in 30 minutes!
What’s a web app? What technologies? What’s modern about them? What’s with the weird time limit?
SEO matters and Margaret’s article is going to do a lot better in both the short and long term with that clear title.
The outro
Ben Halpern says that the next most important thing after the intro is:
[…] the last paragraph.
People don’t read top-to-bottom the moment when they arrive, so there is a good chance it’s the second paragraph people read. Personally, I find the beginning a lot more important than the ending, but there is a certain art to the ending as well.
A lot of people just
Conclusion
and write a few words about what was just went over. Honestly, I don’t hate that. It falls into this time tested pattern:
- Tell ’em what you’re gonna tell ’em
- Tell ’em
- Tell ’em what you told ’em
That helps your message sink in and brings things full circle. Technical blogging isn’t terribly different from marketing in that sense. You’re trying to get people to understand something and you’re using whatever tricks you need to to get the job done. A little repetition is a classic trick.
Make it scannable
[…] the wall of text can be easily be made less intimidating and appear much more visually appealing through the use of visual elements that break it up. The easiest is to simply place section subheadings throughout your post.
I agree: subheadings are probably the easiest and most powerful trick for scannability.
Other methods:
- Lists: Like what I’m doing right now! I didn’t have to use a list. Paragraphs might have worked as well, but a list makes contextual sense here and is probably tricking some of you into reading this. Or at least scanning it and getting some key points in the process.
- Images: Please make them relevant and contextual. Skip the funny GIF. Screenshots are often great in a technical context because they provide a visual to what might otherwise be a difficult concept to explain. I like Unsplash for thematic imagery, too, but you can do better than a random picture of trees, a woman drinking coffee, or a random rack of servers.
- Illustrations: The abstract nature of an illustration is your friend. It tricks people into having a quick thought about what you are describing. They generally take a little work to pull off, but the pay-off for you and the reader can be huge.
- Videos: You can’t simply drop a 42-minute video in the middle of a blog post, but if you can make it clear that you are demonstrating something visual and the video is less than a minute, it can be a powerful choice. You’ve always got
as well to make it GIF-like. - Blocks of code: Technical blog posts are often about code. Don’t avoid code, embrace it. I love how Dan Abramov sprinkles in code blocks in blog posts not so much to demonstrate syntax and setup, but to make points. I’m going to recommend Embedded Pens as well, because they’re fully interactive demoes in addition to serving as code blocks.
- Tables: Don’t forget about tabular data! Presenting information (particularly data or definitions) in a table makes it more understandable than it would have been any other way.
- Collapsing sections: The
Whatever you pick here, you should pick things that help enhance the points you’re making even if in some ways it feels like trickery. It’s trickery to help readability, and that’s a good thing.
My favorite technique? A little bit of design. Use design principals like spacing, color, and alignment to help the readability of posts. We even go so far as to art direct some posts where design can enhance the central point being made.
The point here isn’t to do away with walls of text altogether. Sometimes that’s exactly what’s needed because you’re asking a reader to deeply read a passage that they otherwise wouldn’t get what’s needed from the content. However, more often than not, a post can strongly benefit from some healthy use of white space.
Use an active voice
I find this one a little tricky to wrap my head around, but Katy Decorah has a great presentation about technical writing that explains this point in great detail. It’s kinda like using present tense and stating a point directly rather than passively.
Passive: “After the file is downloaded…”
Active: “After you download the file…”
Passive: “The request is processed by the server.”
Active: “The server processes the request.”
Here’s another clear explanation with examples by Neal Whitman, read by Mignon Fogarty (Grammar Girl):
There are lots of words to avoid
“Just” is a big one. Brad Frost:
“Just” makes me feel like an idiot. “Just” presumes I come from a specific background, studied certain courses in university, am fluent in certain technologies, and have read all the right books, articles, and resources. “Just” is a dangerous word.
There are plenty of others to avoid, which which I’ve written about before. Read the comments in that last link. Long story short: there are lots of words that do more harm than good in technical writing, not only because they can come across as preachy, but because they usually don’t help the sentences where they’re used. Try taking “just” out of any sentence. The sentence will still make sense without it.
Be mindful of your tone
Tone is concerned with how you say something in consideration of the context. For example, you wouldn’t deliver bad news to someone with a happy tone. The way you express yourself ought to be aligned with the situation.
This is our tone goal on this site:
Friendly. Authoritative. Welcoming. We’re all in this together. Flexible (nondogmatic about ideas). Thankful.
MailChimp has a very extensive guide to theirs.
It’s worth pointing out that tone and voice are separate concepts. I like to think of voice as never changing (it’s your personality which is a part of who you are) while tone changes to suit the context. In other words, you can have a professional voice while communicating in a friendly tone.
I don’t think there is one true tone that is perfect for technical writing, but since the high-level goal of any technical writing is to help someone understand something complicated, you can use tone to help. A joke in the middle of a set of intricate steps is confusing. A bunch! of! excitement! about something might feel out of place or disingenuous, but being drab and lifeless is worse. I’d say if you’re writing under your own name, let’s feel a little bit of your personality as long as it’s not at the cost of clarity. If you’re writing under a brand, match what they have established whether it has been codified or not.
Careful about length
The general tendency in technical writing is to write too much rather than too little. Wade Christensen:
Whether trained by school assignments with word minimums or just uncritical, most of us write too much. Beyond approaching each draft with a ruthless cutting mentality, there are several ways to write short from draft one.
Word limits can help, even if they’re self-imposed.
I heard from a fledgling editor recently who struggled with his writers submitting posts with high word counts, so he suggested they keep it to 1000-1500 as a guideline and that seemed effective. This post is roughly double the high end there, for comparison.
The real solution, if the resources are there, is ruthless editing.
I personally don’t find that writing too long is the only issue. I’ve had just as many occurrences of writers going too short and not digging into the topic deep enough. I don’t like focusing on the length; I like focusing on the clarity of the delivery and usefulness of the content itself.
Side note: Breaking up a post into multiple parts (as separate posts in a series) is not a solution for posts that are too long. In fact, it can exacerbate the problem. Do that only if the different parts are thematically different and can stand alone without the other parts.
Don’t stop yourself from writing
There is an invisible force, built from fear, that keeps a lot of people away from technical blogging. “Meh, everybody already knows this,” you might think. (They don’t). “What if I’m wrong and someone calls me out?” (You aren’t wrong if what you’re doing is working for you.)
There can still be blockers even if you overcome those fears and start putting words to screen. Here’s Max Böck:
There is a thing that happens to me while writing. I start with a fresh idea, excited to shape it into words. But as time passes, I lose confidence.
The trick for Max is not to wait too long and to ignore feelings holding you back:
I’ll publish something as soon as I feel confident that all the important points I want to get across are there. I try to ignore the voice screaming “it’s not ready” just for long enough to push it online.
Jeremy Keith goes so far to say we shouldn’t even keep drafts:
I think keeping drafts can be counterproductive. The problem is that, once something is a draft rather than a blog post, it’s likely to stay a draft and never become a blog post. And the longer something stays in draft, the less likely it is to ever see the light of day.
The chances that your writing helps someone is pretty high! Matthias Ott:
Even the smallest post can help someone else out there.
Think you’re too inexperienced? You’re probably not, but even if you were, a perspective from someone with less experience is still useful. Ali Spittel:
If you have a blog post that contains mostly correct information, or at least your interpretation of the topic, then you’re experienced enough. There are lots of excellent posts out there from the perspective of newbies, and they’re really important!
Fear is a real thing in writing and dealing with it can be debilitating. While it’s primarily geared toward creative writing, The War of Art by Stephen Pressfield is a good read to help break through the fear.
There is no one perfect style
We each have our own unique perspectives and writing styles. One writing style might be more approachable to some, and can therefore help and benefit a large (or even small) number of people in ways you might not expect.
…says Sara Soueidan. She continues:
Just write.
Even if only one person learns something from your article, you’ll feel great, and that you’ve contributed — even if just a little bit — to this amazing community that we’re all constantly learning from.
Technical blog posts don’t have to be devoid of creativity. You could create a wonderful technical blog post that is an annotated chat room conversation between two developers learning from each other. Or a blog post that is a series of videos that build on each other.
The more introductory, the higher the bar
The web is saturated with beginner-rated and surface-level blog posts. There’s a sea of crash courses, 101s, and intros out there. You’ve gotta knock it out of the park if you want to stand out from the pack and be useful.
There is no particular change in tone necessarily for a beginner-focused post. You don’t need to do the equivalent of talking slowly or talking down. You only need to be clear, and clarity is valuable to readers at any skill level, not to mention appreciated by them as well. A very advanced programmer can and will appreciate the clarity in a technical blog post even if it’s something they already understand.
But the bar isn’t that high in general
You don’t need a decade of experience to write a blog post. I’d say it’s closer to a day of experience, a desire to write, and having something to say. I think you’d be surprised at how little you need to do to make a blog post stand out and be read. Put in some effort, make clear points, focus on readability, and you will do well.
I hope the advice in this post helps!
Abstraction is helpful, but real-world examples are sometimes better
It’s one thing to describe a high-level concept, and another to explain or illustrate how that concept applies to the real world. In technical writing, you’ll often be covering complex or hard-to-understand subjects, so it’s even more important to use a well-placed example or two to showcase why your topic matters, or how it relates to the real world.
I find myself pushing back on code that is too abstract more than I push back on code that is too focused on a real-world use case. I’d rather see ["Charles Adok", "Samantha Frederick"] than ["foo", "bar"] or [a, b] any day, but more importantly, what is then done with that data to make it feel like a relatable programming scenario.
But avoid real-world examples that come at the cost of clarity. If abstraction is useful to drive a complex point home without getting lost in the details, so be it.
Blogging opens doors
Everyone I’ve ever met who had ever actively blogged has said that blogging has had a positive impact on their career. Besides being a public demonstration of your ability to think and present ideas, it helps you understand things better. To teach is to learn.
I’d attribute my own blogging as the biggest contributor to any success I’ve had. Here’s Khoi Vinh, a designer ten times more successful than I’ll ever be:
It’s hard to overstate how important my blog has been, but if I were to try to distill it down into one word, it would be: “amplifier.”
You get better at what you do.
There is no way around it: practice makes you better. The expectations around practice are sometimes very clear and culturally ingrained. In order to get better at playing the piano, you take piano lessons and practice. We all know this. But people also say “Oh, I’m a terrible cook,” as if cooking as a skill is somehow fundamentally different than playing the piano and doesn’t require the same amount of learning and practice.
You get better at writing by writing more. That is, writing with stakes. Writing and then publicly publishing what you write such that people read it.
You can go to school for writing. You could get a writing coach. My thinking is nothing teaches better than writing often. Whatever it is you sink time into is what you end up getting good at. Is 10,000 hours a good framework for you? Go with it. Heck, I find even people that sit around watching a lot of TV end up being pretty damn good at watching TV.
Your voice alone < A story with context < Stories including others < Research and data along with stories including others
An article where you just say some stuff is OK. You’re allowed to say stuff.
But you can do better.
An article where you tell a true story about how something worked for you is better. Context! Now we can better understand where you are coming from when you say your stuff. Plus everybody likes a story.
An article where you combine that with quoting other people’s writing and stories is even better. Now you’re painting a larger picture and helping validate what you’re saying. Context and flavor!
An article where you combine all that with research and data is the best. Now you’re being personal, acknowledging a world outside yourself, layering in context, and avoiding being too anecdotal. Kapow! Now you’re writing!
Are you pitching?
Read what the site says about guest writing. Here’s ours.
Not to scare you off, but 90% of submissions are garbage. Maybe 75% is outright spam and another 15% are people that clearly didn’t read anything we had to say about guest posting and are way off base. I can usually tell from the quality of writing in the email itself if they’ll be a good guest blogger.
I say things like that, and then feel compelled to remind you the bar isn’t that high.
Are there any useful tools?
There probably is, but I don’t wanna link you off to tools I can’t vouch for. All I use is Dropbox Paper for collaborative writing because the sharing model is easy and allows for co-editing and commenting. Plus Grammarly because it catches a ton of mistakes as you go.
??
The post Advice for Technical Writing appeared first on CSS-Tricks.
