Tech Book Face Off: The Pragmatic Programmer Vs. Code Complete
sam-koblenski.blogspot.com
sam-koblenski.blogspot.com
The cool thing about PP is how it packs its advice into easy to understand metaphors. CC tries too hard to make science in a subject (Software Engineering) that is not always very easy to handle scientifically. I don't buy a lot of the evidence CC provides (cone of uncertainty, 10x productivity difference in programmers). I even think CC becomes a better book after you read PP first.
[Edit] At the end the author comments about 2 other books: Clean Code and Refactoring as overlapping the stuff covered by Code Complete. I don't think so; to me they are much more a subset of it. [/Edit]
It provides a lot of useful mental approaches to programming, and the reasons to code something one way or another. If it's long winded, that's a consequence of its being a comprehensive survey. Certainly, as a software engineering textbook, it has no peer.
We bought the 2nd edition as a library book here at work recently. I couldn't get into it at all. I wonder if there is a qualitative difference between the editions, or if perhaps I internalized the first book enough that the 2nd edition just didn't capture my interest in the same way.
But, in case the article has you doubting the value of the book, I found it to be tremendous. With every line I write I have all of the ideas in that book running through my head.
Take a simple example. Braces on the same line or next line? Well, to me the answer is clearly same line (I used to prefer next line, until Code Complete, btw, I am not just using the book to justify a random preference). Why same line? Because studies show that as soon as you need to scroll a window to see all of your function, bugs go up and comprehension goes down. So, by putting the braces on the same line I can sometimes significantly improve vertical density, and thus improve the code reading experience.
I do not intend a brace war - please don't start one. The point is that we can use empirical studies to guide how we code. Not just layout issues, but how we name variables, how we enter and exit loops, how we break things into functions, and so on.
I cannot overstate how much I value the book and the ideas contained within it. If it was up to me (and, it's not) every programmer in this company would have a copy on their desk, and would be expected to either follow it or have a good reason for not following it (and there are good reasons sometimes - no rule is cast in stone).
Get the book. Learn the book. It will make you better.
So reading an old classic like The Mythical Man Month isn't going to be a waste of time at all and is strongly recommended, but later really good stuff like these two books have additional lessons we've learned since then. So read the 20th anniversary version of that book (http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...), in which the author revisits issues and e.g. modifies his advice to "plan to throw one (version) away, because you will". The potential state of the art has gotten better, you can often get away with not doing that.
Code Complete, on the other hand, is a little more hit-or-miss. Some parts of it are still very relevant, like how to write clear, readable code. But other parts have been supplanted by better practices. The book tends to lean more towards waterfall development approaches.
(I haven't read the other two because wherever I dipped in it was familiar. That's mostly true of the above too, but it got a chance because hey, Kernighan and Pike.)
Code Complete was (to me) revolutionary at the time. Though it may seem a bit dated now, it was a foundational work that much of what we take for granted was built on.
I don't hear enough talk about Steve McConnell's other book "Rapid Development". http://www.amazon.com/Rapid-Development-Taming-Software-Sche...
I just looked at its Amazon page and it has 5 stars with 115 reviews. That doesn't surprise me at all - it's well deserved.
It came out well before the agile movement, and I would contend that it laid the foundation for it.
I'm so glad I read that at the beginning of my career. As a junior developer, it helped me immensely and even more so over the years.