Code Complete by Steve McConnel (2004)
Intro: I remember buying Code Complete in 2009 – this was before I gone to college. This was one of the books I saw recommended over and over again. Now, 5 years later I want to embark on the journey and read this tome of software construction.
After reading it I can say that it’s still a good book. I think for beginners (< 2 yrs) it’s really valuable. You can pick up some good habits through this book. You can learn things that others learned hard through experience. Definitely worth a look.
For more experienced people there isn’t that much new stuff in it.
The chapter on metaphors was interesting. I never realized how prevalent they were. Since the time of reading the book and writing this article I’ve read some other books who focus more on metaphors but nonetheless interesting. The question is how useful they are. Not in the sense of having a metaphor but in the sense of learning new insights.
So far (Chapter 3) it reads like a programmers guide to talking to managers; which I think is great for beginners into the job world but not that interesting for me personally. I think it has to do that I did quality management for some time so I know about the importance of requirements and uncovering needs and cost of errors in different stages, etc.
Problem description should be in user language
This is a great advice. I like it because it prevents you from jumping to solutions too fast. If you write – we need some PostgreSQL DB with these primary keys, and … – you think in solutions. And often the problem the customer has isn’t the problem you should solve.
5-15 productivity gain of high (Java, Smalltak, VB) over low-level languages relative to C
Not surprised. Interesting is that the gain varies by language. Java is about 2.5 times productive, Smalltalk 6 times and SQL 10 times. It shows to me the strength of Lisp because it allows you easily to build bottom up and thus basically build your own DSL for every problem you encounter.
Interpreted faster than compiled
Also not surprising. It boils down to faster feedback. Some interpreted languages offer a REPL which allows you to get even more timely feedback.
Habits of good programmers
This was a key insight. Good habits make a good programmer. I’ve written about habits ages ago – I sadly don’t have that post anymore. It was about written communication and writing correctly. Back then I talked to friends and some said that they are going to write correctly if they have to. I argued that you’re not going to learn it if you don’t practice – make it a habit. Same thing here.
Most of the stuff in this book wasn’t new to me but I’ve read tons of other books and have some experience in software development. What I noticed while reading the last quarter of the book how great functional programming can be. The author pointed out several problems and pitfalls which are solved if you use functional programming language.
The last interesting fact was:
Average programmer reads less than a book on programming/software development per year
That’s insane. He recommended to read 12 books a year and you will be pretty quickly above average. I know a lot of people read blog posts and online tutorials or stackoverflow. But a book is just different.
All in all, a good book for beginners. I would recommend it to them.