Since Dec 26th 2009, I have written regularly on my personal blog on a variety of technical topics. Suffice to say that I have had a lot of practice of technical writing! theburningmonk.com I love learning, and I love sharing. What I learn I like to share through writing, as it also helps me solidify my understanding too. Over the last 3 months, my posts have received around 75K views per month across medium and my blog. So the evidence suggests that my writings aren’t turning readers away at least! So to help more people share their knowledge and insights, here are a few simple rules that I follow when I write. Mind the “curse of expertise” The rule of thumb is to always remember . When you share knowledge & experience, you need to be mindful what assumptions you’re making of the reader. most important you are the expert of your domain Especially when you discuss the merits or problems of an approach. Always state your assumption and context explicitly up front. This helps the reader understand you’re doing this, and the constraints you’re working with. WHY In the immortal words of , , which brings us to the next point. Simon Sinek start with why Sell the problem, NOT the solution “Brad, sell me this pen” Like that great scene in “the wolf of wall street” where asked to sell him a pen. Di Caprio Jon Bernthal Create the demand, then supply the solution. Sell the problem to the reader. Help them understand why it’s a problem solving. The merits of your solution are irrelevant without an interesting and worthwhile problem. worth Where possible I try to set out what a “good” solution would look like, and what properties it should have. After describing the solution I would then finish off with the I have to make. This would usually evolve around the pillars of , and . tradeoffs cost complexity efficiency If you don’t define what “good” is up front, then it’s easy for cognitive biases to creep in. We often subconsciously bend the definition of “good” to fit our solution, and lose objectivity in the process. We all have this , there’s no escaping it. But defining “good” ahead of time helps keep us honest with ourselves. confirmation bias Keep in mind that your solution might only work in specific contexts. If people adopt your solution without understanding the context in which it worked, then they risk failure. Worse yet, if the failures are not obvious enough, then you might have started another … cargo cult Keep it short On medium, you can see how long your post takes to read and how many people read it start to end. Unsurprisingly there is a clear trend that longer posts have a lower read %. I compiled the stats for my posts related to serverless and this is what I see. This is reflected in my personal reading habits too. I tend to finish longer posts over several sitting as I often lose my attention span midway. I’m seldom able to finish a long post in one sitting, even if I ‘m really engaged by it. What that means to you is that you should keep things short, punchy, and to the point. Don’t linger with your words and try to explain things to the Nth degree. If need be, use bullet points, and keep each to one line. Write the post, then read it back a few times. With each run, cut out unnecessary words or rephrase sentences to make them more concise. For example, “to be or not to be, that is the question” might be vague and leaves a lot to the reader. The longer, more expansive version is actually far less clear! Courtesy of Kevlin Henney’s talk “7 ineffective coding habits of many programmer” — https://www.slideshare.net/Kevlin/seven-ineffective-coding-habits-of-many-programmers Be honest Goes without saying :-P Picture says a thousand words Apply common sense, too many pictures is also not good. Also, keep pictures relevant. We all love cat pictures, but too much of it (or used out-of-context) is off putting. Start strong I follow this advice when giving talks as well, and try to kick off a presentation or post with a strong message. Think of your reader’s attention span as a currency. You have to earn the audience’s attention before you can spend them on technical discussions. Conclusions So that’s it, 6 simple rules that I follow whenever I write. The folks also have some for writing on medium. freecodecamp very good advice I hope this post helps you improve your writing. If you have any suggestions on how I can improve my own writing style, please feel free to let me know via the comments below. Happy everyone! Easter

YouTube

Serverless observability, what can you use out of the box?

7 things I learnt from one of the best startups you’ll find

Ask me for help about serverless

Read My Stories

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

here are my top tips on technical writing after 8 years and 700 posts

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

6 Tips To Scale an AppSync Project To 200+ Resolvers That Will Blow Your Mind

The Noonification: OpenAI is Sam Altman; Sam Altman is OpenAI (11/30/2023)

10 Websites That You Should Know About

102 Stories To Learn About Storytelling

100 Stories To Learn About Blogging

10 Tips to Help You Stop Being Your Own Worst Client

6 Tips To Scale an AppSync Project To 200+ Resolvers That Will Blow Your Mind

The Noonification: OpenAI is Sam Altman; Sam Altman is OpenAI (11/30/2023)

10 Websites That You Should Know About

102 Stories To Learn About Storytelling

100 Stories To Learn About Blogging

10 Tips to Help You Stop Being Your Own Worst Client

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps