Yet another bookshelf post (part 1)


For “part 1” of this post, I’m not going to mention focus on great engineering books and leave books specific to testing for the next post. These are books that I think every engineer should read and re-read (In fact, I’ve read every book on this list at least three times over the years).

I’ve read Writing Solid Code by Steve Maguire at least ten times over the last 12 years. Every time I read this book I become a better developer and tester. Sure, the examples are all in C, but the concepts and stories are timeless. If you are at all interested in writing great code you should read this book. Maguire’s Debugging the Development Process is something else I’d highly recommend – it can be hard to find, but it’s absolutely worth the effort.

A close second on my desert island geek engineering book list is The Pragmatic Programmer by Hunt & Thomas. It is a great book to read to get ideas on how to improve your own skills as well as great ideas on how to improve the entire engineering team. A year or so ago, I wrote several articles based on the stories from this book. If you’re curious, you can find them here, here, and here.

Code Complete by Steve McConnell is another “must read” for serious software developers. I practically wore out my copy of the first edition, and the updated version of the book is fantastic. A common thread between these books is that they all use stories to convey the messages. Joel Spolsky (www.joelonsoftware.com) talks about the need for this in the introduction to The Best Software Writing I (which I highly recommend as well).

I recently re-read the 30th Anniversary version of The Mythical Man Month by Fred Brooks. This book is as relevant today as the day it was written. Just over two years ago, I ended an argument with my general manager by grabbing this book off of my bookshelf, handing it to the GM, and asking him if we could continue the discussion after he read it. He never came back and the point in question was never raised. As a concession prize, I gave him my copy of the book.

Looking at my bookshelf, there are dozens of other books on software that I love (I calculate my percentage of love by the wear on the spine). The books mentioned above are the books with the most wear, so I must love them the most.

 

 


Comments (3)

  1. Lauren Smith says:

    I’m going to out myself here as the latest reviewer of Debugging the Development Process over at Amazon.  I know, I’m famous.  Go ahead and press the little (yes) button next to the "was this review helpful to you" prompt.  🙂

    That said, having read all of the listed books except The Pragmatic Programmer, I have to agree with your selections except for DTDP.  I find its content too sugar-coated and inapplicable to many non-functioning engineering teams.  As I described in my review, it gives great advice if you’re dealing with a team of great engineers who have super-human abilities to concentrate for extended periods of time and be productive 8 hours a day.  However, real life presents us with teams made up of a hodge podge of engineers with varying degrees of capability.

    He approaches the problem of dysfunctional teams as a problem of management (and ultimately that’s where it lies, of course), and by changing management behavior it becomes possible to turn sinking ships into the Queen Mary.  I don’t doubt that a positive attitude is absolutely critical when taking over floundering teams (again with the marine analogies!) but it also takes a lot of intestinal fortitude to face the facts that some members may be a drain on the rest of the team and to make the necessary adjustments.

    It’s a fun book to read, all that aside.  There are great stories (Maguire loves to use stories) and the suggestions he provides are useful right away.  I don’t know if I’d put it on my must-read list.

Skip to main content