Software I Admire That I Didn't Write

writing

The software I think about most is not written in TypeScript or Python. It is mostly C. SQLite runs inside my iPhone, my browser's storage layer, and the Firefox profile on my laptop. Nginx is probably handling some request I am making right now. Git runs every time I save work. I have read documentation for all of these. I have filed a bug report against one of them. I have never written a meaningful program in any of their primary languages.

I find this interesting as a category. There is software that I use constantly and understand well enough to configure and debug, but that I could not have built — not because of effort, but because the engineering discipline involved is genuinely foreign to me. The people who wrote SQLite or ripgrep were optimizing for things I have never had to optimize for. Reading about how they work has changed how I think about the software I do write.

14 of 14 · click any row to expand

What the C programs have in common

The C programs on this list were all built before most modern software tooling existed. No package managers, no memory-safe languages, no ubiquitous cloud infrastructure. The constraints forced a kind of design discipline that is less common now: small binaries, no external dependencies, explicit memory management, portable by default.

SQLite's commitment to backward compatibility is the most extreme version of this. The library guarantees that a database file written in 2004 will be readable by any future version. That kind of constraint, held for 25 years, is almost unimaginable in web development. We break APIs between minor versions.

What the Rust tools changed

ripgrep and fd are not just C programs rewritten in Rust. They are fundamentally better tools. ripgrep is faster and has better defaults. fd has a sane syntax. The improvements came partly from Rust's performance characteristics, but mostly from someone sitting down and thinking carefully about what the tool should actually do and being willing to make different default choices than the Unix tools they replaced.

The Rust programs are also easier to contribute to than the C programs because the safety guarantees make the reviewer's job easier. A pull request to ripgrep that compiles and passes the tests is almost certainly memory-safe. A pull request to a C codebase requires the reviewer to mentally execute the change looking for use-after-free and buffer overflows. That difference affects the rate at which communities can accept outside contributions.

What I actually learned

Reading about how these systems work has changed how I write TypeScript and Python in a few specific ways. Studying how Redis implements its sorted sets made me much more careful about when I reach for a sorted array versus a different data structure. Understanding how SQLite handles concurrent reads made me think differently about locking strategies in the services I build. Reading about V8's hidden classes made me write JavaScript objects more carefully — consistent property order across objects, not adding properties after construction.

I am not going to write a production C program. But understanding what the people who did write them were optimizing for — and why those constraints produced the designs they did — seems like useful context for writing software in any language.