Afterwood

After serving many years as the playroom (nay, ‘dumping ground’) the kids have finally grown-up to the point at which it can serve as something a little more refined. The need to redecorate has created the impetus required to pull the books off the shelves and have a sort out before putting them back in what I hope is a more ‘logical’ order. The room now takes on the grandiose title of ‘library’, not by virtue of the number of books, it has less than before, but simply because the ratio of books to other ‘crap’ is such that they now dominate significantly, and you stand a chance of being able to use the sofa and chairs for actually sitting down.

Having my programming books share the same space as the family’s other books is a fairly recent event. Prior to this they were stacked on shelves in the downstairs toilet until gravity conspired with Jeffrey Richter et al to cause the shelves to sag and bow to such extent that they made the occupants using the facilities as nature intended to become deeply uncomfortable. Richter wasn’t the only culprit, although he seems to have a penchant for mighty tomes; other notable authors that stress-tested the woodwork included the likes of Brockschmidt (OLE), Hohpe (Patterns) and Meyer (OO), with Robert Binders’ Testing Object-Oriented Systems the heavyweight champion.

Book obesity is not a new topic to this journal with its editor raising similar concerns some 10 years ago [Buontempo12]. In what became yet another failed attempt at writing an editorial, Fran distracted herself by weighing the classic K&R book on the C programming language (375g it turns out) while lamenting the ‘cost’ (time-wise) of modern technical books. I’ve definitely got books where even the index would weigh more than 375g!

For the sake of balance I should point out there is an upside to having 1000+ page books – they make excellent weights when pressing leaves or flowers, or fixing things with glue that require continuous pressure while setting. Such weight comes with great responsibility, though, and one needs to be careful not to place the book too precariously, lest it slip off the table and land on one’s toes. Fran may have used K&R for her book scale, but misfortune has suggested to me that the Richter scale can equally be applied to the pain level of bruised toes as much as it does earthquakes.

Putting the ‘technical library’ in the downstairs toilet was partly borne out of practicality. The desk performed admirably as a level 1 cache but the latency of accessing the level 2 cache in the attic was dreadful, especially in the evening when my kids were asleep as they played host to the hatch and loft ladder. The shelves in the toilet drastically improved the (amortized) L2 access time without disrupting the facilities due to a clustered configuration (aka secondary toilet in the upstairs bathroom).

There was also a slightly humorous element to using such an unusual location as a library – my wife would suggest to visitors that it was to keep them ‘hidden away’ and avoid tainting the collections of Penguin Classics and Dr Seuss. In retrospect, I’m not buying this argument as when I was finally granted safe haven with the rest of the family’s books, they were still relegated to the topmost shelf as if they were some kind of illicit material. The extra reinforcement for the new top shelf may also have had a bearing on this decision along with me, the tallest member of the family, being the only one who needed to reach that high up.

Unpacking the boxes of books once the fresh lick of paint had dried provided a much needed opportunity to revaluate the existing organization which was analogous to the complexity guarantee for a std::vector – inserting anywhere except near the end was time-consuming. Naturally, I paid the price and ended up with a retrieval complexity approaching O(N). (Sorting the books was very much left as an exercise for the reader, which they never seemed to get around to…)

I can’t say that organising technical books primarily by author, title, or year has ever felt natural to me. Luckily (based on my limited data set) authors tend to stick to the same topics and, as technologies tend to come and go, grouping around them ends up leading to a clustering based on author and age as a side-effect. My programming career to date has largely involved writing applications and services on Windows in C++ and C#, so that provides three obvious initial collections with only Windows++ and Windows via C++ causing any immediate hesitation. But what about the rest?

What I really need is a book on category theory. I’m aware that Bartosz Milewski has written one specifically for programmers, but the trouble then is where do I file that? I already have Milewski’s C++ in Action from the early 2000s so do I create a new category just for him? Looking at the remaining stack of books they are largely singletons, although design patterns also now stands out as a notable genre too.

Naturally C++ and C# got amalgamated into a larger section on programming languages, which I did alphabetise. It all went swimmingly until I came to the x86 and Z80 handbooks – do they go at the beginning under A for assembly language, or the end under their CPU names? I did briefly consider making the dilemma go away by redesigning the bookshelf as a circular linked list so that A and Z would adjoin, but only very briefly.

What’s left after that little exercise are a whole bunch of books – old and new – about a variety of software development topics covering process, reviewing, quality, history, etc. with no obvious home. Hence, with no self-contained sub-categories leaping out I’m inclined to borrow from J.B. Rainsberger [Rainsberger15]:

Junior programmer’s bookshelf: 90% APIs and programming languages; Senior programmer’s bookshelf: 80% applied psychology.

…and file them all under a single section: applied psychology. Sorted!

References

[Buontempo12] Frances Buontempo, ‘Editorial: Too Much Information’, Overload 111, published October 2012, available at: https://accu.org/journals/overload/20/111/buontempo_1885/

[Rainsberger15] R. B. Rainsberger, on Twitter, tweeted 1 July 2015, https://twitter.com/jbrains/status/616228270841962496

Chris Oldwood is a freelance programmer who started out as a bedroom coder in the 80s writing assembler on 8-bit micros. These days it’s enterprise grade technology from plush corporate offices the comfort of his breakfast bar. He has resumed commentating on the Godmanchester duck race but continues to be easily distracted.