Books for software engineers and managers

A Philosophy of Software  Design

by John Ousterhout, Creator of Tcl and professor of computer science at  Stanford

Star Engineer

Aim for deep  modules

We should strive to build modules that solve problems completely.

Solving a problem completely comes from having deep functionality. And in the best modules, the deep functionality is hidden behind a simple interface.

When reading this section, jQuery immediately came to mind. Before jQuery was uncool, it was the world’s most widely used JavaScript library and completely solved the problem of cross-browser compatibility in JavaScript. Today we take for granted that browsers mostly act the same but that was far from true in jQuery’s heyday.

jQuery was a deep module – it solved a problem completely and contained deep functionality hidden behind a very simple interface.

As a budding developer, using jQuery extensively taught me the importance of simple interfaces in driving adoption of your code.

Avoid classitis

The author makes a solid case against classitis – the compulsion (particularly in the Java community) to split everything into a new class.

But by splitting into new classes, you’re driving toward shallow modules. You’ve actually introduced complexity in the name of simplicity.

Separate special purpose and general purpose  code

When you’re performing a code review on a class, smell around for special purpose code mixed with general purpose code. This mixture represents an opportunity to split off the general purpose code into something more reusable.

Design it twice

As an engineering manager, I strongly advocate and sometimes even insist on designing systems twice or even three times.

Let’s say we’re designing the database tables for new functionality. I will often say things like:

  • Show me at least two ways to do this
  • What if we didn’t use the database at all?
  • What’s the dumbest and simplest way to do this?

I play devil’s advocate because I want my engineers to really think through and justify their design decisions, especially when those decisions involve data storage because data structures are unlikely to change once created.

A Philosophy of Software Design

How strongly do I recommend A Philosophy of Software  Design?
5 / 10

This book sits somewhere between Clean Code and Clean Architecture, but with less detail than either.

The first 100 pages of A Philosophy of Software Design are solid and worth reading. These first 100 pages feel like a primer for Clean Architecture.

However, the final 70 pages are filled with recommendations about code comments that I find hard to support. Most of the examples the author provides of useful comments could easily be replaced with better named variables and methods. Because of this poor advice, I can’t recommend this book for junior engineers.

Rather than read the last 70 pages, I would recommend Clean Code or Code Complete.