How I Prepare to Make a Video on Programming

Over time, I’ve recorded a few videos on programming topics, most recently on the Computerphile channel. For example, one on implementing a programming language was released last week; another on implementing an HTTP server came out earlier this year; and you can find a few more from before that if you’re willing to hunt around a bit. I’ve now had a number of questions about how these came into being, and I thought it might be worth setting out a few quick points from my perspective.

Scope

Let me start with something that might seem obvious, but is worth making explicit: what I know best is programming, and that’s the topic of the videos I’m considering in this post. However, “programming” is a very wide area, and my ignorance is vastly greater than my knowledge: there are many things one can do with programming that I know little or nothing about. Ask me about programming vector graphics systems, for example, and you’ll very quickly realise that I know nothing more than a person on the street.

When I talk on a topic, I aim to have an understanding of not just the direct topic of interest, but enough of an understanding about surrounding topics that I won’t misrepresent them. It’s amazing how often people have questions that require a broader understanding than my direct topic. I don’t expect to be able to answer every such question, but I’ve found that I need to know more than one might expect to even be able to understand the question. Some people worry that they might have to say “I don’t know”, but I worry that I’ll answer a question other than the one I was asked and not even realise it!

Another way of putting this is that I don’t want to mislead people. When I’m conversing with friends, I’m happy to expose my ignorance, because as part of the conversation my ignorance can be corrected. When I’m talking in a video – or a lecture or a podcast or similar – that two-way aspect isn’t present in the same way and my ignorance can cause damage. However, I’ve got to be realistic: I don’t – won’t ever, indeed can’t – know everything and at some point one has to accept that the price of passing on knowledge is that one will say some incorrect things. Fortunately, my ego is robust enough to deal with the consequences of reasonable mistakes.

My aims

What, then, do I want to show people in a video about programming? Ultimately I have two main aims.

What’s possible and plausible

I bundle these two together, because my experience of life is that most of us either don’t know what’s been done already, or we lack a good sense of what we might be capable of doing.

It is (or, at least, was) often said that computers mean that we don’t need to know as many facts as we used to, because we can look facts up. That’s true when I know what I don’t know. However, much of the time, I simply don’t know what I don’t know. In this sense, simply knowing that something is possible changes how I approach life. For example, if I’ve read that humans have climbed Mount Everest, that tells me something about what is possible, even in somewhat different circumstances.

However, knowing that something is possible doesn’t tell me if it’s plausible for me to do in different circumstances. Were I to try climbing Everest in a pair of trainers, shorts, and a cotton t-shirt, I might find that I had incorrectly estimated the plausibility of the task.

In programming terms, I might know that it’s possible to create a web server but if I look at the source code of, say, Lighttpd I might leave with the impression that only impossibly clever wizards can create such a thing. In other words, I might know it’s possible, but I don’t know it’s plausible for a mortal such as me.

If I can show you that we can create a web server that works in real browsers in 25 lines of code, in under 20 minutes, I hope to show that it’s not just possible but plausible too.

Programming is Fun

What I’ve found I enjoy doing is taking digestible topics, breaking them down, and then creating a running program that builds up the solution bit-by-bit. I find that showing the solution evolving in this ways is much more fun, and I think useful, than just talking about the eventual solution. There are some additional advantages to this: for example, I make all sorts of stupid, minor, mistakes when programming, and I’ve found that can help others realise that the mistakes they make when programming are perfectly normal.

I also hope that, in talking about what I’m doing while I’m doing it, I can impart a bit of the joy and enthusiasm that I feel when programming. Writing this down feels decidedly uncool, but I find it bizarre when our culture [1] puts people who seem bored by everything, or who want to destroy things, on a pedestal. Neither path seems likely to bring joy to those people directly, or society as a whole. In the same way that others helped me understand how much enjoyment one can get from programming, I hope to to pass even a little bit of that enjoyment on to others.

One aspect of this that’s sometimes commented on is my sense of “humour” — I like to lighten the presentation with facetious asides. To some extent this is because I was brought up in a family where humour was highly rated. In my case, the raw materials for comedy were, and are, lacking, but my attempts at humour amuse me, if no-one else. As self-indulgences go, there are worse ones.

Planning and recording

By this point I hope you’ve got a sense of what topics I might be able and willing to speak on, and why. What do I do when I’ve got a candidate topic in mind? Turn up, wait for the record button to be hit, and then wing it?

The Computerphile videos are deliberately informal — they’re recorded live and not much material is cut. Someone (hello, Sean!) has carefully edited the visuals (e.g. when to zoom into screenshots) to make them more appealing and helpful, but I haven’t done 17 takes of what I say. Indeed, mostly, you’re seeing the first take. A couple of times I’ve made a stupid programming mistake that’s taken me a minute of head-scratching to fix, and that’s not useful to show, but otherwise I’m happy for viewers to see mundane mistakes as part of the process.

My lazy side might wish for me to turn up and hope for the best when recording, but my conscientious side forbids me from wasting viewers time. If I was to give a talk on a topic I’d just thought about, it would be absolutely terrible. I wouldn’t just make many more small mistakes than normal – though I would! – but the entire structure would be awful. I wouldn’t really know where I wanted to end up and, to the extent I might have guessed a suitable ending, I wouldn’t know how to get there.

For example, I’ve written lots of programming language implementations, big and small, in my time. Indeed, multiple people have thought I know enough about implementing programming languages that they’ve been willing to give me money to do so! However, even though this is an area I feel I know fairly well, when I wanted to show how to create a tiny programming language implementation, I had to think carefully about what I wanted to do. Here are the major steps I remember going through (in order):

1. I could implement a BF language. They’re very small and you can write programs which do surprisingly visually appealing things. However, BF programs are utterly unreadable. I then worried that a lot of viewers would not see the link between BF programs and its implementation.

2. I was then tempted to make a purely stack-based language. However, those are unfamiliar to most of us and – at the risk of further incurring the wrath of Forth programmers – I find them hard to understand after more than a few instructions.

3. I then decided to try and create something that looks like a “normal” dynamically typed language (think Ruby or Python). However, after sketching out a test program, I quickly realised I might end up spending too much time explaining parsing, which I think is the least interesting part of language implementations.

4. After a quick experiment in a couple of languages, I realised that I could use Python’s split function to do all the parsing I needed. This wasn’t just convenient, but meant I only needed to explain how one parsing-related function worked.

5. The smallest vaguely useful function I could think of was factorial, but that required both + and *, which pulled me back towards the horrors of parsing. I then realised that Reverse Polish notation – which is fairly easy to explain and understand for small expressions – would save me having to explain that. Odd though it is, stack-based expressions in an otherwise non-stack-based implementation were a useful fit for what I wanted to do.

6. At this point I had an outline of what I wanted to do: implement a small, dynamically typed language, in Python, with expressions in Reverse Polish notation, and building up to a factorial function. Now I just had to implement it two or three times to get a sense of what a good sequence of steps might be, where I could take shortcuts without confusing viewers, and see if I could squeeze the final code onto a single screen.

How much time did all that take? Somewhere between 1 and 2 hours — let’s say 90 minutes. Imagine if the resulting video had seen me go through that 90 minutes of thinking, experimentation, and dead ends in real time… The result would have been a waste of viewers’ time.

However, just because I’ve prepared doesn’t mean that I stick to my plan without deviation. For example, I’m very happy for questions to somewhat change my path, so long as it doesn’t take me so far away that I might not know how to get to my eventual destination. The aim of my preparation is to be adequately prepared for reasonable levels of improvisation [2].

Closing thoughts

There seems to be a wide audience for good quality videos on programming. Indeed, to the extent I have any sense of trends, demand might currently outstrip supply. The ability to learn in this way is very different from what was available when I was trying to learn to program myself, and I do sometimes wonder if my slow path to competence would have been sped up by such resources!

Nothing I’ve said in this post about how I go about recording such videos will surprise those who’ve done this sort of thing more often than I have. Indeed, since this is something I only have the time to do infrequently, I’m sure there are other people whose thoughts on the topic will be far more fully formed than mine!

I do hope that you don’t leave this post with the impression that I think there’s only one style of video one might want to record — or watch! For example, when I created a video on our parsing error recovery work, I had a very different goal in mind. First of all, I wasn’t being “interviewed”, so it was much more of a “presentation” than the interaction of a Computerphile video. I wanted the resulting video to be as crisp and accurate as I could reasonably make it, so I was happy – using Aeschylus – to record as many takes as necessary to achieve such results.

As that suggests, I think that different audiences have different requirements, and different material should be aimed at different audiences. Perhaps the main thing that links all of these is the importance of showing suitable respect for the audience, both in the sense of adequate preparation and in the sense of pitching the right material at the right audience.

And my final piece of advice might be the most important: if you’re being filmed as part of a recording, don’t go away the night before and pack a linen shirt.

Footnotes

Comments