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.”
That's a great call-out, and it (along with the change itself) underlines the importance of not letting fun get in the way of actual engineering improvements. Defunnification as a side effect, if you will.
I remember seeing this in React's __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED, and I've always enjoyed similar lighthearted and unwieldingly-long names.
Great, thanks for the pointer! I see it was published in 1999, so I imagine it’ll be a good time-capsule read too, even if it predates the dot com bubble burst and the eventual Oracle acquisition, though maybe that’s where the “Larry Ellison lawnmower” talk fills in well.
I enjoy historical books about the rise, fall, and everything in between for companies in the industry — things like The Idea Factory about Bell Labs, Dealers of Lightning about Xerox PARC, and Soul of a New Machine about Data General.
Are there any books folks would recommend like that about Sun?
That's a good question, and I could easily see the camera settings (and the light) being a source of error here. Naively, I used the default iPhone camera with the same exposure for each one, then ended up manually removing some of the HDR settings from each one when they were showing up as way overexposed on my computer. Not exactly an advanced, scientific technique, and there was also a bright source of soft white light from the window next to the setup, which could have thrown off the automatic exposure.
Another comment mentioned it, but I wonder if the overall effect would be more visible with yellower baseline oranges (or, as you mention, pale lemons and limes). Really interesting about the LEDs underperforming as well!
Taking another look, I think you're right! Particularly since the first orange is pretty orange already. I think the first example would have been better served with a yellower, less ripe orange to highlight the difference and the pull in the redder, riper direction from the bag.
For years, I've been good heartedly losing the blog SEO ranking fight to a great developer and writer who has the same name as me. A football player eclipses us both if you just google our shared name, but if you add any sort of "developer" or "programming", he's clearly got me beat for the top marks. It makes sense — he writes about tech much more consistently than I do, and his articles are likely much more helpful than my sporadic and eclectic posts.
Naturally, being vain, when I saw this post, I immediately looked up my own blog and was chuffed to see it at #292.
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.