Yesterday, I sat down over coffee with the Fog Creek system administrator and learned how a specific piece of our network architecture works. As he talked and I asked questions and tried saying things in my own words, and we drew diagrams and annotated them, I learned something about how I try to understand a complex system.

1. First: the big parts/components and their functions.
2. Next: understand the desired and usual flow of data/blood, from entering the system to exiting it. Here I try to see things from the perspective of a single data packet, blood cell, or what have you.
3. Next: what's enforcing the rules, and what's pushing the data/blood through the system? What are possible attacks or failure points? And what defenses are built in to resist or recover from attacks or failures?

Without even meaning to, I was taking Neal Stephenson's advice to heart:

Windows 95 and MacOS are products, contrived by engineers in the service of specific companies. Unix, by contrast, is not so much a product as it is a painstakingly compiled oral history of the hacker subculture. It is our Gilgamesh epic....

...Unix has slowly accreted around a simple kernel and acquired a kind of complexity and asymmetry about it that is organic, like the roots of a tree, or the branchings of a coronary artery. Understanding it is more like anatomy than physics.

--Neal Stephenson, "In The Beginning Was The Command Line" (1999)

So I've articulated a possible plan of attack for learning computer-related architectures. Another: just dig in! Try something small and concrete, and learn as you go. But I've found that, once I try to do anything even mildly complicated with OSes, filesystems, networks, and what have you, I get quite uncomfortable unless I can find out the structure and foundations of the domain. So now would be a good time for me to take classes in data structures, algorithms, networking and architecture, etc. Maybe I'll make my own summer crash course.