If you are into inspirational quotes, and repeating the same thing over and over again on your head until you believe it to then get into "hacking" fully inspired and into the productive zone, then this book is for you.
If you are into inspirational quotes, and repeating the same thing over and over again on your head until you believe it to then get into "hacking" fully inspired and into the productive zone, then this book is for you.
The guy who wrote it had a pretty interesting career trajectory - went from being a jazz musician, to a self-taught dev, working his way up to a manager of a large scale outsourced team, to a dev again doing Rails and the like.
It had a feel and structure like Robert Greene's books - little 3-5 page segments focused on one idea, interspersed with personal stories and interviews illustrating the points. It seemed particularly focused on working within a corporate structure in a positive manner.
The book is about the tiny details of coding. Getting the small things right, as in any sport or profession, gives you the tools to get the big things right.
But if you are in a section that bores you, skip around a bit!
Kind of book equivalent of opening facebook/news for 5 minutes and then going back to work. Except that you learn little bit each 5-10 minutes long session.
Much of the book is spent making arguments for and providing evidence for things that are considered obvious today.
So if you stopped because the material sounded obvious and redundant, then maybe it is for you. But if you stopped because the material seemed seemed unimportant or trivial, then I strongly urge you to start up with it again.
It is a thick book. But you can still learn a lot even if you don't read it cover to cover. Even if it only makes you a better developer by 0.5%, isn't that still worth it?
My full review of it is here: http://www.amazon.com/review/R269BBARXH1V6R/
Since then most of the lessons in Code Complete have become part of the soul of modern languages, frameworks and libraries. So you learn them through proxy.
Still, I still come across people who could learn from reading it again, especially what it says over comments, testing and generally writing legible code.
I think more people read those books and say, "yes, I agree with all of this already" than read them and think, "oh, here is a new thing I haven't thought before and will use from now on."
Generally, for a programmer, I'd say skip it. Or pick it up in a library and skim over it, and you'll get 90% of the benefit. And yeah, the whole thing could be condensed into a large blog post / small handbook and it would be immensely improved.
I read Code Complete 2 after developing software for maybe 6-7 years in an environment like this. Much of it was obvious, but the rest was a revelation. Same with The Pragmatic Programmer.
Several years later I read a book called "The Passionate Programmer", which was like the book described in this article - soft, career development skills. That was probably the most important book I've ever read. In fact it's how I found out about Hacker News in addition to a whole bunch of different books. It lit a fire in me.
4 years later, I have a career that is so dramatically different I don't even know where to begin. On the same token, I reread that book (Passionate Programmer) recently and it does seem like common sense I would absorbed over time from things I read on HN.
That said, it has a lot of solid advice. It also has some less than solid advice which is more of an opinion.
I would still recommend people read it. I also recommend they read the references. I also recommend they talk with other people, look at their experiences, and try to figure things out for themselves.
Adding another thought here:
Some things have to be learnt through experience. You can read a really great book about swimming but it probably won't make you a good swimmer. So that's one thing.
The other thing is that I found the book trying to be very rigorous about subjects where it's simply impossible to do so. There are so many different ways to approach different problems and things like cost vary hugely between different businesses. Sometimes doing things one way makes sense in a given context and not in another. What we need is for people to develop that understanding rather than simply learn some rules.
Did you at least read it?
Yes, I have read it. It is not a terrible book, heck, it might be good for what it is meant to be (guidance for disoriented developers), but it is far away from being the best development book, and thus should not be called what it is not.