Is Writing Solid Code a paltry set of rules for writing C, for a vanished era of PCs? Yes, but if you put it in context, this is an amazing book.

It's 1993. Microsoft is near the height of its powers: Windows 3.11 will be out that December. Windows 95 development is under way. The FTC closed an investigation into Microsoft abusing its monopoly power. All the bad stuff came later: Settling one Department of Justice investigation. Bill Gates' "Internet" memo. The United States v. Microsoft Corp. and Gates' terrible deposition in that trial. The Halloween Documents. Windows ME. Clippy. The consent decree. Sweaty "Developers, developers, developers." Mark Penn. 1993 was the threshold over which it all went wrong.

Writing Solid Code doesn't portend any of that turmoil. It has one foot in the past. Pascal. The 68000. C++ is on the horizon but not "here". But it has one foot in the future. The rules are a confident argument about how to build things. Use compiler warnings. Write tests and assertions. Build subsystems and check things at the boundary. Shape API ergonomics to avoid errors. Be conservative.

Today these are common practice. Today we have tons of resources. We have well debugged compilers. We have less heterogeneity—JavaScript is everywhere. Writing Solid Code doesn't evangelize C, nor bash Pascal programmers as morons. Instead it makes some opinionated arguments about "the way we should be doing things." Arguments that are deeper than "use React."

That said, as successful as Microsoft was then, everything turned out to be rotten. Software succeeding on its merits? Tainted by the antitrust stuff. That this code is "solid"? Did not survive connecting to the internet. It did not scale to "Longhorn."

So... yeah. I pick this book up and appreciate it on its merits. Other times, I reflect on the context of how complicated and f-ed up things got.

There is one practice recommended here which has fallen by the wayside. That is stepping through your code in a debugger. Many programming environments are hostile to debugging. Many programmers rely on logging and not debugging. Debugging gives you a tremendous feel for what you're making the poor machine do. It tells you the control flow is hard to follow because the execution point flits all over the place. It tells you if the abstractions are in the way. You have to see it. Even—especially—if you think there aren't any bugs left.