97 Things Every Programmer Should Know at W-JAX
At this year's W-JAX conference in Munich, independent consultant and trainer, Kevlin Henney, will gives attendees an insight into the 97 Things Every Programmer Should Know project, in a session that promises to share code that has historical importance. In this interview, we speak to Kevlin Henney about his '97 Things Every Programmer should know' session, and the 'Cool Code' keynote he will run as part of W-JAX.
JAXenter: 97 things every Programmer should know – that is a lot to keep in mind! Can you tell us a bit about the thoughts, that led to the creation of the 97-Things-every-Programmer-should-know-project?
Kevlin Henney: I was inspired a few summers ago when I was thinking about a piece of code I'd seen, specifically code that made a false assumption about floating-point numbers. I muttered something along the lines of "Dammit, that's just one of those things that every programmer should know!", which immediately put me in mind of the book 97 Things Every Software Architect Should Know. I had contributed to that project, led by Richard Monson-Haefel, and knew that O'Reilly was interested in publishing a '97 Things' series. My interest in programming practice and the possibility of this project seemed a natural fit.
One thing that attracted me to this project was the open-sourced and crowd-sourced approach to gathering the advice. Anyone can come up with a personal list of 97 pieces of advice, but they will likely be written in the same style and from the same perspective. While this gives obvious consistency, it also inevitably misses some points of view and freshness of variety. There are contributions to 97 Things Every Programmer Should Know I simply would not have thought about had I been making my own private list.
JAXenter: In your 'Cool Code' session, you talk about programmers not having the opportunity to study much code, outside of the code they maintain. Why should programmers study existing code?
Kevlin: I think programmers do have the opportunity, but they often don't realise that they need to consciously make an effort to make and take the opportunities.
The main act of programming is composition. As with any other form of composition, there are lessons to be learnt. How can we express ourselves clearly and effectively? What idioms simplify (or complicate) code? What techniques make the impossible possible ,or the difficult easy? Programming has a vast body of publicly available code in which we can see how others have tackled similar or different tasks.
If you were studying creative writing, you could not do it effectively without studying the writing of others. If you were studying building architecture, you would study existing buildings. If you were studying mathematics, you would familiarise yourself with the proofs and techniques of other mathematicians. Why is programming any different? Knowledge work requires knowledge; existing code is one source of such knowledge.
JAXenter: In your keynote abstract you mention code examples that have historical significance. I'm curious what those could be – can you give us a sneak peak?
Kevlin: We have over half a century of significant code behind us. Some of this code has changed the way we can program and think about programming. John McCarthy's realisation that a language can be written in itself is still as mind-bending and relevant today as it was when he invented LISP, for example. Although there is code for code's sake, most code also does not exist in a vacuum, and some has a direct connection to historical events outside software development itself. For example, the code used on the Apollo Lunar Module is publicly available and surprisingly revealing.