On the suggestion of my father, I’ve recently picked and am working my way through up a copy of Where Wizards Stay Up Late. It’s a book documenting the invention of the internet, and comes hot on the tail of The Idea Factory – a book about all of the innovation that came out of Bell Labs.
Where Wizards Stay Up Late is a fascinating look into the engineering behind a lot of the world that I take for granted as a software engineer. Without getting into too much detail about the book (I plan to write a review when I’m finished reading it), I found myself amazed by one peculiar fact in particular:
When originally discussing what it might look like to connect several computers together, everyone involved seemed to use the word “network.”
Why is this worthy of amazement? Well, I suspect you’d be hard-pressed to find anyone today who had studied computer science who wouldn’t call such a thing a “graph.” OK, so what?
Graph theory is the study of things which are interconnected – things like highway networks, the connections between groups of people, the steps in a flow chart, and yes, the internet. The first paper on graph theory was written by Euler back in 1736, and the word itself was coined in 1878.
It’s curious that given all of this history, the engineers of the early internet (circa 1967 or so) didn’t use the word “graph” to describe their brain-child. The most obvious explanation is that they didn’t know about graph theory.
I consider myself to have a particularly good education. The stated goal of my five year program at university was to give me the skills necessary to build a modern computer from scratch. Which is to say, from the underlying physical principles, up through the necessary circuitry, to the design of the CPU and its memory, to the unending hierarchy of software necessary in order to actually get anything accomplished on the damn thing, to the protocols behind how you might get computers to talk to one another. This last part is the topic of Where Wizards Stay Up Late.
If you’re curious, I wrote a fun textbook a few years back walking through most of these topics. You can find it here. It’s targeted at someone who doesn’t know any of these things, but is motivated to learn for themselves. Obviously I’d recommend it ;)
Anyway, much of my formal education was split in a dichotomy: “here is how this stuff works” or “here is a widely applicable, yet very theoretical idea that will help you build things.” As broad categories go, they’re pretty damn useful for the process of I have this particular thing in mind and I want to build it.
And as of a month ago, I would have assumed that was all there was to it.
But Where Wizards Stay Up Late presents little tableaux of discussions of the engineering behind the early internet. And those discussions have awakened me to a vital skill that I wasn’t taught in university: the thought process that was the “why” behind the “how” of all of the cool things I now know how to build.
My university degree taught me how to apply familiar patterns to new domains, how to fit existing tools into different shapes. Don’t get me wrong – I’m overwhelmingly thankful for those skills, because we’re all standing on the shoulders of an incredible number of giants, and these are the best tools that they’ve handed down to us.
Unfortunately however, my university failed me and my colleagues in the skills necessary to hoist the next generation onto our shoulders. We were taught how to build things that have already been thought of, but not in the ways of thinking what should be built next.
Arguably this is a much harder skill, and one could make a point that such a thing is what graduate school is for, but reading through Where Wizards Stay Up Late has brought an obvious and salient example of a missed opportunity to my mind.
We took a class on computer networking. It was fun and interesting and had a lot of practical coursework. The final assignment was to write a computer program that implemented the TCP/IP protocol – essentially the backbone software underpinning all of the internet. Your computer used TCP/IP just now in order to download this essay so you can have the immense pleasure of reading. Thanks TCP/IP!
Without getting too inside on the baseball with you, the physical connections that form the internet are not very good. They corrupt random pieces of data all the time, send things in the wrong order, and you’re lucky if all of your data actually makes it to its intended recipient. But somehow despite this, the internet still works, and TCP/IP is the reason why. Essentially it’s the software that sits on top of these shitty connections and cleverly hides their duplicitous nature, showing instead a facade of everything working as it should.
As far as a project went, this was admittedly a value one to work through. Given that it’s such a fundamental piece of technological infrastructure, having pieced it together with my own hands was a great exercise into better understanding the world I live in. But I still maintain that it’s a missed opportunity: instead of saying “build TCP/IP” why not have instead asked for a protocol that provides the same guarantees as TCP/IP. Why not have said “we’re going to give you a way of sending data that sucks, and we want you to build something that will reliably get it from here to there.”
Solving this project would have taught me less about the world we live in, but it would have taught me a great deal more engineering.
TCP/IP is but one point in the design-space of reliable network infrastructure. There are infinite other solutions out there – most of which will work less well, but some which must in fact be better. It would have been a much more satisfying (and a significantly better learning-) experience, if after handing in our final project, we were then introduced to TCP/IP. Seeing the solutions and trade-offs that it makes would have taught me a lot about the problem, about how well my solution performed, and I guarantee you I would have paid more attention to its design.
Those who know me in real life will know that I spend an inordinate amount of time complaining about pre-university math education. I argue that things are taught the wrong way around – solutions are offered before problems. If you get a key before you have a locked door that you’ve contemplated being on the other side of, you’ve missed out on the curiosity behind the experience. Giving a mathematical tools that will solve a problem you’ve never cared about is not a particularly good way to get people excited about math.
But if you flip the experience around: find an interesting question and have someone puzzle over it for a long time without making any progress, well, that person is going to soak up any tools you subsequently provide them that might help. And the “aha!” moment when they finally work it out will not be one they forget.
Despite complaining about this like all the time, I somehow missed the completely analogous situations all the way through my university career. I was given tools and encouraged to think about them, but rarely (algorithm classes were a rare counterexample) was I given an open-ended problem and evaluated against an existing solution afterwards.
If any of what I’ve said here has struck a chord in you, I think I might have a solution. It’s too late to go back through university and attempt to persuade the professors to change their assignments to better facilitate this realization I’ve had, but it’s not too late to develop some of these skills.
For software, the most promising thing I’ve come across as of late is Conal Elliott’s work on Denotational Design. He begins with the question of “how do we know if software is correct,” which leads to “what does it mean for software to be correct.” And that’s when you fall into the rabbit hole and emerge two and a half hours later from the video with your worldview shattered, thinking fundamentally differently about everything you thought you knew.
For other specialties, I unfortunately don’t have any advice, other than there is likely low-hanging fruit to be picked off this tree. If teaching methodologies are poor in mathematics and in engineering, across different tiers of education, and is mostly invisible even to people who are looking for it, it’s likely to be an issue elsewhere as well. At the very least, it should inform the way that we intend to pass knowledge on to others.
I’ll leave you with a quote from the book that I found thought provoking.
“The process of technological development is like building a cathedral,” remarked Baran years later. “Over the course of several hundred years new people come along and each lays down a block on top of the old foundations, each saying, ‘I built a cathedral.’ Next month another block is placed atop the previous one. Then comes along an historian who asks, ‘Well, who built the cathedral?’ Peter added some stones here, and Paul added a few more. If you are not careful, you can con yourself into believing that you did the most important part. But the reality is that each contribution has to follow onto previous work. Everything is tied to everything else.”
-Katie Hafner, Where Wizards Stay Up Late
Related Posts
If you liked this post, you might also enjoy: