I’ve just watched Bret Victor from the recent DBX conference.  If you haven’t seen it the link’s at the bottom, you’ll be glad you did.  The rest of this post has spoilers and I wouldn’t want to ruin your enjoyment so go watch it first, my little rant can wait.

I spent the first 15 minutes of the talk giggling at the references – He’s using an OHP! He has pens in his pocket!  He stayed in character the whole way through, it was great.  I couldn’t stop laughing.

Then I spent the rest of the talk crying over the decades of lost opportunity as he laid out "recent" history, to show how little of this history we know, and how little we’ve built on it since then.  We knew all this in 1973? Why have I only just heard about it!

George Santayana’s saying has been frequently quoted that: "Those who cannot remember the past are condemned to repeat it".

Most programmers don’t know history.  Most programmers don’t want to know history.  We say it’s irrelevant, that earlier solutions are not relevant to today’s problems or to today’s hardware.  We have a culture of inventing solutions from scratch, but actually just re-inventing a narrow range of solutions that we are comfortable with.  There are still plenty of commercial software projects that won’t even use open source code, preferring to spend time writing their own logging and database persistence libraries instead of using existing solutions that are safer and more performant.

This is why programming is failing as an engineering discipline, as suggested by Bret at the end of the talk.

Learning from the past is a standard part of other disciplines. Architects study old buildings, the materials, the techniques.  Engineers study old designs, how the forces were resolved with different generations of tools and mechanisms.  Doctors study the history of drugs and treatments as the most modern drugs may not work for every patient.

Artists study art history.  Artists!  Not the most disciplined lot.  You think of them in a scruffy loft spraying paint on the floor or pickling animals to get attention (sorry to my artist friends, just trying to make a point).  You don’t think of them sitting in a room studying and practicing other artists’ techniques to understand them and understand how and when to apply them.  But any time I’ve been to an art gallery that’s what I see, art students learning from what came before so they are equipped to better apply their own vision.

But programmers, despite a reputation for obsessive attention to detail and anti-social levels of introversion, have no idea what the last generation of programmers did.  This exaggerated reputation is no longer justified but the profession does attract many quieter, studious types.  But this is only partly true: detail-oriented yes, but not research-oriented.  We don’t like facts, we like problems.  Or more accurately we like puzzles, we like solving problems.  That is where a lot of the satisfaction from our work comes from.  We don’t want to know someone else has already solved it in 1968. We want to solve it ourselves.  We feel like we are inventing something, pushing the future, when really we’re just redoing something that was done already, stuck in the past.

My own excuse is that I didn’t do Comp. Sci., just picked up programming on the side.  So I don’t know how much history is taught, but I don’t see any appreciation of history in programmers I know who did do Comp. Sci.  If I had done Comp. Sci. and if it actually did include history, thinking about who I was at that age I don’t think I’d have cared then.  Even if this had been taught I don’t think I’d have listened then.  I gravitated to programming exactly because I enjoyed the mental exercise of solving puzzles, of getting the computer to do my bidding.  I was interested in programming as an active thing, not a learning experience.  It was only later that I started reading and learning from other people’s experiences which has expanded my programming toolbox.  But my default approach is still to attack a problem directly with the tools and techniques I already know, rather than to see who else has already solved the problem and learn from them.

And I’m worried that programming in general has the same problem.  We are teaching language syntax and problem solving but not introducing new programmers to the history of the discipline.  Museums of technology show the history of computer hardware (mainframe to mini to micro to PDA), sometimes show the history of user interfaces (teletype to green screen to WIMP, Pong to Space Invaders to Doom), and occasionally the history of computer languages (COBOL and FORTRAN to C and BASIC to C++ to Java and C# with Lisp and Forth as footnotes) but not the history of code itself.  Books like "Beautiful Code" or Kevlin Henney’s talk on "Cool Code" are a wonderful surprise because we’re invited to read old code so rarely.

And it’s not just the same code that we’re stuck in, Bret’s vision is much wider.  Computers have completely changed many other disciplines.  CAD for engineering, diagnostic machines for medicine, CGI for cinema, word processors and spreadsheets have changed every single office.  But programmers are mostly still using the same tools and solving the same problems as 30 years ago.

So thank you Bret Victor.  Thank you for thinking differently.  Thank you for reminding us that we can too.

Links:

• Bret Victor on The Future Of Programming: http://worrydream.com/dbx/
• Bret Victor’s website: http://worrydream.com
• George Santayana on wikipedia: http://en.wikipedia.org/wiki/George_Santayana
• Damien Hurst with cow in a jar: http://www.theguardian.com/artanddesign/2011/mar/03/damien-hirst-tate-modern-olympics-sehgal
• The National History of Computing at Bletchley Park: http://www.tnmoc.org/
• Beautiful Code By Andy Oram, Greg Wilson: http://shop.oreilly.com/product/9780596510046.do
• Kevlin Henney – Cool Code: http://vimeo.com/44792649