To celebrate my first blog post in four years, I thought I’d do something really wild and crazy, like shots and strippers. Then I realized that future employers could read this, and decided to write a book review on ‘The Pragmatic Programmer.’
Really, though, I feel kind of bad that I’ve been “borrowing” this book from my boss for about a month now. In an effort to actually, you know, peruse its contents, I started to bring it to the gym, and now the pages get all crinkly after they dry. I really don’t think he’ll mind, I mean, it’s been through worse. I’m pretty sure I had sex on top of it.
The book is excellent, inasmuch as it is a programming design book. It won’t teach you code, or basic programming structures, you have to know those things already. If you haven’t worked with spaghetti code yet, stared at an incomprehensible mass of letters and numbers until your eyes go all leaky and you wish someone would hold you, anyone, even that dishwasher from Eat ‘N Park – well, you’re not ready for this book. Still, it is easy reading, and very comprehensive, covering many of the things that my own team does, as well as things that we don’t have a use for, but another programming team might.
You should treat exceptions as exceptional (yeah, you’d think, right?), because they can temporarily couple unrelated functions together, which makes for icky debugging. In fact, try to prevent separate modules from interacting in any way, unless absolutely necessary. We try to stick to that, but about a year ago someone had diarrhea all over our Dispatcher module, and now there’s some unavoidable cross-referencing. We keep it to a minimum – while this book wouldn’t be our Bible (and the authors specifically state that not everything they write is always applicable), it’s a series of great guideposts. That’s a top selling point for the book; the authors always acknowledge that their advice is good in practice, but not necessarily as a released product. If it turns out that you can halve the server hits by tightly coupling two mostly unrelated processes together, then good Lord, man, do it!
I really liked their approach to orthogonality – that changes to the meat of one function shouldn’t affect other functions at all, or at least as little as possible. Yes, the idea really is basic, and it’s the foundation for their discussion of object encapsulation and contract-based functions, but it resonated in a way that many other books can’t hope of achieving. Later, they made some correlation between coding and flying a helicopter, which immediately made me think, do I really want a motorcycle? I mean… helicopter. Then I remembered that a) helicopters cost lots and lots of money, and b) after roofing for a summer, I hate heights. A season of working forty feet off the ground, inches from finding out if humans are like cats (do we land on our feet? does it matter?), well, it gives you a certain appreciation for life.
They also related coding to getting blown up by a land mine in a war zone. I’m sure our troops would love that.
