Programming is a funny (in the sense of “odd”) subject, both to learn and to teach. It’s simultaneously extremely abstract, and incredibly practical. It’s often taught as a way to solve problems in one particular domain (biology, in my case), but the tools of programming (which are really about storing procedural knowledge) are so general that they can be applied to almost anything.
This strange dichotomy of programming-as-a-tool and programming-as-a-way-of-thinking-about-the-world can lead to some degree of stress among people who are trying to learn it. The problem arises because the people who are most excited by programming (and hence are most likely to end up teaching it) tend to see programming as a way of thinking and as a tremendous intellectual adventure1 . Students who don’t see programming as an exciting intellectual adventure (but rather as a tool for getting things done) can often wonder if there’s something wrong with them when they find themselves sitting in a programming class with people who do.
It’s interesting that this doesn’t tend to show up when learning other skills. If you go along to a course in order to learn how to use a centrifuge, you don’t expect to see your fellow students excitedly discussing a particularly elegant loading pattern, or talking about their side-project centrifuge that they work on at the weekend.
The purpose of this blog post is to reassure people who feel that way that: no, there’s nothing wrong with just viewing programming as another tool for getting things done. Yes, there are many fascinating nooks and crannies of programming to explore and discuss, if you like that kind of thing. And diving into different aspects of programming will undoubtedly make you a better programmer. But you’re under no obligation to find any of it interesting. The computer has no way of knowing whether you see writing software as a delightful mental puzzle like doing a crossword, an act of creation like painting a picture, or a tedious chore like picking bacterial colonies off an agar plate2. It will work just the same.
I’m going to introduce an analogy that I’ve often used with my students…….
Last year I moved house. As anybody who has carried out this exercise knows, one of the most delightful3 parts of this job is transferring your possessions from the old house to the new one. In my case, that included several quite large bits of furniture – a couple of sofas, a table, a big bookshelf, etc. In order to move these things, I had to hire a panel van, load the stuff in at the old house, and unload it at the new house.
Now, I don’t have a great history with panel vans. Last time I hired one (for a previous house move) I got it stuck in a deep snowdrift for about four hours – after the first couple of hours of trying unsuccessfully to free it, I had visions of being forced to extend the hire period until the snow melted. The time before that, I managed to rip a hole in the side of the van while trying to park next to a store in heavy traffic.
The actual experience of driving a panel van does not make me like them any more. Because I only have reason to drive one every few years, I have never got used to the width, and am always worried about whether I have enough clearance in tight spaces. Plus, of course, there’s no rear-view mirror so manoeuvring is extra fun.
Suffice it to say, that from my point of view, driving a van is a necessary evil – something that has to be done in order to finish the job of moving house. I certainly wouldn’t want to spend my time talking about different vans, or swapping photos of them, or discussing the minutiae of van driving techniques. The interesting thing, though, is that there are people out there who do enjoy all these things. While for me, vans are a tool for doing a job, to them, vans are a fascinating world to be explored.
In case it isn’t obvious, in this analogy, driving the van is like programming – a tedious job to some (i.e. me), but the best part of the day for others4 . The analogy continues if we think about alternatives to me driving the van. I didn’t absolutely have to do it – there were other options open to me. I could have simply left my big pieces of furniture where they were (I guess this is equivalent to not dealing with datasets large enough to require programming). If I had a friend who owned van and enjoyed driving it, I could have asked them to move the stuff for me (the equivalent of getting a colleague to write programs to solve your analysis problems). Or I could have paid for a commercial moving company to move my stuff (the equivalent of paying for software to be developed when you have a problem).
Despite these other options, and my own distaste for van-driving, I nevertheless chose to do it myself, because I prefer to be self-sufficient when it comes to moving bulky objects. I don’t want to push the analogy too far, but I think that the same applies to programming, especially in the context of a relatively independent career like academic research. For many projects, large datasets come as standard, so we don’t have the option of simply not dealing with them. And in general, we probably don’t want to rely too much on our colleagues to solve our programming problems5. Developing a degree of self-sufficiency with respect to programming is probably worthwhile, even if the experience is not something you find tremendously enjoyable.
Summary: programming languages are like vans; it’s probably worth learning to drive one even if you don’t enjoy it.
This describes me pretty well, as people who know me will testify ↩
if you’re reading this and you’re not a biologist, substitute an example of a boring job from your own industry ↩
Just to keep the analogy going, let’s say that different types of van are equivalent to different programming languages ↩
although obviously collaborating with and learning from colleagues with programming experience is a Good Idea(TM) ↩