How I Write

Good technical books are like quality tools: the more you use them, the more valuable they become.

After enough years in Systems Programming and UNIX administration, you learn to separate signal from noise. The principles that underpin UNIX, the real behavior of memory, why concurrency fights you at every step, how I/O actually works—these things have not changed in decades and will not change in the next decade either.

My approach is simple and stubborn:

• Master the fundamentals first.
• Understand them deeply, not superficially.
• Break things on purpose, watch them fail, rebuild your mental model from the pieces.
• Then write it down so clearly that someone picking it up ten years from now can still follow the reasoning.

The books I return to most—K&R, Stevens, Pike & Kernighan—never tried to be exhaustive. They did not chase every API or framework. They taught you how to think. That is the only standard worth holding yourself to: respect the reader, trust the timeless ideas, cut every ounce of filler.

The language—whether it is C, Go, Zig, or something that does not exist yet—ends up being mostly notation. Get the concepts right and you can speak any of them fluently. Systems programming is systems programming.