Meta: this project is wrapping up for now. This is the first of probably several posts dumping my thought-state as of this week.
Moving on to other things?
NaiveTortoise
Karma: 804
A thing I really structured to capture was that “i did actual research and had actual models for why masks would help against covid, but it’s still not type-3”, which is why “know why” doesn’t feel right to me.
I share this feeling based on my understanding of the boundaries you’re trying to draw.
I tentatively think that some of what you’re calling engineering knowledge would fit into what I call scientific (which is a strike agains the names), and/or that I didn’t do a good enough job explaining why engineering knowledge is useful.
Yeah, like I said, I don’t want to bike shed over terms but I do think the distinction between science and engineering is an interesting one. Regarding the “and/or” isn’t it more like there’s often an interplay between the levels? First we get “folk knowledge” and then we “do science” to understand it and then we use that science to “engineer” it?
Also, I found an Overcoming Bias post where Robin quotes Drexler on the distinction:
The essence of science is inquiry; the essence of engineering is design. Scientific inquiry expands the scope of human perception and understanding; engineering design expands the scope of human plans and results. …
Scientists seek unique, correct theories, and if several theories seem plausible, all but one must be wrong, while engineers seek options for working designs, and if several options will work, success is assured. Scientists seek theories that apply across the widest possible range (the Standard Model applies to everything), while engineers seek concepts well-suited to particular domains (liquid-cooled nozzles for engines in liquid-fueled rockets). Scientists seek theories that make precise, hence brittle predictions (like Newton’s), while engineers seek designs that provide a robust margin of safety. In science a single failed prediction can disprove a theory, no matter how many previous tests it has passed, while in engineering one successful design can validate a concept, no matter how many previous versions have failed. ..
Simple systems can behave in ways beyond the reach of predictive calculation. This is true even in classical physics. …. Engineers, however, can constrain and master this sort of unpredictability. A pipe carrying turbulent water is unpredictable inside (despite being like a shielded box), yet can deliver water reliably through a faucet downstream. The details of this turbulent flow are beyond prediction, yet everything about the flow is bounded in magnitude, and in a robust engineering design the unpredictable details won’t matter. …
The reason that aircraft seldom fall from the sky with a broken wing isn’t that anyone has perfect knowledge of dislocation dynamics and high-cycle fatigue in dispersion-hardened aluminum, nor because of perfect design calculations, nor because of perfection of any other kind. Instead, the reason that wings remain intact is that engineers apply conservative design, specifying structures that will survive even unlikely events, taking account of expected flaws in high-quality components, crack growth in aluminum under high-cycle fatigue, and known inaccuracies in the design calculations themselves. This design discipline provides safety margins, and safety margins explain why disasters are rare. …
The key to designing and managing complexity is to work with design components of a particular kind— components that are complex, yet can be understood and described in a simple way from the outside. … Exotic effects that are hard to discover or measure will almost certainly be easy to avoid or ignore. … Exotic effects that can be discovered and measured can sometimes be exploited for practical purposes. …
When faced with imprecise knowledge, a scientist will be inclined to improve it, yet an engineer will routinely accept it. Might predictions be wrong by as much as 10 percent, and for poorly understood reasons? The reasons may pose a difficult scientific puzzle, yet an engineer might see no problem at all. Add a 50 percent margin of safety, and move on.
Good question, yes I know what you mean. I don’t think these are great labels but to me the categories seem like reguritated facts, pre-scientific empiricism / folk knowledge, and science and engineering. Admittedly I know these don’t make great section headings, so I’ll think more about better names.
Another comment mentions “know what”, “know how”, and “know why” which I suspect captures some of what you’re getting at but not all of it? Only some because there are different types of whys within levels 2 & 3, right?
One more point that may clarify things: I think you’re lumping applying science to the problem of making things under science whereas to me that’s the essence of engineering. That is, the scientist seeks to understand things for their own sake whereas the engineer asks “what can I build with this?” Again these are obviously idealized, extreme characterizations.
With respect to COVID, we ought to allocate some credit to engineering for building the high-throughput systems that enable rapid testing and experimentation. We also will require some impressive engineering to scale up vaccine production once we hopefully have a viable vaccine.
Not to quibble on words and categories but this feels like a straw man of engineering knowledge that reinforces the view I’ve mentioned before that people here often have a bias that causes them to think of engineering as “trivial” or “easy”. As I understand it, you’re arguing that engineering knowledge only allows local improvements whereas science allows global optimization, whereas I feel like the reality is murkier but something like what Jason Crawford described in his recent post on shuttling between science and invention. I’m also partial to Eric Drexler’s framing where science is about universal quantifiers—the space of mechanisms—whereas engineering is about existential quantifiers—if there exists even one way to do something, then let’s find it. This is a little abstract so I’ll discuss a few of your examples.
To take your example of hybrid cars, yes inventing hybrid cars’ components certainly required scientific breakthroughs but their economic feasibility heavily benefited from improved engineering of both batteries and cars. I’m not an expert on this but I feel like as a general statement it’s hopefully not that controversial?
Related to this, the thing you mention about car maintenance is discussing mechanics, who are distinct from engineers. Consider an alternative statement, “yeah it’s good that cars are 10X cheaper than they used to be, but the important thing was inventing the internal combustion engine in the first place.” Isn’t this a more balanced comparison for the role of engineering and science in car production?
Happy to go into more detail but will stop here because I’m having trouble anticipating whether my comment will 1) provoke disagreement and 2) which aspects are confusing / most likely to be disagrees with.
This reminds me of Mary Carruthers’s comparison of characteristics people emphasize when they talk about Einstein vs. Thomas Aquinas and the way in which memory palaces played an integral role in not just recall but composition for medieval thinkers. Unfortunately, it’s too much text to copy, but I’ve taken screenshots of the relevant pages and uploaded them here.
This is awesome! I’ve been thinking I should try out the natural number game for a while because I feel like formal theorem proving will scratch my coding / video game itch in a way normal math doesn’t.
Minor note—having spent significant time in multiple homes with one dog and more recently a home with multiple, my anecdotal observation is that even just having 2 dogs changes the dynamic from dog obsessed with humans to dogs that have each other and are maybe still obsessed with their humans as well.
Are you putting yours on paper or storing it digitally?
(Not the author, obviously.) Part of my personal intuition against this view is that even amongst mammals, lifespans and the way in which lives ends seems to vary quite a bit. See, for example, the biological immortality Wikipedia page, this article about sea sponges and bowhead whales, and this one about naked mole rats.
That said, it’s still possible we’re locked in a very tricky-to-get-out-of local optima in a high dimensional space that makes it very hard for us to make local improvements. But then I suspect OP’s response would be that the way to get out of local optima is to understand gears.
Only related to the first part of your post, I suspect Pearl!2020 would say the coarse-grained model should be some sort of causal model on which we can do counterfactual reasoning.
FWIW as someone who learned Python first, was exposed to C but didn’t really understand it, and then only really learned C later (by playing around with / hacking on the OpenBSD operating system and also working on a project that used C++ with mainly only features from C), I’ve always found the following argument quite suspect with respect to programming:
(FWIW I’ve made the same argument in the context of training programmers, preferring that they have to learn to work with assembly, FORTRAN, and C because the difficulty forced me to understand a lot of useful details that help me even when working in higher level languages that can’t be fully appreciated if you are, for example, trying to simulate the experience of managing memory or creating loops with JUMPIF in a language where it’s not necessary. Not exactly the same as what’s going on here but of the same type.)
It’s undoubtedly true that I see some difference before & after “grokking” low-level programming in terms of being able to better debug issues with low-level networking code and maybe having a better intuition for performance. Now in fairness, most of my programming work hasn’t been super performance focused. But, at the same time, I found learning lower level programming much easier after having already internalized decent programming practices (like writing tests and structuring my code) which allowed me to focus on the unique difficulties of C and assembly. Furthermore, I was much more motivated to understand C & assembly because I felt like I had a reason to do so rather than just doing it because (no snark intended) old-school programmers had to do so when they were learning.
For these reasons, I definitely would not recommend someone who wants to learn programming start with C & assembly unless they have a goal that requires it. This just seems to me like going to hard mode directly primarily because that’s what people used to have to do. As I said above, I’m fairly convinced that the lessons you learn from doing so are things you can pick up later and not so necessary that you’ll be handicapped without them.
(Of course, all of this is predicated on the assumption that I have the skills you claim one learns from learning these languages, which I admit you have no reason to believe purely based on my comments / posts.)
It seems not that conscious. I suspect it’s similar to very scrupulous people who just clean / tidy up by default. That said, I am very curious whether it’s cultivatable in a less pathological way.
Yeah good idea.
I’m interested in reading more about what might’ve been going on in Ramanujan’s head when he did math. So far, the best thing I’ve found is this.
How to remember everything (not about Anki)
In this fascinating article, Gary Marcus (now better known as a Deep Learning critic, for better or worse) profiles Jill Price, a woman who has an exceptional autobiographical memory. However, unlike others that studied Price, Marcus plays the role of the skeptic and comes to the conclusion that Price’s memory is not exceptional in general, but instead only for the facts about her life, which she obsesses over constantly.
Now obsessing over autobiographical memories is not something I’d recommend to people, but reading this did make me realize that to the degree it’s cultivate-able, continuously mulling over stuff you’ve learned is a viable strategy for remembering it much better.
I would recommend the other writers I linked though! They are much more insightful than I anyway!
Sadly, not much. I wrote this one blog post a few years back about my take on why “reading code” isn’t a thing people should do in the same way they read literature but not much (publicly) other than that. I’ll think about whether there’s anything relevant to stuff I’ve been doing recently that I could write up.
Sometimes there are articles I want to share, like this one, where I don’t generally trust the author and they may have quite (what I consider) wrong views overall but I really like some of their writing. On one hand, sharing the parts I like without crediting the author seems 1) intellectually / epistemically dishonest and 2) unfair to the author. On the other hand, providing a lot of disclaimers about not generally trusting the author feels weird because I feel uncomfortable publicly describing why I find them untrustworthy.
Not really sure what to do here but flagging it to myself as an issue explicitly seems like it might be useful.
For what it’s worth, this is very true for me as well.
I’m also reminded of a story of Robin Hanson from Cryonics magazine:
Source