Casual programming

February 12, 2024

I’ve got three young kids. If you were to spend a day in my house, one thing you’d notice is that there are a lot of alarms going off.

Time to leave for school. Time to brush teeth. Time to finish the bedtime story and get into bed.

Maybe it sounds stressful — but for us it’s the opposite. Making liberal use of alarms and timers makes our daily routine smoother and calmer.

Like many people, I also rely on my calendar app to make sure I’m in the right place at the right time. So naturally, at some point I started wishing that I could make my alarms a bit smarter by combining them with my calendar. For instance, next week are school holidays here in Bavaria — so we obviously don’t need an alarm telling us that it’s time to leave for school.

A small matter of programming

You could think of this as an example of end-user programming. But I’ve always found this term a bit odd, because it implies a dichotomy: either you’re a programmer, or an end-user.

To me, the more interesting distinction is the context of use. I’m a professional programmer, and there’s a whole class of problems that (a) I know I could solve by writing some code, but (b) they’re not really Serious Business™.

My friends over at Ink & Switch captured it well in their essay on end-user programming:

There’s an abyss to cross between using an app and modifying it with code by calling APIs. The user has to switch to a whole other paradigm including setting up a development environment. Consequently, few users take the step from using a tool to customizing or making their own tools.

At Ink & Switch, we believe that software should be extensible in an easy, everyday manner. We believe users want to automate, customize, or even make their own tools without much ceremony.

Lately, I’ve started to prefer the term casual programming for this kind of thing. It’s arguably a slightly different concept than end-user programming. As Bonni Nardi wrote in A Small Matter of Programming:

End users are not “casual,” “novice,” or “naive” users; they are people such as chemists, librarians, teachers, architects, and accountants, who have computational needs and want to make serious use of computers, but who are not interested in becoming professional programmers.

To me, the distinction is important: I’m specifically interested in ways of making the power of programming available in a much more casual, informal way.

Some use cases

Since I’m interested in better tools to support casual programming, I wanted to have a bunch of concrete use cases. So, for the past couple of years, I’ve been jotting down a note whenever I find myself with a need for some casual programming.

The full list probably isn’t interesting to anyone but me, but I thought it would worth sharing some of my use cases. At a high level, there’s one thing that sticks out to me: there’s little computation involved in most of these. They’re mainly about data wrangling and automating tedious manual tasks.

Anyways, here are some of my use cases for casual programming1:


  1. Keep in mind that I’m not saying that thare aren’t already tools or apps to solve these problems. They’re just examples of times when I thought, “If only I could just write a little script to do this…”