+972 52-548-6969
Book recommendations in the test of time
Technical books are interesting. Some of them last for decades, some of them are valid only for a session. I had a few discussions recently about books in a conference, in particular, what books would I recommend. That got me to really think about the topic. There are a lot of books that I think were really valuable for me when I read them that wouldn’t really make sense to recommend / talk about today. Not because they are bad books, but because both the industry and the reader have changed.
Consider a book that I was really impressed with at the time: Patterns of Enterprise Application Architecture.
It is a great book, and quite interesting. But if you’ll try to write anything based on its contents, you are doing yourselves and your employer a great disservice. This is a book that you’ll read, today, to understand how the already pre-existing libraries and frameworks are put together. Interesting, certainly, but much less relevant than when it came out over 15 years ago.
There are a lot of such cases. Books that are relevant for either the time period in which they were written, or sometimes even to the time period in the career of their reader. An example of a book that I was quite taking with is the Code Complete book. For very much the same reasons as the PoEAA book, they are much less relevant now than when they came out. This is because the ideas exposed in these books have won, they are both ubiquitous and expected.
That is not to say that you’ll always find them, or proper behavior, but that is the ground floor on which you’re expected to start from, not something that you need to aim at and strive for.
Because of this, I am actually struggling to think about good technical books that I believe would withstand the test of time. Anything that is too tech specific usually have an expiration date attached to it. And even if we are talking about concepts and ideas, I’m interested in things that will give me more than just information, but actually provide something more. A good book in this regard is something that would change how I’m doing things for a long time. A compiler book would tell me about how to write parsers and work with AST, how to generate code and and lot of details in this nature. And that would be very valuable, but it would also usually be knowledge that is very specific to a task and place. It will be generally applicable.
Thinking back over all the technical books I have read, there are just a few that I can point to and say: “This book changed the way I write code and build systems”. And these books typically are still relevant today and I can happily recommend them developers at every stage of their career.
The ones that really pops to mind are:
I read it a few times, which is pretty rare for me with technical books and I got a few copies floating around in the office so I can tell people, “Read this and you’ll get it”.
The ideas there about building robust production systems, what are the challenges and the things to watch out for are invaluable. The patterns outlined in the book, anything from circuit breaker to explicit transparency have been invaluable for the software I write.
I do have to point out that the tech in the book is often Java (circa 2010, I guess). So when the books discusses specific options, that is often not relevant, but the content and the ideas are fascinating and had made a major impact on how I write code and architect systems.
Working Effectively with Legacy Code
I remember reading this book and going “Ahhh” several times over. The book talks about how you can approach a legacy codebase and make changes to it, and presumably it is useful in this regard. I read it very early in my career, before I really had the chance to get enough code to call it legacy and I have used the techniques in the book to avoid getting myself into too much trouble over time.
I should note that a lot of the things that are discussed, such as creating seams in the system so you can write tests for it are actually very useful for many other things. One of the things that I have noticed is that I will routinely make use of such seams for debugging things. To provide additional behavior and insight into what the system is doing explicitly to find a particular issue.
For some reason, I haven’t seen a lot of usage of that, but I consider debug hooks to be a really important feature of good software and I started doing that as a direct result of the kind of things that I read in Working Effectively with Legacy Software.
I have to admit that I have a much older edition of this book, and I like that cover a lot more. But I think you will be more interested in hearing about the contents of this book.
This book, as well as Operating Systems Design and Implementation, cover how operating systems actually work, the major components and how they are actually put together. The topic may seem pretty academic and not of much use for application developers but I found it fascinating when I read it for the first time and I think it is very relevant today. Not so much the details, which are quite often different between operating systems and operating systems versions but the actual high level concepts.
It also help in understanding what is actually going on when you are running code on a machine. Things like how threading is implemented and the idea of how the OS gets to decide what runs, how memory works and how you can make use of that, etc.
I would be able to write RavenDB if I didn’t have a good grasp of all these details and the 4.0 release has been quite explicit about building software so the operating system can help us, instead of having to fight it. In order to do that, we needed to understand how the OS works, what it expects applications to do and how to actually make the best use of that.
You might note that there are a lot of books that aren’t here. Nothing about source control or writing tests, the Pragmatic Programmer or Design Patterns. To head things off at the pass, it isn’t that these are not important, but at this point, talking to an experienced developer, I just assume that that kind of knowledge is already ingrained.
Federico had the following recommendation. Modern C++ Design is one of those books that literally break your understanding on how code is built and interpreted. I remember having taken this book back in early 2002 when I saw it standing on the counter of the computer science department library. I somehow convinced the secretary to give it to me under the promise of returning it, because there was a professor waiting for it. I read it completely in a week. End result, either this guy was absolutely crazy or I didnt understood a thing (latter I discovered it was not the former). So I did what anyone responsable enough would do; start all over again, and not return the book. Had to read it 3 times in the space of a month to barely grasp the concepts and got fined because of the late return 1 month later :D
I would love to hear about the books that you found fundamental to your career.
Comments
Not that I disagree that the ideas expressed in Patterns of Enterprise Application Architecture are more commonplace, as I also find I look at it less and less these days, but I still find that the book (and it's sibling in ESB systems Enterprise Integration Patterns) are valuable reference materials. Usually it's when I know there is a more established way to do something I'm hacking together, or need to find a well-recognized name for a pattern I'm implementing and I just can't remember what it is. It's also good to throw at a junior dev and say "read that, them come back to me"....
I know we talked about this already in person, but for the sake of readers:
Code Complete changed my outlook as a developer. I'd even go as far to say that it changed me from a programmer into a software developer. It helped me think about software from a higher level, helped me analyze where I was at and where our project was at on the "technology wave" that McConnell spoke above, helped me think about software as a craft.
It would be interesting to read it again after all these years. But I suspect there remains plenty of applicable wisdom in that book. While you rightly note that Code Completes ideas have won, I believe the book would still be valuable to newer developers.
Essential COM (by D. Box) to discover COM differently, plus it's relatively fun, like Mr. Box was at that time, Principles of Transaction Processing (by P. Bernstein, E. Newcomer) helped me understand transactions (also MTS/COM, etc.). Inside Microsoft SQL Server 7.0 (by R .Soukup, not the sequels, just this one specific version) which really helped me understand what is a relational database (beyond SQL Server). PS: I always considered PEAA as pretty useless (ie: only helpful to communicate with people who use pattern-oriented jargon...)
Thanks for pointing to Release it! That's how I discovered a second edition was just released last month.
Would you mind discussing in details on your implementations of "debug hooks"? I am very much interested in how you implemented them.
Hibernate in Action. Not just the book but Hibernate it self (in my case was NHibernate), and the ideas that I come to see in Hibernate and NHibernate forums. I remember the first time that I see something from Oren there. It was a piece of code that would allow us to set in code only one side of a bidirectional relationship. Unfortunately it didn't work. :)
Jiho Han, The debug hooks I'm referring to are mostly about building the software to be understandable from the get go. In RavenDB, you can see this with the kind of monitoring output we provide, anything from tracking disk space to seeing how the data on disk is arranged. It means building the software already thinking about troubleshooting. So you can lean on it as core part of what you are using to figure out what went wrong.
If it took you three times (in a span of only a month, mind you) to grasp Modern C++ Design, how many times do you think it would take us mere mortals? Knowing that, would you still recommend this book?
Jojo, This is actually Federico, not me personally. But that said, I found that some of those things require bouncing against the wall several times before it is grokked. I don't really understand how I learn some things. I remember being utterly confused about pointers and dynamic memory management in high school, and a year later doing a C course and just picking it up as if it was obvious. There were several instances of such things, where the accumulation of enough experience and related knowledge gives you the option to actually understand what is going on and have things click.
Besides the ones you mentioned, each of which I have also found to be tremendously helpful, I do think there are some truly timeless "classics". A few of my favorites:
Comment preview