Tech Book Face Off: The Pragmatic Programmer Vs. Code Complete(sam-koblenski.blogspot.com)
sam-koblenski.blogspot.com
Tech Book Face Off: The Pragmatic Programmer Vs. Code Complete
http://sam-koblenski.blogspot.com/2013/03/tech-book-face-off-pragmatic-programmer.html
7 comments
Code Complete was my first book on engineering (the first edition). Even though the coding examples were in Ada and Pascal, I ate it up.
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.
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.
Same here (ate it up).
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.
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.
The Pragmatic Programmer is one of my favorite books ever. I recommend it to every programmer. At whatever point I'll have employees of my own, it will be required reading.
I see that those books were published in 1999 and 2004 respectively. Does anybody how much (if any) of the advice in these books is outdated?
I would say that the advice in The Pragmatic Programmer is timeless, much like The Mythical Man Month. A lot of the ideas presented there were later formalized into agile principles and practices, and are still quite relevant today.
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.
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.
It's been a long time since I've read either, but I can state in general that software engineering concepts don't tend to get outdated. The state of the art stuff I learned in the late 1970's is still almost entirely valid, although when it comes to low level stuff you'd want to e.g. adopt the advice about goto statements to other non-local things we are confronted with nowadays.
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.
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.
I never read anything I disagreed with in PP, and it's worth going through, but as you allude to it did reflect its times. There was an undertone throughout that programmers exist to server the capricious whims of their suit-wearing overlords, and a lot of the advice was centered around that. Relative to the times it was good advice, but perhaps doesn't apply as much in today's startup world where "the suits" often don't exist.
I think the people who need to hear the advice in PP aren't in the startup world. There are a lot of programmers in the world who are not in SV startups.
Code complete is very much tied to the OOP of its time. (I can't comment on the pragmatic programmer.)
The first edition of CC appeared before the mainstream boom of OOP, C++ was beginning to get adopted, Java wasn't released yet. The 2nd edition addresses OOP a little more but doesn't really goes too deep on it. I'd argue that the book is more worried about modularization, a concept from structured programming that in OOP would be translated into "loose coupling/strong cohesion".
When the first edition of CC hit the shelves the big thing on the internet was usenet and that was basically the only place to talk/fight about the stuff CC was talking about. The web was too new, the content to sparse and dialup was still king so you didn't spend hours online reading HN and StackOverflow. The audiences for these books are separated by a decade. CC2 was an effort to bridge that span of time but the audience has changed so it missed the mark. People care about different things today. The business of writing crappy code quickly, getting investment and getting out with your life savings intact matter more than the craft of writing code that first drew me to computers. Different times.
I've recently read The Pragmatic Programmer and its still quite relevant
NO
I recommend Kernighan & Pike's _The Practice of Programming_.
(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.)
(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.)
Seeing these classics discussed at all is awesome.
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.
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.
I'm a bit surprised that people find CC dry. I read it almost cover to cover within a couple of weeks of having it, and I'm the most easily bored person I know.
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]