I realized something about my life right around the time that I was getting ready to ask my girlfriend to marry me: if I wanted to eat well at home, I was going to have to learn to cook, because she lacked the interest and patience required to cook well (or at all, in her case…)
I gradually transitioned from basic subsistence cooking into being a really good and enthusiastic home cook with an ever-growing bookshelf of cookbooks and hours logged in front of the better shows on Food Network. The real thing that unlocked cooking for me was finding resources created by people who weren’t interested in demonstrating how to make a particular thing; these teachers were more interested in showing you a different way of thinking about food. On one end this is people like Michael Ruhlman and Alton Brown, focusing on the underlying principles behind how and why we cook (if you wanted to learn to cook well, I’d buy you a copy of Ruhlman’s books “Ratio” and “Twenty” and you’d have a solid foundation right there.)
On the other end of that shelf you have chefs like Grant Achatz, whose ‘Alinea‘ restaurant in Chicago is built around taking his deep, deep knowledge of the basic materials and techniques of cuisine and blowing them up, reassembling them with ultra-modern technique and presentation to create things that have never been done before, yet always make sense as food.
image from http://designforhackers.com/book/
David Kadavy’s book ‘Design for Hackers: reverse-engineering beauty’ is built around the idea of presenting the underlying principles of visual design to hackers eager to learn the secrets of the field. (more…)
This past week I finished reading the very interesting book, How Google Tests Software. I first heard about this book from an IT-Conversations interview with one of its co-authors, James Whittaker. The interview provides a good overview of many of the key points made in the book, but I still found it worthwhile to read the book.
The book itself is not a how-to book, providing concrete steps on how to test software. Instead the focus is at a higher level with much of the book devoted to describing the different testing roles within the company. There were three particular themes that jumped out at me from both the interview and the book itself.
I’d like to expand on Brett’s post a bit with some more recent books that I’ve enjoyed. And another which is perhaps a few clicks off the maintained trail.
The Algorithm Design Manual (Steven Skiena)
I’ll kick this discussion off with the fact that I don’t have a Computer Science degree. There, I said it. No degree. Ask me and I’ll give you the info: There’s no Computer Science degree here. Anyway. As a pure practitioner, I love books that usher out-of-reach concepts into the realm of real-world applicability, and this one does exactly that. This book is one part catalog of algorithms, the other part a series of “war stories” — real problems the author has tackled during his career using variations of the algorithms presented.
The Little Schemer (Matthias Felleisen, Daniel P. Friedman)
This book taught me a conscious way to write recursive routines. Prior to reading, I’d hammer the keyboard with a gloved hand and hope for the best. The preface mentions that this book is itself derived from a course taught by the authors on Scheme programming — to non-technical public affairs students. Yes, so you might imagine that the presentation inside is not your typical c0d3rz manual. I’ve dispatched this book to a couple of my non-technical friends, and the consensus is that this book is a gem.
Hacker’s Delight (Henry S. Warren, Jr.)
Count 1-bits in a word. Reverse bits in a byte. Transpose a 32×32 bit matrix. This book is a catalog of interesting passages of low level bit-twiddling code. Thanks to modern day tools, I haven’t needed to reach for many of the tactics described in this book, but it is an enjoyable and mind-contorting swim through the ether of machine words and switch flippery. Looks like I need to pick up the recently released second edition.
Image via http://www.flickr.com/photos/library_of_congress/2162719777/sizes/z/in/photostream/
Going through my RSS feeds this morning after a week away, I see this post from DHH at 37 Signals:
There are so many programming books out there, but most focus on specific technologies and their half-life is incredibly short. Others focus on process or culture. Very few focus on the timeless principles of writing good code, period. The following five books had the biggest influence on my programming style and development:
A very interesting list, and especially interesting to me that it has no overlap with mine. I do appreciate that his list concentrates on higher-level issues instead of more ephemeral matters (I angled the above photo so you can’t see my office’s Siberia shelf where I’ve exiled books like Brockschmidt’s “Inside OLE”). The five software development books that I’d grab if I had to evacuate in a hurry:
The Pragmatic Programmer: From Journeyman to Master (Andrew Hunt & Dave Thomas)
I re-read this book once a year or so. I love that it’s a set of small concrete steps that you can take every day to make your work better. Two specific changes I made as a result of reading this book were:
- I switched to using vim as my primary editor, even when relying on an IDE to maintain build environments (Tip 22: Use a Single Editor Well)
- When I read this book, C++ was really the only language that I had use for on a daily basis. Their Tip 28: Learn a Text Manipulation Language convinced me to pick up Python, which is now where I spend most of my time coding (and using it far beyond what their description of a text manipulation language would imply).
Code Complete (Steve McConnell)
I vastly prefer the first edition of this book, but there’s still a lot of great material in the second book. The great thing about this book is that he looks at software as a construction activity, and considers the effects on your code of elements from the lowest level inside a single line of code up to broader architectural considerations have on the final product. Most usefully for me, he’s done the work of scouring the literature and providing citations that back up his recommendations. In an argument with someone about issues of indentation, using white space, or other code layout issues? McConnell can point you to the relevant human factors/readability studies that will help you make your case (or change your mind).
Literate Programming (Donald Knuth)
Sure, most folks would have gone for Knuth’s multi-volume ‘The Art of Computer Programming’ if they were going to include anything by him. For me, though, Literate Programming is the really interesting read — his basic concept here is that the true purpose of source code is to explain to another human what you’d like a computer to do, and more incidentally to include the actual instructions that make up the program. It completely upends the traditional thinking, where a source file is mostly code with some comments/documentation strewn about (rarely enough, or at least enough of it being useful). This book is a collection of essays, mostly discussing the WEB (not world-wide — the essays in this book are all from the mid 80s or earlier) system for authoring programs that he developed while creating TeX. A program written using Knuth’s Literate Programming tools reads as a publication that happens to have source embedded in it; post-processing tools named ‘Weave’ and ‘Tangle’ convert from the human-focused layout into compilable source.
On the one hand, I think that Knuth’s vision as presented in this book is a pipe dream (and is largely obviated by more modern tools and methods for thinking about source), but I find the idea of programming as a branch of literature compelling enough that it remains at the front of my mind when I’m coding.
The Design of Everyday Things (Donald A. Norman)
Technically, not a programming book, but instead a book about making things that are intended to be used by humans. Originally written in the late 80s, as software development was slowly making the move from being presented to users via character-mode terminals to modern GUI environments, and many developers needed to be dragged into the era where it was no longer acceptable to deliver clunky, unusable systems. I’ve got a whole section of my shelves filled with Don Norman books — this early one was probably the most eye-opening for me.
Thinking In C++ (Bruce Eckel)
This is another book where the first edition is the important one for me, even though it would probably be less so for anyone reading it today. When this was released, I had been working as a C programmer, mostly, and had been having a difficult time making the switch to using C++ as anything more than ‘a better C’. What Eckel did in this book was to go feature-by-language-feature in C++ and first implement each one in C to provide a thorough understanding of what’s going on beneath the covers before writing the same example program again using the much clearer C++ syntax. Reading this book was one of those cases where a subject I had been struggling to grasp suddenly and thoroughly clicked into place for me.
Those are my five (and I could keep listing books — Design Patterns seemed too obvious, Alexandrescu’s Modern C++ Design perhaps too mind-blowing).
Tag — you’re it.
User Interface from ‘Prometheus’
Nathan Shedroff (from the MBA in Design Strategy program at the California College of the Arts) and Christopher Noessel from the well-known interaction design firm Cooper have recently released a new book analyzing the user interfaces shown in science fiction, as well as an accompanying blog to cover material that wouldn’t fit in the book for space reasons, or came out after the release of the book.
I’ve been following the blog for a few weeks now, and the more material they put up, the more I think that it’s important that these kinds of discussions are put in front of the eyes of as many software development practitioners as possible, for the reasons they put forth themselves:
Being an interaction designer colors how you watch science fiction. Of course you’re enjoying all of the hyperspacey, laser-flinging, computer-hacking action like everyone else, but you can’t help but evaluate the interfaces when they appear. You are curious if they’ll disable the tractor beam in time, but you also find yourself wondering, “Could it really work that way? Should it work that way? How could it work better? And, of course, Can I get the interfaces I design in my own work to be this cool or even cooler?”
We asked ourselves these questions with each new TV show and each new film we watched, and we realized that for every eye-roll-worthy moment of technological stupidity, there are genuine lessons to be learned—practical lessons to be drawn from the very public, almost outsider-art interfaces that appear in the more than 100 years of sci-fi cinema and television. Then we wondered what we would learn from looking at not just one or even a dozen of them but as many as we could.
As developers, it’s important that we both find ways to expand the potential set of problems that we can address with our software, while making sure that those solutions are based in what researchers in the interaction design and HCI fields instead of just aping the ideas created by Hollywood production designers.
The blog is at http://www.scifiinterfaces.com/
The book (either paperback and digital bundled, or digital only) can be purchased from the publisher, Rosenfeld Media.