The South Park Technical Writing Manual (Ep. 14)

What can we learn from South Park? Yes, the satirical TV show

There are many storytelling frameworks around. The Pixar one always seems to make the cut when there's a list of the Top Whatever storytelling frameworks.

But one of the simplest is the South Park method. There's a video you'll find on the interweb where Trey Parker and Matt Stone, South Park's creators, explain their approach to a group of students at New York University.

Here's how it goes. List all the key events in your story. If the phrase connecting all the events is 'and then', you're f- finished, yes, that's the word they must have used!

Instead, connect the events either with 'and therefore' or 'but'.

---

Why? • Causality and Conflict • They go on to explain the motivation for this shift. A sequence of events doesn't make a story. The causality between events — the 'and therefore's — and the conflict between events — the 'but's — are the key ingredients that transform a sequence of events into a compelling story. And the conflict leads to a resolution, another key part to most story arcs.

---

Maintaining the Focus • Another benefit of this framework is that it helps maintain the focus. The sequence of 'and therefore's and 'but's helps the story stay focused and prevents the storyteller from meandering from the central narrative.

---

From Satirical Writing to Technical Writing • Technical writing is well-suited to the 'and then' approach. Every topic is always made up of a sequence of events or steps.

However, I argue that we should avoid this. The South Park method applies here, too. If we can connect the events through a narrative, the "story" linking the technical detail helps the reader engage, follow, and understand the topic. We can find causality. And we can even find conflict that we need to resolve.

I'll try to demonstrate the two approaches using an example from Python programming. I'll keep the explanations short—shorter than I usually would—since the purpose of this article is not to teach Python functions. Go to The Python Coding Stack for that!

Let me start by explaining function definitions using the 'and then' approach:

A function is a self-contained mini-program that can be reused when needed. This prevents you from repeating the same lines of code every time you need them to make the code less repetitive and easier to maintain.

You can define a function using the def keyword followed by a name of your choice. The function can have one or more parameters. These store information that's input to the function when you use it.

The function definition includes lines of code that are executed when the function is used. Any data created within the function is not available directly in the main program. You can use a 'return statement' to send information back to the main program.

I did not explicitly use the words 'and then' in this explanation, but I simply presented a sequence of accurate and descriptive facts. This is still the 'and then' style—we don't need to use the words directly, of course.

Now, let me present the same facts differently:

You often need to repeat the same lines of code in a program. You could repeat the lines of code every time you need them. However, this is repetitive and makes the code harder to maintain.

So, you can create a self-contained mini-program that you can reuse. This is a function, and it contains the lines of code that form the self-contained block. You can define a function using the def keyword, but you also need to choose a name for the function to use later. You may want to use the same code with different input information. So, you can create parameters to store these data when you define the function.

But since the function is a self-contained unit, any data you create within the function is not available outside of the function. This causes an issue when you need that information elsewhere in your program. But you can send information from the function back to the main program using a 'return statement'.

This section starts with a challenge that we need to resolve. The function is presented as a solution to this problem. Even the need to choose a name for the function is linked with a 'but'. The addition of parameters is also presented as a consequence of the need to use different inputs.

The self-contained nature of the function, presented as a feature of functions earlier in the section, now presents an issue. There's a conflict, but we can resolve this with the 'return statement'.

Note there are words like 'so' and 'however' to connect ideas and 'but' to show conflict. And even when these words are missing, the context linking sections implies causality or conflict (and its resolution.)

This made-up example, perhaps, is somewhat too artificial. I wanted to present a brief example of the concept I discuss in this post. But the principle applies to longer technical articles. You can change a sequence of facts into a more compelling narrative by linking the elements with 'and therefore's and 'but's instead of 'and then's.

---

Afterword • From late January, I hope to have more time to explore and write my thoughts about narrative technical writing. So, these posts will become a bit more regular than they've been in the past months. But I'm unlikely to try and stick to a rigid timetable as I did in the early days of Breaking the Rules. I'll post whenever I have something to post.

---

---