Brian W. Kernighan is one of the minds I most respect in history. I’ll spend a little time gushing.
Background
As he lays out in his Unix: A History and a Memoir, Brian wasn’t the guy who made most of the brilliant things in Unix. He was really the ultimate first user.
Brian would adopt and provide feedback and fixes. But he would truly understand what he was doing. He could turn around and teach anyone to use it. Originally it was internal documentation for making documentation within Bell Labs. Later it was the books he is famous for.
I’ll walk through my personal journey because it is a personal story and a one-sided personal relationship.
Enter C
In college, I decided to take Computer Science 101 because I liked programming. I had taught myself some QBasic, Pascal, and Delphi/Object Pascal, but never had any real training other than “Teach yourself X in Y days” books and practice.
I was a BioChem major at the time.
My school still used C where most of the rest of the world had moved to C++, and we had a lab of Sun equipment. From the moment I started using a Unix, I loved it. Everything made so much more sense than Windows NT. I could troubleshoot a problem without leaving the system because of the excellent error messages and online documentation.
I installed RedHat 4.1 from a CD I got in a magazine on my desktop and have been using Unix or Unix-like OSes since.
Our First Meeting
After taking CS 102, I understood the math (the actual point of those classes)
but I also knew how much I didn’t know. I was still fumbling around C. I had
a small set of things I knew by rote, and I could man fscanf. My text book
was good for the class but not for really understanding the language.
So I did what I usually do. I figure out what the most “legit” source is and I get that. So obviously, I bought K&R and dove in.
It was dense and technical, but I couldn’t put it down. I read it in 2 days. Then I read it again.
It didn’t just teach me the C ideas, but how to think in C. And really it just taught me a new way to think.
I switched from BioChem to CS right then. I needed more.
I knew that book was amazing, but I didn’t realize it was Brian in general.
It Wasn’t CS
While I enjoyed my CS coursework, I didn’t get that dopamine hit of K&R again. There were fun puzzles to be solved and topics to explore, but it was learning and not that meta-learning.
I had also wandered into Philosophy along the way and really got that there. Ancient and Early Modern were full of moments like that.
But I missed it in terms of technology. So I sought out more.
I picked up a used copy of Brian and Rob Pike’s The UNIX Programming Environment. It was directed to an audience using a terminal tied to a PDP-11. That really made it better to me. I didn’t just understand how things worked in Unix at large, but the history of why they worked that way.
I’d been using Unix for years at that point, but again, it let me not just see UNIX, but see the world from UNIX.
It’s The Author
That’s also when I realized that it wasn’t K&R or even Bell Labs. Brian Kernighan has incredible ability.
He doesn’t just teach about the topic but from it. His writing is very technical, but it also has a humanity to it that makes it extremely readable.
On the Network
I really was fascinated by networking. Our dorms were hooked together with
hubs, since switches were still expensive. That made it really easy for me to
drop my NIC into promiscuous mode and tcpdump away. It was also before
everything was done over IP.
There was TCP and UDP, but also NetBEUI, IPX/SPX, etc. But the internet was really becoming a thing then, and I wanted to learn more.
Again, looking for “the source” to learn, I picked up W. Richard Stevens’s TCP/IP Illustrated Volume 1. It had that same quality and the most incredible diagrams.
As I dig more into the front matter I see 2 things: Brian edited. They used ROFF.
I’ll save my troff/nroff love affair for another time. Maybe something on
all of the text layout tools I’ve used.
But you could see Brian’s hand guiding that book. It isn’t the same as his own writing, but you can see a lot of the key qualities.
Life Moves On
I kept pursuing my career and interest in computers, but I also loved the eye opening experiences. I ended up sucked into my job and dropping out, coming back to school and finally graduating with a Philosophy degree.
I’d stick Brian Kernighan right next to great philosophy minds that shaped my thinking: Aristotle, Descartes, Kant, Hume, James, Rawls are a few.
And I’ve kept reading his works as I can. When I found he had co-written The Go Programming Language, I picked it up and it accelerated my adoption of Go. I still prefer a lot of practices in the book to their more modern counterparts.
His Memoir
UNIX: A History and a Memoir is an incredible work. It’s humble and informative. It has lessons about technology, teams, business, work ethic, and so much more. And it covers first hand accounts of things I had only hearsay to go on.
But it also surprised me. I’ve used awk for 20 years. Admittedly, I’ve
never been great and mostly programmed by looking at docs or Google. But his
work describing it made it click for me.
Awk is to text what SAX is to XML before those were conceived of, and in a way that is simpler and more flexible. It’s all events, callbacks, and state. I immediately went from using it when I ended up being cornered into it, to understanding when it was the best tool for the job. It made my awk code much more understandable and maintainable.
And another thing is that it (like most things I’ve learned from him) influenced what I make in other languages.
Parting Thoughts
Even more than that, the perspectives he’s given me apply to organizations and
business processes. Understanding awk gave me ideas to improve developer
experience at work. I learned from Brian, I built things, worked with people,
and shared ideas. Now software developers can more quickly get the tools they
need, the access they need, and the infrastructure they need to deliver
business value. And in that process we reward and enforce “good” behavior.
Through the flow of the process, and dealing with those events, we ensure that
we capture just enough state to make getting the right things the easiest
things.
It gave me another view to look at my passion.
OK, a Quick Aside on That
People are efficient. All living things are. If they weren’t, they’d be dead. But you can also call “efficient” in this sense “lazy” and “shortsighted.”
We all have at least something that we care about where we cast this aside. Maybe you don’t understand why people don’t exercise, write good documentation, maintain their car… whatever. But for every one of those you have there are 1,000 more you don’t care about, because you don’t have to and if you cared about all of them, you’d be dead.
And if you’re like me, you obsess on 1 or 2 at a time, but neglect them later. Human beings change and are inconsistent.
So if you want people to do “the right thing” you can’t write down rules. You can’t just document. You can’t berate, lecture, or even teach and expect to have widespread impact.
You have to make “the right thing” the easiest possible thing to do. If “right” is “efficient,” then people will do “right.”
People are like electricity. They will take the path of least resistance to their destination. Make that path what you want it to be.