Posts
This approach not only complicates the simplest of math problems; it also leads to delays. Under the Common Core Standards, students will not learn traditional methods of adding and subtracting double and triple digit numbers until fourth grade. (Currently, most schools teach these skills two years earlier.) The standard method for two and three digit multiplication is delayed until fifth grade; the standard method for long division until sixth. In the meantime, the students learn alternative strategies that are far less efficient, but that presumably help them "understand" the conceptual underpinnings.Once again, knowledge stored in memory is entirely different from knowledge stored on Google.
Biological memory is a biological process that requires a period of time during which new memories are consolidated:
Memory consolidation refers to the idea that neural processes transpiring after the initial registration of information contribute to the permanent storage of memory.I don't know how much time the brain requires to consolidate memories, but I recall John Medina suggesting that the figure may be as long as 10 years. (That would jibe nicely with the 10-year rule for development of expertise, wouldn't it?)
Memory consolidation, retrograde amnesia and the hippocampal complex
Lynn Nadel* and Morris Moscovitcht Cognitive Neuroscience
The "consolidation lag" between first learning a new skill and really knowing that skill explains why "just-in-time" learning is so crazy. There is no such thing as just-in-time learning. The brain doesn't work that way. No matter how smart you are, if you are 17 and you don't know how to do long division, you can't just have your professor show you how and then start doing it. Knowledge has to be consolidated before you can use it well, and consolidation takes time.
Here is James Milgram on his experience teaching Stanford students who had not been taught long division:
What happens when you take long division out of the curriculum? Unfortunately, from personal and recent experience at Stanford, I can tell you exactly what happens. What I'm referring to here is the experience of my students in a differential equations class in the fall of 1998. The students in that course were the last students at Stanford taught using the Harvard calculus. And I had a very difficult time teaching them the usual content of the differential equations course because they could not handle basic polynomial manipulations. Consequently, it was impossible for us to get to the depth needed in both the subjects of Laplace transforms and eigenvalue methods required and expected by the engineering school.There is no just-in-time learning, and you can't catch-up.
But what made things worse was that the students knew full well what had happened to them and why, and in a sense they were desperate. They were off schedule in 4th and 3rd years, taking differential equations because they were having severe difficulties in their engineering courses. It was a disaster. Moreover, it was very difficult for them to fill in the gaps in their knowledge. It seems to take a considerable amount of time for the requisite skills to develop. [emphasis added]
Transcript of R. James Milgram
1999 Conference on Standards-Based K-12 Education
For the sake of argument, say it takes two years to consolidate the skill of adding and subtracting double-digit numbers. (I'm guessing it takes more than two, but I don't know.) If a child learns to add and subtract double-digit numbers in second grade, he or she will be proficient in fourth grade.
Delay teaching the algorithms until fourth grade and now you have a cohort of students who won't be proficient in addition and subtraction until 6th grade.
That's the way it works. Two years is two years.
and see:
Eide Neurolearning explains elaborative rehearsal

13 comments:
That transcript is great. From it:
The problem is that the scope of things in mathematics is so long that an ordinary second, third, fourth grade teacher is not equipped to make a judgment about whether a subject is needed or not needed.
I read that interview years ago & then re-read it again & again. The idea that these very smart Stanford students could not ***immediately*** make use of brand-new long-division knowledge has always stuck with me.
New knowledge isn't the same as old knowledge, and we have at least one folk saying that capture this phenomenon: knowledge has to "sink in."
Agree with you on the passage about elementary school teachers not being equipped to make a judgment about what is and what is not needed.
If folks don't mind a little mercenary self-promotion, a friend and I grew disgusted enough with what passed for educational software that we decided to start our own company to make some for tablets. Our first app allows children to practice longhand arithmetic; yes, including division.
I finished the web page for it just this weekend:
http://www.edisongauss.com/blackboard-math-app/
Includes a rant about what's wrong with so many math "games." Regards.
Oddly, our district has replaced its 5th grade curriculum (a bad, crazed combination of EM with enVision only used in all schools for two years) with...the 6th grade curriculum (which is connected math @@).
The reason for this is said to be that the Core Curriculum requires more earlier -- which seems to be the opposite of what's here?
One can learn things fast. It's hard work, but it also helps to have a good teacher or textbook and more than a little motivation. However, you can't just listen to a lecture or be part of a hands-on group. You have to do it yourself, as with homework sets. Cramming is not the same thing because you are trying to speed up the process too much. Often, cramming implies that you are taking short cuts with practice. You read the material and think you understand, but you really don't.
My son's piano teacher says that it makes a big difference whether you have performed a piece in concert (memorized) rather than just practiced it at home, even if you think you have it concert ready. That makes it easier to bring the piece back up to that level later on. Most music conservatories expect students to learn and perform one new piece a week. However, you have to live with a piece for awhile before you can improve it to the next level. There are different levels of understanding, and they are all tied to understanding by doing, not understanding by talking.
I once decided to learn everything in a vector calculus textbook I happened to have. I was going to go through the whole book and make sure I understood every detail. No trouble, but I didn't do too many of the problems. It didn't last in my head. I set the book aside and went back to it six months later. It was like starting over. If I continued to work with the material, that would have helped, but that wasn't all that was needed. I needed to really dig in and do the work in detail. You can speed up the process, but you can't skip over the hard part of mastery. There is linkage.
I notice that with my programming work. There's nothing like getting a program to work correctly that forces you to REALLY understand what's going on. There is no room for fudging or waving your hands. You can't explain using words. The explanation is the code. There is a HUGE gap between conceptual understandings and true mathematical understandings. With computer programs, managers LOVE documentation, but the best documentation is well-organized programs and clean code.
With math, the explanation is the math, not prose. You can offer conceptual understanding using words, but that's not mathematical understanding. Textbooks explain things with words only as a start. You really don't understand the material until you have successfully worked many problems and variations.
I did a test long ago related to programming that had to do with whether you can really understand things with words or even diagrams before you do the work. This relates to many systems analysis techniques that focus on top-down analysis and design before you write one line of code. Even though most of those techniques use diagramming and organizational tools, there is still a lot of hand waving about the details. I was in one project "walk-through" where one wave of the hand glossed over 25 percent of the code in the system.
My test involved a very simple case of writing one function routine to do one task. With functions, you pass in a fixed set of variables (data) and produce a specific result. I decided that I was going to write the exact lines of code to implement the function beforehand on paper. It didn't work. Everytime I did this and went to put the function into the program, it ended up changing, sometimes in not so simple ways. Sometimes, it was a matter that I changed my mind, but in some cases, I just got it wrong.
My general philosophy of programming now is that you can't know what you are doing until you do it. I'm a big proponent of prototyping. It solves two things. First, you have the psycological boost of having real tangible code early in the process. It may have a lot of missing parts, but it works. Each time I add on a new (small) part, it's easier to test and validate. The real benefit is that you build the program without any hand waving. Talk and diagrams allow you to go a long way while fooling yourself. Real code won't let you do that. You don't do this with no preliminary analysis, but it avoids the "analysis paralysis" that happens on so many large projets. So many analysis and design tools are really documentation tools, not thinking and detail tools.
In writing, I remember of all of the "web" and other thinking tools my son has had. I remember the formal source theme structure that I had to follow in high school; outlines, 3X5 cards, first, second, and nth drafts. I don't write like that now, even for technical papers. I open up Word and dive right in. What I write is a mixture of real text, notes, and bullets of things to cover. I try to formally write my opening. That forces me get real and to avoid hand waving.
Talk and diagrams are cheap. Many think that some sort of process can get you close to the details to make them simple. The idea behind the classic top-down analysis-design-code-test sequence is that when you get to the code part, it's automatic. Nope. It just pushes unknowns (risk) off to late in the project when you are already behind.
In the programming world, you have a conflict between the process and control people and the people who actually write the code. Programmers generally don't like any controls, but those in charge can be big control and process freaks, especially if they buy into some do-it-all concept of software development. It's worse when those people have either never written a line of code in their life or they were the bad programmers who opted for the managerial track. (You can see where I come from.)
I've been working on a government contract that prescribes the use of UML - Unified Modeling Language. They pick and choose what parts I have to follow. It's not too bad, but I clearly see how critical details are overlooked and how risk is pushed into the future. People generally have good feelings if they see nice charts and diagrams, but there are the dirty details that can feed back to alter your analysis assumptions. Diagrams DO help with basic concepts and analysis, but everything gets bogged down when you start moving into the design details. We have had real arguments over the need to produce detailed UML design documents for a large system before a single line of code is written. I told them that it's faster to put together a prototype system even if the code has to be rewritten. The detailed UML design process does not eliminate the risk of finding fundamental problems later in the process. No diagram or talking can do that.
Of course, fast prototyping is becoming the big thing. The assumption is that you really don't know what you are doing until you do it. However, even some of the process control freaks have gotten ahold of that. Any good idea can be ruined.
There is a big gap between initial analysis and design tools and the final product, whether it's math, programming, or writing. It takes a lot of practice and experience to bridge that gap. It's not a speed or rote process. You cannot completely diagram or process your way across it. In terms of learning, you need automatic mastery of so many basics. You can't understand or think your way there. Mastery and experience provide those key levels of understanding. Understanding doesn't provide the skills. Understanding without skills is almost meaningless.
Steve - that is **very** interesting! (I'm reading the story about you trying to learn everything in a vector calculus book.)
I'm trying to get the Cliff Notes version of 'maintenance' versus 'elaborative' rehearsal now----
From what I can see, working the problem sets would likely be a form of elaborative rehearsal, which is what you need to move new material into long-term memory.
My other question has to do with the 'two years is two years issue' -- how long does new knowledge need to 'marinate' to become easily transferrable, easily accessible, easily combineable with other knowledge, etc.?
Jenn, I suspect it's a result of moving more abstract concepts down the grades, while moving the exercise of actually doing the work up the grades.
But as Steve wrote, and I and many others would agree, there is no substitute for doing. Talk is cheap. It's only after you've done something enough times for it to sink in that you can really understand the concepts going on behind the scenes.
I don't think knowledge has to marinate. First, you have to learn it well. Then you have to use it. If you don't use it, you'll lose it. If you learned it well the first time, then it should come back pretty easily the next time, but that isn't automatic. Sometimes I look at old code I wrote and think that it's either wrong or that I must have known something that I've completely forgotten. I remember that I did know it very well, and I know that I could get back up to speed ... some other time.
In some cases, I think that the first learning experience is inspiring and you are able to make many connections. Later on, your knowledge might stagnate. (I'm not talking about grade school math.) Feynman talks about how he was able to make great leaps of understanding during the first, intense, learning of a subject.
In the very short term, I've heard that two separate hours of learning on two days works better than two hours on one day due to what I suppose you could call a marination process. Some say that's true with piano practice. But I wouldn't call a process that takes two to ten years a marination process. If that's the case, then I flunk. I lose stuff over time.
I think there is, however, a limit to how much you can intensely learn at a time. You have to build up knowledge and skills bit by bit. To stop in the middle of differential equations to add in the learning of long division (without enough time) would be tough, but I wouldn't call it a marination effect. I would just say that they didn't set aside enough time to go from conceptual understandings to the understandings that come from doing a lot of examples.
In a proper math textbook, one should carefully do all of the homework problems. In the following sections and chapters, the textbook should keep you using and extending those skills. This is unlike Everyday Math, which does drive-by learning or what I call repeated partial learning.
Perhaps you could say that for many topics, the initial learning and practice has to get over some particular level to have any lasting effect. Otherwise, you have to start from scratch. I think that's a basic failure of Everyday Math.
Jenn, another way to put it is if we applied Common Core logic to learning to spell, we'd decide it's too hard and some kids have a really tough time with all the memorizing, so why not teach etymology first? Once children know the historical source of various word roots, they'll have a better understanding for which words use 'ei', and which words use 'ae' to get the hard A sound.
Personally, I think that's nuts. There is a place for etymology, but it's for those that already have a modicum (or more) of practical skill and are trying to make sense of what seems to be all the randomness.
Great article.
Post a Comment