Book Review: Code Complete

Code Complete: A Practical Handbook of Software Construction, by Steve McConnell

51jokj0md0l_sl500_bo2204203200_aa219_pisitb-sticker-dp-arrowtopright-24-23_sh20_ou01_.jpg

This was a great book. If you have been in software for a significant time you are likely to have picked up many of these habits already, assuming you have been around experienced engineers who have helped you cultivate your software capabilities. It is chock full of useful information that every engineer should know. While this is a sure career improver for new engineers it has information that could easily be digested and used by even the most experienced programmer.

Seminal book. Buy it.


Over the code

I realized a while back that I have grown tired of writing code. I still enjoy the design aspects of software and enjoy being involved in the software creation process. I just no longer care for the implementation aspect of the business. I haven’t written a line of code in probably three months. I haven’t written a significant portion of code in at least six months. And I’m happy.

My parents were both programmers so I got a very early introduction to software. I began by writing little programs, address books and the like, throughout childhood and high school. I then jumped into a data entry job, which I quickly figured out how to write a script to help automate. From there I never had a job where I didn’t write code. Until now.

My parents both ended up in management – my Dad has relatively recently returned to writing code. They both told me the same thing at one point or another: they just got tired of writing code and wanted something new. I believed them and figured that I would follow suit sooner or later.

About five years ago I was still pretty into writing code still but looking to the future I saw myself growing wary in the next five to seven years. My timing ended up being just right. About five years ago I started getting into more leadership roles – leading software teams while still having my hands in the code. Over that span I have slowly become more and more removed from the code until just a few months ago when I decided I was completely done with it. I am now in a role where I don’t write any code but still have a high level of involvement in the design and development processes.

I may still write about code and software practices here and there however, as is obvious by my post trends, they will become less frequent. I imagine that the main focus of my writings will continue to be business of software and economics, with a little bit of software sprinkled in here and there.


A Riddle

Last night we were preparing for my daughter’s third birthday party and decided to go grab fast food. After leaving the drive through I put a french fry in my mouth only to find that the outside was cool but the inside was very hot. My daughter asked for one and I said they are too hot, so hot they are burning Daddy’s mouth. Here response was simple enough: “Blow on it.” So I posed the following question:

“How do you blow on something that is in your mouth?”

Before you continue reading take a moment to think about this.

If you are like me the first thing that came to mind is the reverse blow. You know this. It’s where you all of a sudden find yourself with something too hot in your mouth and frantically suck in air to try to cool the food down. But this isn’t right.

The answer is simple: take it out of your mouth.

I posed this question to her then immediately recognized the riddle like nature of it and started thinking about the answer. My three year old told me the correct answer before I arrived at it on my own. Perhaps it is a testament to the complexity of our adult minds but the natural tendency for most of us is to start at the complex and work back to the simple. Conversely, the child brain seems to naturally start with the simple and work towards the complex. We shouldn’t do this – we should start with the simple and work towards the complex.

This concept can be applied time and time again in the software industry. I can’t count the number of systems that I have seen that have been over designed and/or over engineered. Many times these systems would have worked just was well, if not better, with a simple solution. However, the simple option was either never noticed or was ignored.

The Keep It Simple (KIS – alternatively KISS for Keep It Simple, Stupid) principle should always apply – the design and engineering should be as simple as possible while still meeting the needs of the system.