The Half Life of Programming Knowledge

Programming is hard. I relearned this lesson recently.

From time to time, I go on a decluttering spree at home, throwing / donating / recycling things I haven’t used in a while. Last week, the bottom row of my bookshelf caught my eye — because it had a number of programming books. I do write code as part of my job — though it isn’t the main part of my job description. But I hadn’t touched these books in years. I decided to recycle these:

While these books served as a reminder of past jobs and adventures (I have been an embedded systems programmer, built networking systems, designed large scale log processing and analytics and helped build a non-profit), they were quite obsolete. After a few minutes of consideration, I decided to get rid of these as well:

My library of programming books somewhat reflect my career. My masters thesis was on object oriented databases (written in C++). My career started in a organization that was in the midst of a massive software re-architecture. The architects there had been bitten by the object-orientation bug and it infected me as well. We used Smalltalk and Design Patterns. Later, I became a C++ aficionado, dabbling in template meta-programming (don’t ask!) but haven’t used C++ in over a decade. I learned just enough Perl to fix some obscure scripts that I only half-understood. Ruby was thrilling for a while — but like the rest of the industry, it has faded in interest for me. I’m not sure why I have the compiler book from my undergraduate studies — maybe I wanted to write a Domain Specific Language (DSL)?

I have retained a few books:

The C++ books are just there for nostalgia. I still work a lot in networking, although I don’t use these books. The pink book is ‘The Little Schemer’ — after Object Oriented Programming’s demise(?), perhaps only functional programming can save us (I also have a book on Clojure in my Kindle library). I remember trying to learn Scala, CoffeeScript and Lua and a few other languages.

My current programming languages are Python and Go (and bash !). For both, online references suffice.

The decluttering exercise reminded me of how hard it is to learn programming, how much I have forgotten and how much I didn’t actually learn. I also realized that I have not bought any books on programming recently. There are many reasons for this:

• Great free content. Thanks to open source, I can now grok a piece of code in a language new to me and somewhat understand it. When I started my career, the only code one could read was the code written by colleagues. Thanks to communities like StackOverflow, I can learn from other programmers faster than I can learn from a book.
• Software is disposable. Although I like to think that I write great software, the truth is that a good piece of it is never-or-under used. Admittedly, it is a pleasure to write and read idiomatic code, and I cringe when Python code is not PEP8 compliant, but in truth, it only matters some of the time. Going deep into a particular programming language doesn’t have the payoff.
• Programming languages go through fads. It was always interesting to debate the pros-and-cons of C++ vs Java vs .Net vs Javascript, but in the end it rarely mattered (counter-point). Does it matter if your code is highly optimized if it never reaches the market?
• As a generalist, I have to switch languages every day. It is hard to get deep into one language when the other languages in my toolbox have different APIs and frameworks to do the same thing. As a result, a quick reference (Google!) tool gets the job done better than a book.

Knowledge decays very quickly in the software field. If I were to advise my younger self, I’d urge younger-me to pay less attention to language wars, less focus on software elegance and less time on shiny new languages (Groovy, Clojure, Scala, CoffeeScript…). That doesn’t mean one should learn only ONE language. Rather, when faced with a new language, one should learn how the old patterns apply, figure out what is new and see if it can quickly be put to productive use.