This message could be simpler

Hey {{first name | there}}. I estimate I spend about three hours of my day thinking about how to make things simpler.

In an age where a 4,000-word essay is a prompt away, I often find the best responses from an LLM are the ones that directly answer my question. A wall of surrounding text usually leaves me looking for the answer somewhere in the middle.

The same applies to my own writing.

In today's technical notes:  

If you have paid time left on an individual Granola plan, we'll match it with a Wispr Flow subscription that includes Notetaker and dictation, and add bonus time, up to 12 months total. Sign in or create a Wispr account and submit proof of your plan to check eligibility.

Try Notetaker Free

Similar to the folks who think software engineering is dead, it is easy to think writing does not matter as much in the age of LLMs. I beg to differ. Now more than ever, I think it is important to develop a personal voice.

Anyone can generate a project and a few paragraphs describing it. What makes me interested is hearing why someone built it, what they struggled with, and how they arrived at their decisions.

Those are also the parts I want to get better at communicating.

A personal voice comes through in the examples you choose and the opinions you can explain. If I disagree with a common approach because it caused problems in my own work, that experience belongs in the write-up.

Writing also makes me sit with an idea long enough to find the gaps. Sometimes I get halfway through explaining something and realise I need to go back and understand it properly.

That is still useful work, even when a model can finish the paragraph for me.

For a long time, I thought the best pieces had loads of fancy words. After several years of writing, the pieces I look back on or reference often are the ones that got the main points across as clearly as possible.

This is usually where most of my editing happens.

I look for introductions that take too long, paragraphs that repeat the previous one, and explanations that assume the reader already knows the thing I am trying to explain.

There is a balance here, though.

“The request failed” is short, but it tells me very little. “The API rejected the request because the token had expired” gives me something I can work with.

When I remove words, I still need to leave enough information for the reader to understand what happened.

Closely related to less being more is pacing.

I could have opened this issue with “use simple words, give examples, and edit your drafts.” You would have the advice in ten seconds, but very little to help you apply it.

Pacing involves giving an idea enough room to make sense before moving on.

If I introduce an unfamiliar concept, an example can help the reader settle into it. If I have just shown a block of configuration, I should explain the relevant lines before introducing another one.

I also try to think about what the reader is likely to ask next. Once I have explained the problem, they probably want to know how to solve it. That is a useful guide for deciding which section comes next.

The main answer can appear early. There can still be plenty worth reading afterwards.

I often fall victim to this. Everything I have in my head apparently needs to fit into one draft.

Sometimes it is okay to split things up.

A guide to setting up homelab backups can help someone get their first backup working. Testing a restore deserves enough attention that it might need its own piece.

Each part should still do something useful on its own. I would want someone to finish the first guide with a working backup, even if they have not opened the next one yet.

Understandably, people will not give every article their full attention. But if a piece helps them solve a problem, there is a reason to come back.

My process usually starts with getting the rough version down. I need something to work with before I can decide what to keep.

From there, I work through a few questions:

That gives me something concrete to revise. I can then decide whether the suggested change improves the piece and whether I would actually say it that way.

🧠TOGETHER WITH EVERYTHINGDEVOPS

📺The ONLY 5 Cloud Skills That Matter In 2027

AI can now write Terraform, deploy infrastructure, and follow runbooks. So what does that mean for cloud engineers building their careers?

The skills worth focusing on are shifting towards the work that requires judgment, context, and a solid understanding of how systems behave.

This video breaks down five cloud skills that appeared across multiple expert rankings, including one that showed up in all four. It also covers why each matters and how to start building it.

Subscribe: @EverythingDevOpsHQ for deeper dives on agents, Kubernetes, MLOps, and AI infrastructure.

Paul Graham  Write Simply

A short essay on using straightforward language and spending more of the editing process cutting unnecessary words. A fitting read for this issue.

Julia Evans — How do you write simple explanations without sounding condescending?

Julia discusses keeping explanations accurate, knowing your audience, and retaining useful technical terms so readers can search and learn more.

Diátaxis — Start here

A useful framework for separating tutorials, how-to guides, reference material, and explanations according to what the reader needs. Worth exploring if your technical documentation keeps trying to do everything on one page.

What is a piece of technical writing you keep going back to because of how well it explains something? Reply with a link. I would love to read it.

Know an engineer who will find this helpful? Share this link with them

Jubril Oyetunji
CTO, EverythingDevOps