The Joy of Programming


A lot of people seem to be really into Bob Ross lately, probably due to The Joy of Painting recently being available on Netflix, and all the memes that he spawned before that. While popular in the 80s, this TV show was mostly unknown throughout the late 90s and 2000s, until the Internet made it re-enter mainstream.

(if you’ve never seen it, I highly recommend giving it a peep:

Witness the Google trends:

22 PM

And the litany of articles about Bob Ross that have cropped up lately:

There’s even a Bob Ross board game!

It’s hard to hate the zeitgeist in this case - the TV show is plain delightful, each episode being 30 minutes of pure zen bliss, with only the soothing voice of Bob Ross and the sound of brushes against a canvas, with a peaceful image slowly emerging. The viewer is free to follow along, or just watch - but most anyone watching it gets the feeling that they, too, can paint well with minimal time and money investment.

Some have tried to apply this to programming - see for example:

  • A YouTube series “The Joy of Programming”
  • This parodic Twitter account

  • Nicky Case’s just released Joy.js

Others have tapped into shows similar in tone to The Joy of Painting, for instance Daniel Shiffman’s Reading Rainbow inspired Coding Rainbow:

Now, I’m a huge fan of both The Joy of Painting and programming. But I am a bit perplexed by these somewhat forced parallels. Reading Rainbow and The Joy of Painting are amazing TV shows, because they really encourage any child or adult to just start reading, or messing with paintbrushes. This is a wonderful mindset, and it’s laudable that programmers want to bring it to their craft.

But programming… programming is kind of terrible! You can’t just pick up your metaphorical brushes and start coding - you have to spend time setting up an environment, which might well break inexplicably at the next software update. Or the tutorial you’re following is using a previous version of the language, making all of the code outdated. At some point you’ll find yourself stuck because of some minor syntax error due to some stray comma or such that will take you hours to find, if you don’t give up beforehand. For instance, see the aforementioned Joy of Programming video - where the author spends most of the hour murking around in Xcode, a tool with an incomprehensible interface for most. We’re very far from the immediacy of Bob Ross’ painting.

And even if you manage to write some cool code, you can’t just share it with your friends like you would a painting - it might only run on the type of device for which you wrote it, or you might have to deploy it to a webserver which is its own mess, or you might have to worry about being able to run it 12 months later if the company providing your tooling goes out of business/drops support/etc, and so on and so forth. It really is a mess. Now of course some companies offer products to try to make it all super simple and straightforward, but of course you are now bound to the whims and desires of that company. Not exactly the definition of a creative revolution.

Not to mention the fact that some paint and brushes can be purchased for very cheap, and free libraries are everywhere, while computers are still costly for many people in the world, and internet access is far from being ubiquitous.

All of this reminds me of a few friends a while back who had learned how to use Flash because they wanted to get into animation. They spent time and money on the software, books, training, how to use advanced features, etc. - and then Flash became a thing of the past, and the animations they put up on their websites couldn’t even be viewed by most people anymore. Now of course they could have learned a new software package, etc. - but they were amateur animators, not professional ones - and Flash dying was enough of a blow to discourage them from continuing.

I have a few ideas of my own on the topic, but I’d love to hear the thoughts of people here.

  • Can programming be taught as lightly as painting can, or will it always have a part of tediousness to it due to compilers, syntax errors, and the like?

  • Are these attempts to emulate Bob Ross in programming misguided, because programming fundamentally cannot be painting, or is there a path forward?

  • Can programming even be as immediate and accessible as painting or reading? Is it even a good question to ask if it can? After all, no one is trying to make a series of videos for complex technical topics such as “The Joy of Endocrinology” or “California Tax Code Rainbow”.

  • Is there a way forward to remove us from the messiness of programming that doesn’t involve a company doing everything automagically for you, but in the process making your knowledge completely worthless the moment the company drops the product/goes out of business?


I love the connection you make between The Joy of Painting and programming. And I agree: programming is kind of terrible.

On a larger scale in technology we made some tremendous progress: Everybody can become a painter, everybody can become a writer, everybody can become a musician, everybody can become a movie director, etc. Sure, in all these cases you still have some investment to make, but compared to what it used to be in the past, you can start learning most of these things with just a computer and some free or relatively cheap software. That’s great.

What’s bugging me about this, is that we as software designers and engineers create the digital tools for people to explore and learn these domains. Take Apple’s Garage Band for instance to introduce people to producing music: It’s a tool that’s sitting right between being professional enough for people to produce real music or podcasts — sure, eventually they will likely upgrade to a more professional tool, but you can get quite far, especially if you learned with it — but most of all it’s simple enough to get started. Given a little bit of interest in the craft of producing music, Garage Band tries to be fun, it tries to get out of the way, and it tries to nudge you quickly to little successes that feel good and provide the momentum to continue learning.

Same with iMovie (sorry, yes, I’m an Apple fanboy, but that doesn’t mean there aren’t other good examples; I just know these better than others): it’s professional enough to help you create some pretty good results, but it stays simple enough and invites exploration to help you get better at the craft of editing video without giving up in frustration.

For some reason tools for creating programs do not work like that.

Vim, for instance, is not inviting new users to explore programming. Instead it stares at you expectantly when you start it, and then immediately screams at you “If you don’t know what you’re doing, you’re in the wrong place. Go away!”. And then it silently enjoys your struggle to find your way out.

I know, vim is probably the worst example I could’ve picked, and that’s exactly why I did, but even if other editors and programming environments are a little more welcoming, we are so far away from the fun, exploration, and “out of the way” I described above.

Sure, there are things like Sketch, specifically designed for learning, and they provide a much better experience to get started. But they are on the other end of the spectrum, and often fall short when you want to start doing “real stuff”. I don’t think they hit the balance between playful and serious like GarageBand or iMovie do.

Programming today is too much about learning the tools and too little about learning the craft. When Bob the Painter tells you how to draw one of his beloved trees, it’s not about the exact properties of the brush or the canvas or the color. Bob the Programmer has a lot of questions about “your environment” first, want’s to know your editor settings, which are “clearly not optimal, because you’re still using the defaults”, and gives a long lecture about “the right programming language” and the frameworks, libraries, and dependencies “absolutely needed for the problem at hand”, before you even get to the point where you think about what it really is that we’re trying to do.

I’m convinced we can create tools for programming that are hitting that sweet spot between easy to learn and powerful enough. However, we are stuck in a local optima, sitting on top of a comfortable hill with our highly optimized tools for manipulating symbols in text editors to craft cryptic poetry that makes machines dance.

Seriously, this can’t be the best way to do it. But it’s hard to leave this world behind, where we have all these comfortable things like diff and git and filesystems and the magical power of piping streams on a unix command line. Why would we walk back down all the way into the deep and cold and dark valley of uncertainty, into unknown directions, just to cross over to hopefully find one of the high mountains around us which I’m sure are there, somewhere.

That comfortable hill is very crowded these days. Only very few people are willing to leave the hill behind to find out what else is there. Kudos to those brave explorers! I’d expect a few of them likely gathering here.


First I have to say I am loving this discussion! This is a great topic and it’s making my mind race!

This discussion reminds me a little bit of a post I made earlier in the year about programming sketchbooks:

I’m looking through Scott Pilgrim creator Bryan Lee O’Mally’s tumblr and a lot of what he posts are pictures from his sketchbook. I wish, as a programmer, I could have a sketchbook. I can sorta do it. A paper book lets me write my thoughts down, and I can doodle in it too (if I was any good at doodling!). Or I could blog it and let other people read / see it.

But I can’t really sketch out programs in this way. I can’t keep a running diary of code I write. The closest thing I can do is keep a running sketchblog with pictures (or videos) of what I’m working on. I can’t actively share the stuff (at least not in a website format). I guess I could theoretically make an app, but then all my stuff has to become appy (and if it’s an iOS app, then it has to be touch-related). Programs are so tricky, because not only do they have to execute (and usually can only execute in one place / platform), they also often involve affordances (that is, they often have to be used, which implies ways to interface with the program — touch? mouse? keyboard? stylus?). How can that be encompassed in a sketchbook?

And @guillaume I think you hit the nail on the head when talking about how even if you learn enough programming to make something, you’re still at risk of your program breaking in a year when the platform changes or the company goes out of business!

I’ve sort of been thinking for a while now that the whole conceit of software platforms is a little broken because of this. There are so many stacks, so much abstraction, that it’s so fragile. And beyond that, because things are so stacked and abstracted, it’s rare that software is compatible with other software.

Each application is its own island because it essentially has to be, due to the way we represent things in code. Many applications have for example, some kind of User object. But my User object and your User object are probably going to have completely different fields to them, each specific to our given application.

I think the way we write software forces us into these rigid models of reality that mean we can’t easily interchange them. And because of that, it makes it really hard to have general, casual platforms where something like The Joy of Programming might happily exist.

But when you look at painting, it’s a different story, because then we’re working in a shared physical reality. Your paint can almost certainly work on my canvas, and my brushes can spread your paint. It doesn’t matter if we bought them at different art supply stores, because they’re all just clumps of atoms in a shared physical reality. We take this for granted! but it’s something sorely lacking in computing. We can’t mix and match our programs because there’s no underlying shared reality, only abstracted models of it (I also think this contributes to why even professional programming is so damn hard, but that’s another topic).

I don’t really know what to do about this, but it’s something I’d like to explore a bit.

Another avenue to explore would be to consider “what could you program in a joy of programming scenario?” Obviously you can paint whatever you want and you can program whatever you want, but for casual creators, what sorts of things do they like to create? Many of Bob Ross’s paintings are of nature and landscape (themselves generally soothing subjects). What would you “paint” with a program? Maybe you start similarly, and program a little nature scene (flowing water? trees blowing in the wind? weather simulations? bird flock simulations?). Maybe it’s more abstract, like you’d find in Flash / processing animations. It’s not that the particular subject itself matters, only that it might help direct thinking towards what the creative “joy of programming” environment might cater to. So, Joy of Programming what?


This is such a good thread, I need to swing by more often :slight_smile:

I’m the system designer of Glitch which is a basically a web development tool designed around the core assumption that it’s not the programming itself that makes coding impenetrable (although code can certainly be frustrating at times), but mostly it’s all the crap around coding that strangle the creative potential of the medium.

What frameworks should I use? What’s the difference between Java and Javascript? What’s the good one? Do I need to pimp up my text editor? How do I find/use the terminal? What’s a Git?

@stefanlesser’s example of Vim also highlights how intimidating programming tools can be. I think it’s partly due to legacy, partly by timidness, but mostly an industry insecurity around what a ‘serious’ ‘professional’ tool should look like. Vim is our industry’s very own bloomberg machine

That said, I actually think we’re at the cusp of a golden era of expressive tools. New programmers entering the field, or learning to code, are increasingly distant from the old programmer archetype that created and sustain Vim and tools like it. New expectations and better technology are creating markets and opportunities for cool new takes on programming environments like Beach, Vimsical, Codepen, (and also Glitch) to thrive.

I believe we can build tools that take genuinely useful things like version control and package management and make them intuitively approachable.

The hill is indeed crowded, but it’s all dinosaurs up there.



I appreciate your optimism.

This is a really hard problem though, apparently. First, because some of us have been trying for more than half a century, and allegedly we haven’t found a higher hill yet; and worse, we seem to often ignore the learnings from those ancient giants on whose shoulders we could choose to stand on. Second, because it seems like we’re spread thin and waste a ton of resources and clever thinking on re-inventing wheels, instead of getting together and pushing this forward as a team. (Or as proper engineers.)

I’m also skeptical about the market argument. There isn’t really a market in the classical sense for development tools. You can choose between selling a product (if it’s very good and you’re very lucky) to a small number of enthusiasts or you can give away for free something that has a chance to become popular (if it’s very good and you’re very lucky).
These days, you don’t really get buy-in, if people have to buy in.
(See also: any Alan Kay talk from this decade, where he is publicly frustrated about the situation with funding fundamental research, e.g. this one)

Well, I don’t just want to point out the challenges… I do, too, believe in opportunity. At some point someone will come along and find a path to a proper mountain, and from that moment on we’ll be looking back on that hill where all the dinosaurs died and wonder how we could live there for so long…