Tech Book Face Off: The Pragmatic Programmer Vs. Code Complete

Once you have received your degree, accepted your first job, and started practicing software engineering, you'll start to realize that there's a lot they don't teach you in college. Many professors tend to focus on the theoretical aspects of computer science and pay little attention to the practical aspects of software engineering. They may expect you to pick up the skills you'll use to practice your craft while you're on the job, or they may not even be aware of this side of software engineering. How do we learn what we need to know in the real world of designing software and writing code? I mean the everyday stuff: writing specs, reading code, adding features, refactoring, testing, reviewing, etc. There are actually quite a few good books that can give you a head start and keep you from making plenty of amateur mistakes. Here are a couple of the most popular classics:

VS.

Even if you've been programming for decades, if you haven't read anything about the hands-on mechanics of software engineering, these books can give you expert advice on how to improve your programming practices. Alright, let's see what each of these books has to offer.

The Pragmatic Programmer: From Journeyman To Master

I thoroughly enjoyed reading this book. Andrew Hunt and David Thomas have a knack for packaging up programming wisdom into short, entertaining analogies, anecdotes, and parables that bring their points home in a memorable way. Even the titles of their chapters allow you to quickly recall the advice contained in each one. After reading through it once, you can just skim through the chapter titles to refresh your memory on their best programming practices. Here are some of my favorites:

Stone Soup and Boiled Frogs: Have you ever been on a project where you had a great idea for how to do something, but it would take too much effort to get approval for it if you asked? Try implementing a small part of the idea and present it to the team. Comment about how it would be so much better if it had this or that added to make it more robust or polished or whatever. Over time you may be able to get your idea in piecemeal, and the whole team will feel like they shared in the success, because they did. It's a win-win situation. On the other hand, don't let small changes to a project build up in a negative way, or you just might fall victim to feature creep like a frog in water being slowly heated to a boil.

Tracer Bullets: This is a great analogy for the design practice of getting a basic version working early and then iterating rapidly to improve it. They go through many of the advantages of this approach and some of the classic design mistakes that can be avoided by using it. It's an incredibly useful way to do design that every software engineer should know.

Programming by Coincidence: What happens when you start coding on a project without thinking? You plow headlong into your editor and bang out line after line of code. Then you test it out, fix a few obvious mistakes, and keep going. Eventually you start getting bugs that look a little weirder so you change code at random until the program appears to be working at a superficial level. In the end you'll have a mess of code that doesn't have a prayer of passing rigorous testing or actual customer use. This is programming by coincidence, and Andy and Dave go into it in much more entertaining detail, along with how to avoid it.

There are so many more gems just like these. I couldn't put the book down, and it was over before I knew it. I finished it wanting much more, and it totally changed the way I approach software engineering. In my mind, that's the perfect combination for a book like this. You should definitely read it. You'll get through it in a few evenings on the couch, and it will make you a better programmer. Highly recommended!

Code Complete 2

Maybe I was biased (or spoiled) from reading The Pragmatic Programmer first, but I just couldn't get into Code Complete 2. I had read many glowing recommendations for this book, and I know it is highly regarded in the software industry. But compared to Andy and Dave, Steve McConnell was kind of dry and long-winded. Now don't get me wrong, he filled this book to the brim with great coding advice, and it's almost four times longer than The Pragmatic Programmer so he covers an amazing amount of ground in 35 chapters. He goes all the way from software requirements to class organization to control structure to code layout to personal character. He covers everything having to do with code construction, hence the title.

There were certainly good things about Code Complete 2. The coding horror sections were always entertaining. If you've been reading old code - other people's and your own - for any length of time, you will definitely notice that many of the coding horror examples can conceivably happen in real code. They are pertinent examples of code gone wrong, along with explanations of why the conventions used in the bad code are confusing, error prone, and generally not a good idea.

If Code Complete 2 is anything, it's comprehensive. For the novice programmer, this is a great thing. Having such an exhaustive amalgamation of programming knowledge in one book can be a great introduction to good programming practices for the new initiate to the software industry. More experienced programmers may like the book as a reference or as a starting point for establishing coding standards on their projects, but as a readable work on the craft of coding, I found it somewhat lacking.

I really wanted to like this book. Everything I read about it recommended it as the definitive work on the subject, and it definitely is. But that doesn't make it an engaging read. It had no focus. Steve alluded to that fact in the beginning of the book where he claimed that when he went looking for the same information in the literature, he could not find it all in one place, that it was dispersed among a multitude of books, papers, and articles. His goal was to collect all that knowledge for future programmers. I believe he achieved that goal, but not in an especially memorable way. I can't immediately recall hardly anything that I read in Code Complete 2, barring a few code layout guidelines. I do distinctly remember that while reading it, I was constantly feeling like I had heard most of his advice before. Maybe that lack of new insights is what really kept me from getting into this book.

So Which One Should You Read?

At this point you may think the answer is pretty cut and dried - The Pragmatic Programmer, right? Not so fast. I still think Code Complete 2 is worth reading, just not all at once. You have to pace yourself. Don't try to read it all in a week or two. Those 35 chapters can be broken up into easily digestible snippets that you can read over the course of a few months.

If you do read them both, I would definitely recommend reading The Pragmatic Programmer first. Andy and Dave do a much better job of showing you how to become a better programmer rather than telling you, with clever anecdotes like the law of Demeter, the theory of broken windows, and "select" isn't broken. You are definitely going to remember a lot of their advice. Of course, there is a lot of overlap between the two books. With Code Complete 2 covering topics in more detail and adding more topics, it's a good in-depth reference following The Pragmatic Programmer.

Since Code Complete 2 is basically a super-set of The Pragmatic Programmer, I wonder if reading Clean Code: A Handbook of Agile Software Craftsmanship and Refactoring: Improving the Design of Existing Code would cover most of what Code Complete 2 does in about the same amount of space, but in a more engaging way. I'm not sure since I haven't read them, yet, but they are on my list. At any rate, The Pragmatic Programmer will pull you in like you wouldn't believe a programming book could. You may not be able to put it down. Go read it!