A while back, I came across a talk by Bryan Cantrill where he said something that really stuck with me: "software, like virtually nothing else that we engineer, can be made to be perfect." You can find the video here.
What I think he means by "perfect" is that our code does exactly what we tell it to do. When you write a line of code, the computer executes that line precisely as it's written. It's not like building hardware where you're dealing with manufacturing tolerances, materials that wear out, or heat causing unexpected issues. Our programs, in that sense, are more like math – defined and exact.
Now, it's true that the real world isn't quite that clean. The software we write still runs on physical hardware. So, yes, cosmic rays can flip a bit, or hardware can degrade. But the interesting part is we can often anticipate these things and engineer our software to be resilient to them. The underlying principle remains: the logic we craft gets executed faithfully.
The other idea that goes hand-in-hand with this is that there are usually no real secrets in software. When you're using a library or trying to figure out how a product works, you can almost always get to the bottom of it. Documentation is a starting point, but the source code? That’s the ultimate source of truth.
I really like how the Go standard library is so readable, and it's mostly written in Go itself. This isn't always the case; Node.js has a lot of C++ in its runtime, and Python has a lot of C. But with Go, if you’re curious about how, say, the net/http package actually works, you can just go read it. The package docs are here. If you click into any function, like http.Serve, you can get straight to the source code: server.go. You don’t have to just trust the docs; you can see for yourself exactly what’s happening.
I had to do this myself a while ago when I was trying to understand how SQLite handles transactions with virtual tables. I wrote about it here. The documentation didn't quite cover the specific failure scenarios I was worried about. So, I ended up digging into the SQLite C source code. The answers were right there.
Unless you're hitting a wall with a closed-source API, there's almost always a path to the underlying code.
For me, the big takeaway from all this is that software engineering isn't just about writing code; it's just as much about reading it. Because software can be "perfect" in its execution, and because we can often see the source, we have this incredible opportunity to truly understand the systems we work with, from the ground up. It’s how we learn, how we debug, and how we can stand on the shoulders of others to build better things.