John K. Ousterhout

Writing computer code provides a programmer incredible freedom, but writing good code that'll work in a team environment is a trickier assignment. Many coders fall back on whatever guidelines their manager issues, but that approach can obscure the real challenge. Not only is someone programming a computer to achieve a certain goal, but that person is simultaneously writing a letter to their future self and fellow programmers about what they are trying to do. Clear communication is as much a show more part of the challenge as getting the code to work in a maintainable fashion. In this book, John Ousterhout of Stanford University guides newer and mid-career programmers how to write better code.

Computer programmers can be famously inflexible with personal coding standards. Whether one agrees with Ousterhout on ever issue or not - I certainly didn't - reading about others' understanding of coding increases your tolerance of other programmers. It simply makes you a better teammate. We all need better teammates, and it starts with you and me personally.

He hits on all the major issues good programmers talk about with each other: when to write comments, how to construct self-documenting code, how to design deeply effective classes, and more. These are not challenges that are mastered once-and-for-all; rather, they are daily challenges with each programming assignment. Even as someone who has been programming for decades, he helped me see my craft in small, new ways.

The obvious market for a book like this are newer and mid-career programmers. But advanced programmers often benefit from reviewing the main themes from a master craftsperson; indeed, at the very least, they can learn how to express themselves to their mentees. I slowly skimmed this book but slowed down for thoughts that I may not have had explored before. Coders of every ilk like learning by doing, but learning-by-doing has to be supplemented by coaching. Most supervisors don't have the time to do that in depth, so reading books about coding becomes essential. This one should certainly be on the reading list. show less

The creator of Tcl is alive and well and teaching CS somewhere. And that is part of what makes this book great - common software design failures are drawn from examples in his classroom, so he is able to explain the reasoning behind a design choice, and then explain how to do it better.

The presentation is much less formal (and shorter) than the usual software design tome, which makes it a quick read.

It's a short book and I didn't find anything I disagree with: it's all really good advice. show more Ousterhout takes issue with classitis (lots of shallow, simple classes that do one trivial thing) and rightly blames Java for the rise of this style. In discussing industry trends, he takes a quick shot at test-driven development, and is much more diplomatic than I would have been ("you're not writing software! you're debugging code into existence!"). Nothing is said about devops (aka Paying A Single Worker To Perform Two Jobs), though. show less

Good software design can be taught. Thoughtful.
Design software to reduce complexity. Complexity is caused by obscurity and dependencies. A simple interface for a module is more important than simple implementation. Error handling makes a lot of complexity; design errors out of existence. Software should be easy to read rather than easy to write. The increments of software development (for sprints or additions) should be abstractions, not features.

Opinionated and somewhat antithetical to other software engineering books out there. Ousterhout is perhaps most famous for his research on storage systems, and his approach to software reflects his low-level expertise.