Once Upon an Article (Pilot Episode)

…because Once Upon a Technical Article didn't sound right. What's this Substack about? (If only I knew)

It's my first post on Breaking the Rules. And I'm going to disappoint you.

You are not my intended audience. Sorry.

I'm writing Breaking the Rules for an audience of one—me. How selfish is that?

Luckily, as I'm still at the beginning, there aren't many subscribers to lose. But I hope you'll still stay for a bit longer.

---

My journal • This is my journal. A place for me to write down my ideas on technical writing, to jot down things I read in books, articles, and some research papers too, and how I interpret what I read in the context of communicating about a technical subject.

I still haven't decided on the exact format—what to write and how to write it. Maybe there won't even be a fixed format. Maybe several. Stick around to find out.

But most posts will be brief and raw. Any long treatise or opus will be very rare.

My personal experience in technical writing is in physics first and programming in Python now. So, some examples I write about will be biased towards these fields, especially the latter. But these posts won't be just about programming articles. Many of the ideas apply to all technical topics.

---

Where I stand as of today • I've been keen to experiment with technical communication ever since I wrote my PhD thesis all those years ago. I couldn't go over the top when writing my thesis for obvious reasons. And I was never brave enough to deviate from the norm in scientific journal papers I wrote.

The first time I recall thinking, "I'm going to do this my way", was when I was preparing for the first course I taught at university as a young lecturer. I was teaching optics to clinicians. My average number of slides per lecture went from about 30-40 in the first year I taught the course to just a handful by the time I left academia. What I said and how I said it was more important than any bullet points I put on the slides. I hardly had any text left on the slides in my last year as a lecturer. The students seemed to like it, based on their votes at the end of the year.

Long story short—let's fast forward to today. I'm very aware that my preferred way of learning is to visualise abstract concepts. The articles I like to read most are the ones that are entertaining as well as informative. They're the ones that lead me through the technical detail in an unconventional way, perhaps, keeping my interest piqued, and my mind alert.

So, I choose to write the articles I'd like to read myself.

---

Stories • Stories have been a cornerstone of every society in history, shaping and reflecting the norms and views of those societies. There's a reason why stories are everywhere. They work in passing on a message that the audience will understand well and recall.

But there's science to back the power of stories, too. In future posts, I'll talk about the science of storytelling. We learn better through stories.

I no longer follow many of the "rules" you read in classic technical writing guides. But that's fine with me. I'm OK with Breaking the Rules.

I've been reading about, thinking about, and practising narrative technical writing for a long time. But I've never written about it…

…until last week in a guest post on

The Tech Writers Stack

. Here's my "treatise" on narrative technical writing in full (it’s a long read, unlike the future posts on this Substack): The Different Flavours of Narrative Technical Writing. I'll cross-post the article on this Substack, too.

Here's the executive summary of the article. When I look at how I try to include aspects of storytelling in my writing, I see three categories:

• Narration through analogies

• Narration through story-framing

• Narration through technical detail

There's a fourth one, too, sort of: the choice of language and writing style.

I'll be talking more about each one of these in future episodes of Breaking the Rules. I’ll break each one down. I’ll give examples, anecdotes. I’ll look at research about how humans react to stories. It’ll be fun for me. Hopefully for you too.

Episode 1, the first real post, comes out next week. I'm aiming to publish my musings on Wednesdays. But since there are no rules, and if there were, I'm likely to break them, who knows?

In the meantime, if you want to see some practical examples of the type of writing I'll talk about, you can have a look at my other Substack on programming using Python.

---

Afterword • There's a bit of pressure with the first post on a new venture such as this Substack. I'm re-reading what I just wrote, and I can see there's a lot of "Me, me, me" in it. Oh, dear! But I guess the main point of this first post is to tell you that I'm not the source of all definitive knowledge on this topic. Or any topic, for that matter. And that I like to make my technical writing more narrative than the norm. I guess you know that by now.

---