Reading the Classics - Code Complete

I've decided to start writing about technical books I read that could be considered "classics." The reason is mostly to keep a record for myself of my thoughts on the book at the time I read it. If it also generates a discussion that wouldn't be too bad either. Someone could remind me of something I missed or give some insight that I never thought of.

I actually read Code Complete a few years ago, but there was a lot about the book that stuck with me.The book is full of good advice for programmers to follow during their entire career. It starts with requirements and goes through each step of the software development life cycle. I really like the metaphor of construction that was used in the book to describe software development. There are sections that show code samples and some best practices. These were what I thought was the core of the book and where most programmers will probably find value. The sections on testing, debugging, and class design were especially good and stuck out to me when I read them.

I liked that the writer was very explicit about the religious wars in programming and when he would be entering into a "religious" discussion. Sometimes programmers are very fanatical about the tools we use. I know I can be sometimes. Personally I like Vim. It's mostly because that's the first editor I learned in college and didn't take the time to learn anything else. Sure I've played around with emacs, but it's just not the same as Vim. I like that the writer says that it's just a personal preference and not to take it too seriously.  

There is a part of the book that talks about code reviews that I thought was really good too. I like code reviews and I think they're an important part of any software development project. In my own job I know code reviews have caught bugs that I didn't see. The book does a good job of emphasizing that a code review should be about having other programmers looking over the code to make sure it's correct. This means other programmers on the team should have time to look over the code and provide useful feedback. Also, it's useless if it becomes political and involves managers. At that point people start trying to hide bugs and obfuscate things to stop people from reading the code.

With all of that being said I think this book felt a little dated since it was written a decade ago. The code samples contain a lot of C and VB. I know people still use those languages but I think most people have moved on to modern languages like C#, Java, Python, and Ruby. It doesn't take away from conveying the ideas in the book so it's not a big deal. There are sections about agile/extreme programming and functional programming that probably could have been more in depth. Again, it's not a big deal though and there is still good information that would be useful to any programmer. Still, it would be nice to have a new updated edition of this book with updated benchmarks and code samples.

I plan on reading back through this eventually. I've probably forgotten some of the information since I read it so long ago. 

Where I've been

I haven't updated this blog in years. I've decided to start blogging again so I can have a place to hold some of my ideas and opinions. Mostly this is going to be random thoughts and ideas about programming and technology. Some of them might be just opinions about certain aspects of programming. I know everybody has an opinion about programming and I'm no different.