I finished reading the
2nd Edition of Code Complete this weekend. I’ve heard about Code Complete for years and never bothered to pick up a copy, and I’m glad I took the time to read it. My first professional development job started in 1995 and I considered myself somewhat picky back then. I few years later, I was under the impression that I was too sloppy, and now I realize that it’s a constant battle towards “almost perfect.” The earlier you can acknowledge the topics in the book, the better. I probably found the first 9 and the last 9 chapters in this book to be the most interesting. Although, you by no means have to read this book from start to finish, I chose to do so. The entire book is great, and I would probably make it required reading for employees if I owned a software or consulting company. There are a lot of “rules to live by” that are expressed in each topic. One of the most interesting and enjoyable chapters talked about the use of metaphors:
“A metaphor is more like a searchlight than a road map. It doesn’t tell you where to find the answer; it tells you how to look for it. A metaphor serves more as a heuristic than it does an algorithm.”
This is basically being able to conceptualize a problem and knowing that there is no magic bullet to create a solution in every case. From a high-level perspective of designing a solution to details of managing its construction, many references and techniques are shared in Code Complete. From a code-specific perspective, example of bad code is shown along with good code to clarify the points being made. Class design, defensive programming, variable naming/use, comments & pseudocode, debugging, testing, performance tuning, integration, tools, and personal character are all discussed.
Personal character as a topic was quite fascinating. Code Complete makes several clear points about intellectual honesty and improving yourself. There is such a thing as an “intellectual tool belt” that becomes more useful with eclecticism and experimentation.
“Blind faith in one method precludes the selectivity you need if you’re to find the most effective solutions to programming problems…adherence to a single method is also harmful in that it makes you force-fit the problem to the solution…software development isn’t a deterministic process; it’s heuristic, which means that rigid processes are inappropriate and have little hope of success…you can’t make a trade-off if you’ve prematurely limited your choices to a single tool…a dogmatic stance conflicts with the eclectic toolbox approach to software construction. It’s incompatible with the attitude needed to build high quality software.”
Continuing to educate yourself and the topic of “experience” is also discussed in detail. The point is made that “if you can’t change with the times, experience is more of a handicap than a help. Additionally, if you make learning a continuous commitment, you’ll get experience. If you can’t, you won’t, no matter how many years you have under your belt.”
This book is almost 900 pages and there is a lot to read, re-read, and review later. The statistic references end up being attention-grabbing as well. At some points you might see a code snipped and figure that you have the statistic figured out, when in fact the opposite is true. Probably the most important issues in this book that I want to take away are: writing comments first and coding around the comments, and the early points about managing complexity. Clearly everyone should strive to make themselves better programmers. There are best practices throughout the book, that a lot of us could read and revisit more than a few times. I definitely recommend buying a copy of Code Complete and encouraging other developers you know to read it as well.
