I know it's the author's <i>thing</i>, but I've really grown to hate the pictures of food in his articles. I might feel differently if it were done well, but there needs to be more of a reason to include a picture of food than simply wanting a visual break in the article.
See also: Jon's great Google Tech Talk "Three Beautiful Quicksorts".<p><a href="http://www.youtube.com/watch?v=aMnn0Jq0J-E" rel="nofollow">http://www.youtube.com/watch?v=aMnn0Jq0J-E</a>
I think the most valuable parts of this book for me were the stories that involved solving problems within constraints. If you work with a large enough dataset or management that won't allow you to buy the hardware to just make your problems go away constraints are still a big part of software development.
From his book: "It is faster to make a four-inch mirror and then a six-inch mirror than to make a six-inch mirror."<p>This is one of my favorite programming quotes. I haven't seen it used much over the years.
As brilliant as the algorithms listed in the book are, I find them less and less interesting in and out of themselves nowadays. Those data structures and search algorithms have really become basics. I just don't understand why people still blindly worship this book and the way it was and are still trying to replicate it during interviews. If you want to test a developer, don't force them to do bitwise manipulations in C. Why not step up a bit further and try to ask them to apply those data structures and algorithms into a server cluster or a server cloud and see how they come up with a solution. That is more likely the case they will encounter nowadays.<p>All right, enough of rants. Here is my take on this book. This is one of my favorite books. Great things like this book, in the same way as Unix, C and other oldies, can last for a really long time. One thing of the book that intrigued me was the way those old great hackers managed to conquer seemingly impossible problems, despite the severe constraints such as limited memory space, in a extremely resourceful manner. The bit sort in chapter one and the chapter how Ken Thompson squeezed storage space for his chess program are two of my favorite read. The other thing I think may be even more useful is the back of the envelope estimation, which encourages out of the box thinking or street smart (though those kinds of questions got abused and became notorious in technical interviews).<p>Constraints still exist as we begin to attack harder and bigger problems, such as "web-scale" applications. New metrics for the back of the envelope estimation came into beings such as network latency, database queries. I really hope someone of our times can come up with a similar book in the same spirit, but addressing the issues we face nowadays.
Bentley's articles on acm : <a href="http://portal.acm.org/author_page.cfm?id=81100143310&query=(Author:81100143310)%20&srt=meta_published_date%20dsc&role=Author&perpage=all&termshow=matchboolean&CFID=18592091&CFTOKEN=68573972" rel="nofollow">http://portal.acm.org/author_page.cfm?id=81100143310&que...</a><p>It might require a subscription, though.<p>It seems to contain the articles from the book, starting with those from 1983.
Bentley's book "Writing Efficient Programs" is also really super. Unfortunately, it's been out of print for a long time. If you ever see it, snap it up.
When I interviewed at Microsoft, they recommended reading this book -- I doubt it helped at all, but it's a great read (as is the sequel) if you haven't read it.<p>There's a real sense of history too, some of the problems illustrate how far we've come: like talking about transferring a whole megabyte several miles as a challenge.
I love this book. I have it next to my bed and read in there from time to time before I fall asleep. Makes you dream up great algorithms (at least I try to belief that ;)
I, by pure luck alone, happened across this book early in my career, and I still go over it from time to time. I will probably die with it in my "keep forever" library.