Some thoughts on how to teach programming


I almost gave up on becoming a programmer. I took two years of college-level programming in high school and I didn’t particularly care for it. Although I did fairly well in those classes, at the time, I probably had something like the following thoughts about programming:

I’ve given this a fair shake. I’ve taken two years of classes, and I’ve decided that programming is some tedious bullshit πŸ’©. I need to find something else.

I couldn’t have been more wrong. Fred Brooks, programmer, professor, and author of the so-called “Bible of software project management” describes programming in almost the opposite way that I described it when I was in high school. He says:

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures…

At its best, programming is the furthest thing from tedium. On my best days as a programmer, there aren’t really any constraints that could cause tedium in the first place. Its just me and my thoughts/imagination.

Lately, I’ve been trying to teach programming, and I’m actually occasionally seeing some of that same “this is some tedious bs” frustration from my students. At first, I found their attitude frustrating. I wanted to say to them,

Don’t you see?! You’re on the cusp of god-hood! Push through and you’ll be able to build “castles in the air” πŸ°πŸ‘‰β˜ with only your thoughts and your laptop!

However, after reflecting on the rather fortuitous manner in which I overcame those same feelings, I’m more empathetic. More importantly, this reflection has led to some thinking about some things that may be missing in many learning resources that try to teach programming. I want to share my reflection and the thoughts they’ve led to here. That is, I want to talk about:

  1. the fortunate things that happened to me that led me to embrace programming the second time around (spoiler: I learned the importance of clear thinking and found something compelling to build).
  2. how we can be more intentional about ensuring that these things happen to new students of programming.

Fortunate things

So, two things happened that changed my feelings about programming. Both of these things, as I said above, were fortuitous. I had no idea at the time that they’d set me up to enjoy programming the second time around.

First, I studied philosophy for 6 years after high school — 4 years as an undergraduate at UCF and 2 years as a graduate student at Tufts. During those 6 years, I learned how important and difficult it is to think clearly πŸ€”β—οΈ. Good philosophy professors will punish you for unclear thinking, and they’ll show you how much you can gain by taking your time, by wrestling with others’ difficult thoughts, and by clarifying your own thoughts.

When I returned to programming at the tail-end of those 6 years, I was ready to think more clearly. The computer that tried to read my code, it turned out, wasn’t that different from my philosophy professors trying to read my papers; they both punished me for unclear thinking. This time around, when the computer choked on my messy programs, I realized that it was my own messy thinking that caused most of the tedium in my programs.

The second thing that happened to change my thoughts on programming was the proliferation of mobile apps πŸ“± and my realization that I could use programming to build something I would actually use. When I took a second look at programming, I was trying to build a game I wanted to play with my family while I was away in Boston and a mobile app that I wanted to use to keep better tabs on how I was spending my time.

Using programming to build something that I actually cared about supercharged my motivation to clarify my thinking, to write good programs, and to deal with the tedious parts of programming that aren’t caused by unclear thinking. πŸ‘

Being intentional

Many of the existing resources out there for learning to code don’t seem to ensure that learners get both of the following:

  • an understanding of the importance of clear thinking for programming
  • the opportunity to use programming to work towards something they find compelling

This makes sense, as these two features of an ideal programming environment pull against one another. Working towards a compelling goal leads the learner to hurry to see the results of her code. Clear thinking, however, requires that learners take their time.

In spite of this natural tension, I think we can do better as teachers.

One example of nailing the “clear thinking” lesson actually happens in SICP πŸ§™β€β™‚οΈ in the preface to the first edition:

Our design of this introductory computer-science subject reflects two major concerns. First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute. Second, we believe that the essential material to be addressed by a subject at this level is not the syntax of particular programming-language constructs, nor clever algorithms for computing particular functions efficiently, nor even the mathematical analysis of algorithms and the foundations of computing, but rather the techniques used to control the intellectual complexity of large software systems.

Later on in the preface, Sussman et. al. even challenge the idea that “computer science” has anything to do with computers 😰:

Underlying our approach to this subject is our conviction that “computer science” is not a science and that its significance has little to do with computers. The computer revolution is a revolution in the way we think and in the way we express what we think. The essence of this change is the emergence of what might best be called procedural epistemology – the study of the structure of knowledge from an imperative point of view, as opposed to the more declarative point of view taken by classical mathematical subjects. Mathematics provides a framework for dealing precisely with notions of “what is.” Computation provides a framework for dealing precisely with notions of “how to.”


On the other side, one example of educational material that nails the “building compelling things” piece of the equation is Ray Wenderlich’s tutorials. I remember working through some of those when I came at programming a second time. They were a blast, mostly because the thing I was building was much more interesting than a function that could approximate a square root. πŸ™…β€β™‚οΈ


By being intentional about motivating students to learn with compelling projects and by reminding them that thinking clearly is essential to programming, I think we can open up programming to a broader audience and help people learn programming faster. I want to see more resources that look like a mashup of SICP and the Ray Wenderlich tutorials. Does anyone know of any resources that fall into this category?


Cigarettes and Texts: Self-knowledge, Self-control, and Meditation

Maybe We Should Go Easy on Uncle Bob

comments powered by Disqus