If you’re a decision maker at your company, you need to be on the bleeding edge of, well, everything. But before you go signing up for seminars, conferences, lunch ‘n learns, and all that jazz, just know there’s a far better (and simpler) way: Subscribing to The Deep View.

This daily newsletter condenses everything you need to know about the latest and greatest AI developments into a 5-minute read. Squeeze it into your morning coffee break and before you know it, you’ll be an expert too.

Subscribe right here. It’s totally free, wildly informative, and trusted by 600,000+ readers at Google, Meta, Microsoft, and beyond.

Hey {{first name | there}},

A question that Divine and I have been asked countless times is some variation of “How do I write good technical content?”

Over the last week, I had some time to distill what I think are tenets of a good technical blog. This is by no means an exhaustive or in-depth list, but more of a guide to approaching technical writing. 

Writing is kinda weird because you need to string together potentially many different thoughts into a cohesive piece that conveys a certain message. Technical writing is a step harder, because not only do you have to make sense, you also have to be factually and technically correct. The last thing you want is (em….AKTUallly), which is inevitable for the most part. You do not want that.

Was this email forwarded to you? Subscribe here to get your weekly updates directly into your inbox.

It is something you might struggle with if you do not write often, but an important thing to note is that there would never not be any new ideas, as stuff is happening every day, and even if not, there is always another angle to approach a topic. 

When writing something, what I always try to keep in mind is that the topic I am on is just the surface, and there is always room to go “one level deeper.” This wouldn’t matter if you have a clearly defined scope, but it is a good rule of thumb when explaining a given concept, as it keeps you on the edge just enough that it does not feel shallow. 

When going one level deeper, you run the risk of writing things that are out of scope. To this, I say you have two options: write it anyway and see how it fits later. “Laterr” could be a 10-15 minute walk away from your desk, and when you come back, you suddenly realize the error of your ways. This isn’t always the case, but the idea is that it would take you a lot more time to try and keep things in scope than to write it out and see if it fits later.  

Besides, going on tangents isn’t all that bad. In one of my favorite write-ups about CPUs, Lexi Mattick goes on several tangents throughout the entire post, which was entirely fine, as you could choose to skip them, and they were explicit about calling them out.

Similar to how everyone speaks differently, so also do they write. Sometimes it seems there is a general convention as to how people write, but some of the best authors, technical and non-technical, write as they would speak. 

I’d argue that if a blog is well written, it is because the author is speaking directly to you, and that's what people want, especially now that everyone is using their favourite LLM to articulate their thoughts. 

Some folks who I think write honestly are Mitchtell Hashimoto, Armin(creator of Flask), although he’s a bit sharper with his writing, and more recently Sam Rose whose writing I find very pragmatic. 

Now this isn’t the full story, as many companies have specific messaging and writing styles that you might have to fit into. In such cases, this is usually outlined in some style guide somewhere, and most times, you can infer it. 

Over time, as you become better at stringing words together,  you will inevitably have to write outside your comfort zone, in which case, the best answer is to structure things with an outline 

My process is usually: 

→ Look up existing articles 

→ Find the best ones 

→ What did they cover?

→ Steal common headings 

→ How can I be one step ahead?

This could be an additional example or a more advanced use case 

E.g: Installing Traefik ingress on Kubernetes 

If everyone were stopping at the installation, perhaps I could show how to route to two services post-install 

An outline would guide you to go one level deeper while staying in scope. 

It's a long path ahead; however, writing and writing content that is not shallow is one of the easiest ways to stand out in this modern age. Being able to point to a body of work speaks to your ability to think, research, and carry out tasks.  Much better than just saying you have done it in the past. 

It is by no means the easiest. Even if LLMs can crank out content, it is nowhere near some of the folks who put in the work to write in earnest.