I frequently find myself coming back to this quote from the first lecture:
And that is that computer science, in some sense, isn't real. You see, when an engineer is designing a physical system, that's made out of real parts. The engineers who worry about that have to address problems of tolerance and approximation and noise in the system. So for example, as an electrical engineer, I can go off and easily build a one-stage amplifier or a two-stage amplifier, and I can imagine cascading a lot of them to build a million-stage amplifier. But it's ridiculous to build such a thing, because long before the millionth stage, the thermal noise in those components way at the beginning is going to get amplified and make the whole thing meaningless.
Computer science deals with idealized components. We know as much as we want about these little program and data pieces that we're fitting things together. We don't have to worry about tolerance. And that means that, in building a large program, there's not all that much difference between what I can build and what I can imagine, because the parts are these abstract entities that I know as much as I want.
I know about them as precisely as I'd like. So as opposed to other kinds of engineering, where the constraints on what you can build are the constraints of physical systems, the constraints of physics and noise and approximation, the constraints imposed in building large software systems are the limitations of our own minds.
Love the story of the Rad Lab and radar before and during WW2. Two relevant books I've read recently(ish) that I'd recommend to anyone interested in learning more would be 1) The Invention That Changed the World by Robert Buderi and 2) a biography of Alfred Loomis, Tuxedo Park by Jennet Conant.
The foreman had pointed out his best man - what was his name? - and, joking with the puzzled machinist, the three bright young men had hooked up the recording apparatus to the lathe controls. Hertz! That had been the machinist's name - Rudy Hertz, an old-timer, who had been about ready to retire. Paul remembered the name now, and remembered the deference the old man had shown the bright young men.
Afterward, they'd got Rudy's foreman to let him off, and, in a boisterous, whimsical spirit of industrial democracy, they'd taken him across the street for a beer. Rudy hadn't understood quite what the recording instruments were all about, but what he had understood, he'd liked: that he, out of thousands of machinists, had been chosen to have his motions immortalized on tape.
And here, now, this little loop in the box before Paul, here was Rudy as Rudy had been to his machine that afternoon - Rudy, the turner-on of power, the setter of speeds, the controller of the cutting tool. This was the essence of Rudy as far as his machine was concerned, as far as the economy was concerned, as far as the war effort had been concerned. The tape was the essence distilled from the small, polite man with the big hands and black fingernails; from the man who thought the world could be saved if everyone read a verse from the Bible every night; from the man who adored a collie for want of children; from the man who . . . What else had Rudy said that afternoon? Paul supposed the old man was dead now - or in his second childhood in Homestead.
Now, by switching in lathes on a master panel and feeding them signals from the tape, Paul could make the essence of Rudy Hertz produce one, ten, a hundred, or a thousand of the shafts.
As a mentor, I like to set explicit expectations for how much time someone should spend digging before asking for help, and I encourage others to do the same.
For an intern or new grad whose information gathering skills likely have gaps they don't even know about, I'll tell them to come check with me if they're completely blocked and haven't made progress for an hour, as it's frequently a small pointer or hint from me that can get them back on track. As they get more more knowledge about the systems and experience unblocking themselves, this grows to half a day, a day, and more from there.
The same applies even for experienced engineers who are new to the team, though the timeboxes grow much faster. There will always be little things to learn, and there's no point burning a day of chasing threads if it's some quirk in the system you just happen to not be aware of.
On a much less optimistic dark humor note, this is the same argument in If Anyone Builds It, Everyone Dies about a superintelligent AI emerging and being a threat to humans.
I remember learning about the complex pumping machines running some of the reservoir pumps in Boston (https://en.wikipedia.org/wiki/Metropolitan_Waterworks_Museum), where they made such distinct noises when working (and malfunctioning) that an engineer could diagnose the problem by ear.
I sometimes think about what a modern analogy would be for some of the operations work I do — translate a graph of status codes into a steady hum at 440hz for 200s, then cacophonous jolts as the 500s start to arrive? As you mentioned, no perfect analogy as you get farther and farther from moving parts.
Reminds me of the purported Ralph Waldo Emerson quote which rings true for myself as well: “I cannot remember the books I've read any more than the meals I have eaten; even so, they have made me.”
Free, high quality learning materials like this are an absolute treasure, and without them, I wouldn't be where I am in my career today.