Code Complete by Steve McConnell is recommended every time a developer asks "How to manage a project?" It is often mentioned as a classic, but unlike many other books with this attribute, it is also a suitable day-to-day read, in close reach of your keyboard.
This review shall help you decide whether it's the book for you or not. (Hint: it probably is.)
There are a few rites of passage for budding developers: things that keep some people confused for life, while others pass them without a thought - indicating they have the prerequisites for great developers.
Usually, the first two obstacles are pointers and recursion. Code Complete is not about them.
Whether the software industry attracts you with its great perks during one of its ups, or you are one of the lucky people who get paid for their hobby: Developing software for a living holds some rites of passage that colleges rarely prepare you for. Some of them are:
Working in a team is a social as well as a technical challenge.
Working on a code base that you can't comprehend completely requires a completely different style than a project you wrote or could write yourself.
Planning ahead how long a feature will take and estimating its total cost - including packing up for distribution and maintenance - is something that inexperienced developers never get right, but may be vital for your project or your company.
Mediating between needs of management, marketing and sales, and the turn-pizza-into-code forces helps both sides to do their job more efficiently and don't meddle in the affairs of the others.
Code Complete isn't and cannot be the answer-it-all book, but it is a valuable asset in the evolution from a coder to a software developer.
What you can find in it
I'll list the book parts here, because they give a pretty good overview:
- Laying the Foundation
- Creating High-Quality Code
- Code Improvements (covers Testing, Debugging, Refactoring, and Code Tuning)
- System Considerations (covers Management, Tools, Integration)
- Software Craftsmanship
For a more detailed table of contents (and a chance to place your order), try this Google search[^].
About 60% of the book is dedicated to improving the code you write; the rest spread on quality control, collaboration, maintenance, management, planning, and keeping things together.
Budding developers will find the usual rules that turn writable into readable code, and "but it works for me" into robust. Code Complete can also jump start your team's style guideline document by just boiling down what makes sense to you to a one- or two-page document.
For project management - including your day-to-day activities - you will find strong arguments about which techniques and principles make sense economically, what to expect and what factors to include if you are asked for an estimate. Human and psychological factors get their share, but not extensively.
So, how good is it?
The biggest strength of Code Complete is the rich collection of statistics and condensed results of studies that support the claims and suggestions. Even for the obvious results, these charts and tables turn "feel-good-advise" into solid and valuable arguments in the struggles with management and other cheaper-faster stakeholders. Others are outright surprising. Did you know that small changes tend to introduce more mistakes than medium-range ones? That you might be better off with a slow programmer instead of an average speed one? That just reading code uncovers more errors than unit tests?
Second, it is not tied to a particular language, principle, or methodology. This may sound like a weakness, but it is not. Most of the things are independent of the process you use. (N.B. ruminations in the same direction by another author can be found here: Does process matter?). While the tools of modern development - Unit Testing and refactoring - get a fair appearance, they are untied from the context that made them well-known.
Third, it is thorough. 120 pages discussing variables, over 30 of them dedicated to naming them. Even the puny evil-doer
goto gets ten pages. This depth is certainly a refreshing change from simplistic statements, but it can also be a weakness, as programmers tend to not read enough (as McConnell points out himself). But, if this isn't enough for you, each chapter has an extensive list of literature to continue with.
The writing style strikes a good balance between formal and conversational. It's not dry, but don't hunt for jokes. Non-native speakers with somewhat-above-basic English skills should be able to read it, but translations exist into many languages. The translation to German is high quality - one of the few texts where I don't clearly prefer the English version. There is a "conversion table" for technical terms, and a few places take local specifics into account. (If you can comment on another language, please do so!)
What's bad and what the book isn't
The thoroughness comes at a price - over 900 pages. The depth and detail can be intimidating - my first of the book was opening it in the middle, and seeing the seemingly common discussion of variable names. "Holy Cow! He needs 500 pages to get there!" The book tries to cope with its size by markup for Key Points, Hard Data and Horror Code, and using multiple indices (Contents at a glance, Table of contents, Indices of checklists, tables and figures). Still, I miss an index of the Hard Data.
While easy to understand, Code Complete is not easy reading. The level of detail makes it easy to doze off or skip ahead.
The book does not give you the tools for building a formal software process or architect software. You will not find a discussion of patterns, and 30 pages on class design is skimpy - considering conditions and loops get the same amount of coverage.
You need it. You will like it. Trust me.