97 Things Every Programmer Should Know at W-JAX
Programming has a vast body of publicly available code in which we can see how others have tackled similar or different tasks.
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
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
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
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
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