How they handle multi-episode stories in a TV series

Related to: Expecting Short Inferential Distances (yes, linking LW is still a thing).

Below are some remarks I've made in scattered form in several forums, but I thought I'd collect them here.

Problem: A TV series will run for many episodes, and the writers will want to build up a storyline over many of them, which is necessary for a satisfying payoff. But viewers don't necessarily watch it all at once and keep the whole thing in their heads.

I call this the "narrative equivalent" of expecting short inferential distances (see the link above) -- just as people are used to an explanation not requiring a lot of steps, they don't expect a given scene or episode to need a lot of previous viewing to understand.

So, how do writers solve this problem? Here are the four general ways, with examples (feel free to offer more TV series for a category!):

A) Don't bother #1: Each episode is self-contained.

This is known as the "episodic" approach, as opposed to serial. Each episode can be understood without knowing anything about the preceding episodes, so there's no need to worry about this problem at all.

Examples: Star Trek (at least the original or TNG), South Park, The Simpsons (earlier seasons)

Downside: It's hard to feel investment when you know nothing will matter, that things will just return to where they were at the end. It also limits how much build-up (and corresponding payoff) the story can have.

B) Don't bother #2: It's the viewers' job to keep up.

Each episode just assumes you have the entire previous history in your head, maybe with some small reminders of previous relevancies for assistance.

Example(s): Game of Thrones

Downside: It only works for really devoted fans who will binge the whole thing and try on their own to stay up to speed.

C) Formal recaps

You've seen them: the narrator says, "Previously, on [this TV series]...", and then you get enough short clips to establish the relevant context for current episode.

Examples: 24 (after season 1), Battlestar Galactica, Burn Notice

Downside: A lot of people don't like them and think they're cheesy. (I've never understood this mentality, but there it is.) It also may force you to reveal what things from previous episodes will be relevant, taking away their surprise when revealed. There is a slight break in immersion since you have to go "out of the world" for them.

D) In-world recaps

Same as the previous, except you're not taken "out of the world" to do it; instead, there is a scene, within the story, that doubles as exposition of the things a formal recap would cover.

Examples: Breaking Bad, Bojack Horseman

Downside: It heavily constrains how you write the story and forces in pointless scenes that shatter immersion because they're retelling things -- and more slowly! -- the characters should know.

Well, there you have it. That about summarizes the different ways writers handle (or avoid handling) long storylines!

An HTTP status code to say "you messed up but I'll handle your request anyway"

So apparently, the Internet Engineering Task Force is going to introduce a new HTTP status code. Just like there's the 404 for "File not found", we're soon going to have "397 Tolerating", similar to a redirect.

The way it would work is, if you send a request that violates some standard, but the server can identify the probable intent of your request, it will reply with a "397 Tolerating" to say, "oh, you messed up, and here's how, but I'm going to reply to what I think you meant".

This is much better than the options we had before, which were either a) unnecessarily reject the request, or b) silently reply to the intended meaning but with no notice that was happening. This lets you tell the client you're tolerating their garbage!

My contact at IETF send me an early draft of the RFC, which you can access at the link below.

RFC 8969: HTTP Status Code 397: Tolerating

Pastebin Link

My presentation on using SAT solvers for constraint and optimization problems

Because of the virus we had to hold this meetup virtually, and I was slated to present there for the Evening of Python Coding. Since we made a recording of it, I can now share. Enjoy my not-ready-for-prime-time voice! (Yes, I need to update my profile picture ... badly.