You can dismiss Writing Solid Code as a paltry set of rules for writing C for a vanished era of PCs, but if you put it in context, if you read between the lines a bit, this is an amazing book.

It's 1993. Microsoft is near the height of its powers: Windows 3.11 is released that December. Windows 95 development is under way. The FTC closed an investigation into Microsoft abusing its monopoly power. All that really bad stuff came later—settling one Department of Justice investigation, Bill Gates' "Internet" memo, the United States v. Microsoft Corp., Gates' terrible deposition in that trial, the Halloween Documents, Windows ME, Clippy, the consent decree, "Developers, developers, developers," Mark Penn. Maybe 1993 was where 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 clearly on the horizon but it's not "here". But it has one foot firmly in the future. Survey the rules. They're 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, well debugged compilers, and a relatively homogeneous platform. Software people today could learn something from Writing Solid Code, which doesn't evangelize C, which doesn't bash Pascal programmers as morons, but instead makes some opinionated arguments about "the way we should be doing things" that are deeper than "use React."

On the other hand, as successful as Microsoft was at this time, everything turned out to be rotten. The idea that the software succeeded on its merits is seriously tainted by all of the antitrust stuff. The idea that this code was "solid" is belied by the Trustworthy Computing memo, the Longhorn "reset", and so on.

So... yeah. Sometimes I pick this book up and appreciate it on its superficial merits; other times I think about it in the context of how complicated and f-ed up things got.

This is down in the weeds but there's one practice recommended in Writing Solid Code which has fallen by the wayside, and that is stepping through your code in a debugger. So many programming environments are hostile to debugging; so 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 when the control flow is hard to follow because the execution point is flitting everywhere; it tells you when the abstractions are helping you understand and when they're in the way. You have to see it. Even—especially—if you think there aren't any bugs left.