by Malte Skarupke
I recently came across this article about 10 papers every programmer should read. Now I don’t necessarily agree with all of that list, but here is the important part: I am about to finish a Master’s degree in computer science, and I have never heard of any of those papers before.
That is a list of papers which are sometimes more than 40 years old. Some of these gave us the assumptions that are normal for us to make about programming these days. I learned programming in the past ten years, and I had to rediscover some of this knowledge myself. I have made mistakes in programming that should never have been made, because people had solved those problems years ago. And I still see people make those same mistakes that I’m now smugly smarter about.
So what is there to do about it?
Well the obvious thing is that every programmer should take a history of programming methods class. Just to understand where the behaviors that we now implicitly do come from. A class like that would just force you to read, say five papers of your choice that are older than ten years old. You have to write five short texts, and present two of your chosen papers in class. That could have been really useful for me.
The biggest problem that I see with that class is, that you only appreciate some wisdom if you have made the mistake yourself that it is the solution to. But still I’d argue that a class like that is useful, because even if you don’t appreciate the knowledge right when you first hear it, it’s useful to have heard it once so that you can remember how things should be done when you run into a problem.
The other thing that you can do is teach people. When you read something on the Internet, find a way to get more people to know about it so that they don’t repeat old mistakes.
So I’m going to shorten that top 10 list to the 3(+1) that I liked most:
1: The paper Lisp: Good News Bad News How to Win Big by Richard P. Gabriel, which you only have to read chapter 2.1 of, which isn’t really about Lisp. It talks about the concept, that coding “the-right-thing” only leads you towards an enormous amount of work. Instead the author argues for a “worse-is-better” approach where you write code that’s slightly worse, but simpler. Who hasn’t made the mistake of designing a system that handles every possible case and has the cleanest possible interface with functions that could never fail? You can probably design a system like that, but you can’t code and maintain it in a reasonable amount of time. In that situation it’s liberating to know that your code shouldn’t be doing “the-right-thing.”
I would very much encourage you to actually read that chapter. Because it talks more about the concept, and even though you don’t want to be doing the-right-thing, in the long term you want to strive to be pretty close to what the-right-thing would have been. Also while rereading this I have found it relevant to game design. When reading it think about Minecraft vs AAA development. Minecraft fits the worse-is-better mentality: When it first became popular it was not complete, but it had all the parts that counted, and it didn’t matter that it was worse than current games in many areas.
2: The paper Arguments and Results by James Noble. This presents some design patterns about function arguments and return values. None of these are terribly complicated and you can certainly re-discover these by yourself without reading any papers. But: While reading that paper I got ideas for how to improve one of my interfaces that had bothered me for a while. And I had had the same ideas for solving my interface issues that this paper presents, but I hadn’t had the courage to try them by myself because I wasn’t sure whether the result would be clean. It was just reassuring to know that I was doing something proven that has a name.
3: Reflections on Trusting Trust by Ken Thompson. This is just a fascinating piece about how you can not even trust software that you have the source code to and that you have compiled yourself. You could become completely paranoid after reading this paper, but really it’s just about how you’re always forgetting one angle when thinking about computer security.
And since there is one more piece that I wish more people had read, I’m going to extend my list by a fourth link which wasn’t on the original list:
+1: Things You Should Never Do, Part I, by Joel Spolsky. Which is about rewriting code from scratch. Two student game teams in my year rewrote their engine from scratch for their second game project. Which turned out to be a big problem for them. These are people in the Master’s program who already have a Bachelor’s in computer science. None of them had read this piece, and neither had I at the time. I was lucky that I thought that I could write a better engine by rewriting only the bad parts of our previous engine. But I had nothing but a gut feeling to lead me there. It would have been really useful for all of us had we read this piece at some point during our Bachelor’s degree.
I’m currently thinking a lot about holding a presentation at the end of the semester for next year’s Master’s students. And I will tell them about these old pieces of wisdom, and I will tell them to not repeat the mistakes that our year made. So that I can at least get a cycle of learning from old knowledge started in this program.