I always like seeing someone else on LessWrong who’s as interested in the transformative potential of SRS as I am. 🙂
Sadly, I don’t have any research to back up my claims. Just personal experiences, as an engineering student with a secondary love of computer science and fixing knowledge-gaps. Take this with several grains of salt—it’s not exactly wild, speculative theory, but it’s not completely unfounded thinking either.
I’m going to focus on the specific case you mentioned because I’m not smart enough to generalize my thinking on this, yet.
First let’s think about what design patterns are, and where they emerged from. As I understand it, design patterns emerged from decades of working computer programmers realizing that there existed understandable, replicable structures which prevented future problems in software engineering down the line. Most of this learning came out of previous projects in which they had been burned. In other words, they are artifacts of experience. They’re the tricks of the trade that don’t actually get taught in trade school, and are instead picked up during the apprenticeship (if you’re lucky).
If I were designing an SRS deck for the purpose of being able to remember and recognize design patterns, then, I think I would build it on the following pillars:
1. ” the name of the pattern on one side and the definition on the other”, as you suggested. These cards aren’t going to be terribly helpful right now, until I’ve gone through some of #2, but after a week or so of diligent review, their meanings will snap into place for me and I’ll suddenly understand why they’re so valuable.
2. ” names and examples ”, as you suggested. I am on the books as generally thinking there’s a lot of value in generating concrete examples , to the point where I’d say the LessWrong community systemically underrates the value of ground-level knowledge. (We’re a bunch of lazy nerds who want to solve the world-equation without leaving our bedrooms. I digress.)
3. motivations and reasons for those names and examples. Try taking them and setting up scenarios, and then asking “Why would design pattern X make sense/​not make sense in this situation?” or “What design pattern do you think would work best in this situation?” You’ll have to spend more than a couple seconds on these cards, but they will give you the appropriate training in critical thinking to be able to, later on, think through the problems in real life.
Hope some of this was food for thought. I might change this into a genuine post later on, since I’m on a writing kick the last couple days.
I always like seeing someone else on LessWrong who’s as interested in the transformative potential of SRS as I am. 🙂
Sadly, I don’t have any research to back up my claims. Just personal experiences, as an engineering student with a secondary love of computer science and fixing knowledge-gaps. Take this with several grains of salt—it’s not exactly wild, speculative theory, but it’s not completely unfounded thinking either.
I’m going to focus on the specific case you mentioned because I’m not smart enough to generalize my thinking on this, yet.
First let’s think about what design patterns are, and where they emerged from. As I understand it, design patterns emerged from decades of working computer programmers realizing that there existed understandable, replicable structures which prevented future problems in software engineering down the line. Most of this learning came out of previous projects in which they had been burned. In other words, they are artifacts of experience. They’re the tricks of the trade that don’t actually get taught in trade school, and are instead picked up during the apprenticeship (if you’re lucky).
If I were designing an SRS deck for the purpose of being able to remember and recognize design patterns, then, I think I would build it on the following pillars:
1. ” the name of the pattern on one side and the definition on the other”, as you suggested. These cards aren’t going to be terribly helpful right now, until I’ve gone through some of #2, but after a week or so of diligent review, their meanings will snap into place for me and I’ll suddenly understand why they’re so valuable.
2. ” names and examples ”, as you suggested. I am on the books as generally thinking there’s a lot of value in generating concrete examples , to the point where I’d say the LessWrong community systemically underrates the value of ground-level knowledge. (We’re a bunch of lazy nerds who want to solve the world-equation without leaving our bedrooms. I digress.)
3. motivations and reasons for those names and examples. Try taking them and setting up scenarios, and then asking “Why would design pattern X make sense/​not make sense in this situation?” or “What design pattern do you think would work best in this situation?” You’ll have to spend more than a couple seconds on these cards, but they will give you the appropriate training in critical thinking to be able to, later on, think through the problems in real life.
Hope some of this was food for thought. I might change this into a genuine post later on, since I’m on a writing kick the last couple days.