This is a linkpost for https://g-w1.github.io/blog/observation/2023/07/08/shoot-yourself-in-the-foot.html
Why it's necessary to shoot yourself in the foot
14Adele Lopez
12Jacob G-W
8SarahNibs
5Said Achmiz
4Viliam
9Said Achmiz
1papetoast
New Comment
This is a good and interesting point, but it definitely isn't necessary for learning. As an example, I get why pointing even an unloaded gun at someone you do not intend to kill is generally a bad idea, despite never having had any gun accidents or close calls. I think it's worth trying to become better at seeing the reasons for these sorts of things without having to go through first-hand experience. This is especially relevant when it comes to reasoning about the dangers of superintelligence, as we will very likely only get one chance.
I think the idea actually works pretty well with superintelligence (with one big exception if you assume we all die). Lots of people don't understand how/why superintelligence could kill us all. They naively think that creating a superintelligence would be a great idea. If we all died, then they would understand why alignment is a necessary complexity. The only problem with this is that we are all dead.
https://blog.mrmeyer.com/2015/if-math-is-the-aspirin-then-how-do-you-create-the-headache/
Here is the most satisfying question I’ve asked about great lessons in the last year. It has led to some bonkers experiences with students and I want more.
- “If [x] is aspirin, then how do I create the headache?”
I’d like you to think of yourself for a moment not as a teacher or as an explainer or a caregiver though you are doubtlessly all of those things. Think of yourself as someone who sells aspirin. And realize that the best customer for your aspirin is someone who is in pain. Not a lot of pain. Not a migraine. Just a little.
Piaget called that pain “disequilibrium.” Neo-Piagetians call it “cognitive conflict.” Guershon Harel calls it “intellectual need.” I’m calling it a headache. I’m obviously not originating this idea but I’d like to advance it some more.
One of the worst things you can do is force people who don’t feel pain to take your aspirin. They may oblige you if you have some particular kind of authority in their lives but that aspirin will feel pointless. It’ll undermine their respect for medicine in general.
Learning Vue, July 2020: Why are there all of these complicated ways to represent state? Shouldn’t developing a web app be simpler than this?
After writing a bunch of vanilla JS, I can see why these frameworks could be useful. I have never made a very big web app, but I could see that keeping track of state and what is or isn’t rendered is hard and gets much harder with a bigger web app.
You should write a web app in vanilla JS before you learn a framework
I have built multiple websites with vanilla JS and I have yet to see any good reason to use a framework for the sorts of things I do. In fact, using a framework would make building something like, say, gwern.net considerably harder, as frameworks are heavily biased toward doing things the way most people do them, and make it very difficult to do anything really innovative and unusual.
Instead of "mistake" I would say "problem". Do not teach solutions to people who have not experienced the problem yet. Do not tell answers to people who have not heard the question yet.
You don't have to shoot yourself in the foot, but you need the experience of not knowing which direction to shoot at. That's when you imagine the possibility of accidentally hitting yourself.
*
I would also adjust the timing for the opinions at the end of the article. For example, I think it is good to use IDE for writing a "hello world" program, because that is the thing you are learning at given moment. Syntax highlighting and instant error checking is great to have for a beginner. The moment to try it without the IDE is probably when you can write the "hello world" reliably -- so that when the task is "write the hello-world program and compile it from command line", you won't get stuck at some stupid missing semicolon.
Don't learn two things at the same time. Using javac without being able to write hello-world doesn't make sense, so you either need to learn to write hello-world first, or you need to get the file from the teacher.
1
1Don’t learn two things at the same time. Using javac without being able to write hello-world doesn’t make sense, so you either need to learn to write hello-world first, or you need to get the file from the teacher.
I strongly disagree with this.
When I learned C (my first programming language), we wrote a .c file in a text editor and compiled them with gcc from a command line. This gave me a much better understanding of the process of writing (and using) a program than an IDE ever could have. I have, since then, learned other languages, and spoken to many people who were learning, or had learned, etc.; and I have noticed a definite pattern, that those who started with the basics (no IDE, no fancy tooling) ended up with a deeper understanding of what they were doing than those who started with the IDE and all that.
You can learn the advanced tools later, but you absolutely should “learn two things at the same time”, if those two things are “the thing you’re trying to do” and “the simple, basic way to do that thing”.
When teaching programming, we should let people make these mistakes, and then show them the tools to correct them.
We can also just teach them what mistakes are likely to happen and why, then show them the tools. Letting them actually make the mistakes will make them understand more deeply but I think it is usually not worth the extra time.