This is the sixth and final part of our series on how to write a tech blog that reads well. If you wish to read the previous entries, here is a table of contents linking back to all the previous articles!
Article #1 – Fundamentals & Essential Practices
Article #2 – Structuring Your Blog & Presentation
Article #3 – Style
Article #4 – Common Pitfalls
Article #5 – Opening Your Blog
Article #6 – Closing Your Blog And Explaining Difficult Concepts
Closing Your Blog
Like titling, this is another topic in which we have a discrepancy between a blog’s style and its efficiency in terms of generating traffic. If you’re trying to get clicks, then final paragraphs are very important, and I will once again link a helpful guide on how to write an SEO-friendly conclusion.
In terms of just good writing, however, conclusions carry a lot less weight than openers. If a reader has stuck with you until the end, it’s unlikely their reading experience will change much based on the final paragraph (unless you really write something beastly).
How should a conclusion be written? There are two possible answers, which depend on the type of article you are writing.
For technical articles with an objective register, it’s every bit as simple as writing the opening, and more or less the same logic applies. First, declare that the article has reached the end, then express your hopes or best wishes. For example:
This concludes our overview of the best text editors on the market. We hope our article helped you make an informed decision. Remember that the editor has to fit your needs, not the other way around, and of course – happy coding!
That’s pretty much all you need. For more stylistically sophisticated articles, there are two things you want to have in your conclusion.
Firstly, clarification of potentially contentious points. If you wrote an article about why it’s a good idea to be more assertive in the office, you don’t want that to be interpreted as telling people that they have to be jerks to each other. That’s something you (should have) already specified in the body of the article, naturally, but make sure your final paragraph includes a reminder in that sense. Just to be sure.
Secondly, and this is considerably more difficult to pull off, you want your article to finish with a little bit of a punch. This isn’t something very easy to teach, because what you’re looking for is a memorable phrase – and what that is depends heavily on what you wrote in the article, and how that final phrase reflects on that. A few things you can do in this sense include:
Vivid imagery or metaphors
These usually stand out in an article, although they take some creativity and inspiration. If you can find a metaphor, a simile, or an image that relates to the topic you have been discussing, use that to wrap up your argument. It will give your reader’s mind something concrete to carry away from the article, and a powerful mnemonic object that lets them remember what you said. Here are a few quick pointers on writing metaphors, and they mostly work for similes and imagery in general.
Statement of belief or emotion
You can make your final sentence resonate simply by turning it into a short statement about how you feel, ideally related to the general argument you have discussed in the blog. For example: ‘Anyone can and will find a job if they take the time to learn Python. I believe that.’ Or alternatively: ‘As I left my job with Apple, I told my friends that I would never return to backend development again. And I meant every last word.’ The trick here is to make sure that the final, short statement is definitive. You’re not going to pack any punch by saying ‘I’m pretty sure I believe that’ or ‘I meant what I said, to an extent’. It’s the definitiveness of those sentences that, coupled with the relatable intimacy of a personal feeling, makes them memorable.
A less personal variation of the above, this just means closing your article with a short sentence, ideally one that ends with a verb. For example, ‘Hundreds of developers turned to Laravel to profit from their skills with PHP. And they did.’ It’s possible to play around with this, of course; the sentence doesn’t necessarily have to end with a verb (‘And they did just that’). But the principle is the same as the above, except this time you create rhetorical impact not by relating the reader to a personal emotion, but to some form of action in the real world.
If you’re really struggling to find an apt conclusion for your blog, even with the above suggestions, then an easy way to close is to Google famous quotes based on key words that can be related to your article. If you wrote an article about job hunting, you can Google quotes on ‘perseverance’, and then end your article by saying ‘Remember, as the saying goes, it’s often the last key in the bunch that opens the lock.’ This is a passable method, but it’s also a bit of a cop-out, and you really don’t want to abuse it. Readers will start noticing if you do this too often, and eventually it will just come across as lazy (because it is).
EXPLAINING DIFFICULT CONCEPTS
Knowing how to explain concepts that are difficult to understand is mandatory if you write blogs in tech. Here are a few techniques that you will want to make use of.
Use diagrams, charts and other pictures
I cannot stress how important visual aids are when explaining abstract concepts. In most cases the mind can process an image much better than it can process words. So use diagrams, draw out concepts visually, and represent data as charts and graphs. Even if all you do is screen-grab a snippet of code from your console, do it. It helps.
Pictures aren’t just useful in their own right, they also break up your text both visually and conceptually. Readers will associate pictures to concepts, and therefore ‘map out’ your article as they read it.
How to create a good diagram is a question beyond the remit of this article (and frankly beyond the expertise of this writer). Ideally, you should be able to find ready-made pictures online to help you out. Otherwise, you should keep pictures you create relatively simple, with straight, geometric lines and patterns, and liberal use of primary colors. Consider drawing stick figures too, and don’t worry about them looking rudimentary – they will add a human, relatable element to your image, which offsets any issue about how ‘pretty’ it is.
Writing about difficult concepts
Let’s move on to the actual writing bit of explaining difficult concepts. Here are a few pointers that you should always keep in mind.
Language matters, tone doesn’t
Most blogs out there that cover how to explain difficult concepts suggest using simple language and short sentences, and writing in an informal, light tone. The former is essential – keep complicated vocabulary to a minimum, and avoid long sentences wherever possible, as they will make it even harder for your reader to focus.
The latter, on the other hand, is a myth – keeping your tone casual doesn’t necessarily make your explanation(s) more accessible. You can use a dry and formal tone if you are more comfortable that way, and as long as you keep the language simple, it will be just as clear.
The ‘jargon horseshoe’
Jargon that is key to the topic you are talking about must be defined. If you are explaining what SQL is, you can’t gloss over the fact that it stands for Structured Query Language. But how and where in your blog should you bring this up?
The answer is: you should say it twice – once at the very beginning of your explanation, then one more time at the very end. The first time you mention it serves to give your reader an anchor. Here’s what we are explaining, here’s what we’re talking about. No room for ambiguity.
The second time comes at the very end of the explanation, once the concept is (hopefully!) clear in the mind of the reader. Make sure that defining jargon is the first and the last thing that you do whenever you explain a difficult concept. (It goes without saying that all of this holds for necessary jargon; complicated terms that are only indirectly relevant to what you are talking about should simply not be used).
Now that we know how to start and end our explanation, what should be the meat of it? The answer is in two parts.
First, employ a metaphor or a simile to describe the topic you are writing about. This can be challenging – it’s like having to explain your topic by explaining something else instead. Make it as visual and as situational as possible, allowing the reader relate to something familiar.
For example: ‘If you want to understand what a PHP engineer does, imagine somebody who can play the violin. A professional violinist is an expert with a tool that is mostly associated to outdated music, but in reality is one of the best things that can be learned to find paid work, as it’s extremely flexible and used in more or less every genre.’
See what I did there? Everybody knows what violins are and more or less understands what their role is in the world of music. (This is a metaphor I actually carried much further, by writing an entire article based around it).
Once you have used a metaphor to ground the reader in the concept you’re discussing, then you can pass to a more technical, nitty-gritty explanation of your topic. Again, just keep the language simple and straightforward, and use diagrams alongside.
One word of advice though – avoid mixed or extended metaphors. If you want to explain what frontend and backend are, you should devote two separate metaphors to each explanation, rather than try and think of a single idea that can accommodate both. It may be seductive to try the latter solution, and some very talented writers can pull it off wonderfully, but in practice you are playing with fire. The more elements you put into any metaphor, the more likely you are to complicate rather than to simplify things.
You can expand on your explanation by linking out to other articles (yours or anyone else’s) that explain the inessential parts of what you are talking about. If you are trying to convey a sense of what a Data Scientist does, and you touch on the topic of programming languages, you can link to somebody else’s article comparing Python and R. That may not be the topic of your blog as such, but it’s a useful expansion for anyone who wishes to delve deeper into the topic.
In summary then: Use lots of pictures combined with simple language, then follow the structure of a.) definining jargon, b.) illustrating with a metaphor/simile/analogy, c.) going for the technical explanation, d.) once again going over jargon. All of this should be enough to give your readers a good understanding of what you are talking about.
This concludes our extensive series on how to write a better tech blog! The irony is not lost on me that I just explained how to close a blog, and now found myself in the position of having to close this blog. I have already revealed my cards!
No tricks or techniques then. I hope this series was useful to you, and I wish you all the best. And if you feel like seeing some of the principles I talked about in practice, check out one of my favorite blogs about our graduate student Imogen Drews. Keep writing!