Two people start at opposite ends of a 31-km forest trail; one walks quickly at 5 kph, while the other manages only 4kph. Where in the trail do they meet?That's a paraphrase of a GMAT prep site (which I'm not criticising at all, since it's exactly the sort of thing you need to be able to do for the GMAT (which I'm also not criticising at all)). When I started teaching introductory programming in the 1980's, a lot of problems we set were of the same sort: Here's a very simple problem you care nothing about that you have to solve in a particular way because there's one basic technique we want you to learn. For the math-talented, solving the equations was easy, but they hated translating the words into the equations. For the math-impaired, the equations were boring or scary and the "story" wasn't the least bit compelling.
I think we can do a lot better.
I've learned four relevant things since those days, which I can symmetrically and geekishly divide into two groups of two.
- First, I learned more about teaching. My employer's Centre for Teaching and Learning exposed me to problem-based teaching and a variety of techniques about teaching with groups. My kids' schooling taught me about the difference between formative and summative assignments; you don't have to use exactly the same kind of problem for learning as you do to for assessing.
- Second, I developed a personal view of why we "formalise" anything. I started teaching "requirements analysis", which is kind of the same thing as word problems, on steroids, for software geeks. I also started describing software design techniques mathematically; part of my intended audience was better at the math and part at the software design, but I had to be comprehensible to each. In both contexts, you study a complex real-world problem, find parts that can be translated into math, manipulate the math to get a formal answer, then translate that answer back to a solution to the original problem.
So if you're teaching time-distance-rate problems, how about the following?
Mary and Martha are sisters who like to meet each year to exchange Christmas presents and have dinner together. Mary coordinates seminars at a hotel on Dixon Road near Pearson Airport and can blow off the rest of the workday somewhere between noon and 1:30. Her last three speeding tickets are for 25, 37, and 29 kph over the limit. Martha works at the Tim Horton's on Division Street in Kingston, gets off work at exactly 2pm, and always drives at the speed limit. Which exit should they pick for a meeting, assuming neither wants to make the other wait more than absolutely necessary?To someone who thinks they're supposed to focus on solving equations and eliminate irrelevant detail, this is horribly over-complex. The thing is, in the real world anything interesting is even more complex. That very complexity helps motivate why we need math but also puts it into a context where other skills are also important -- like digging up more facts by asking people questions, or deriving one equation for several closely related scenarios, or deducing plausible assumptions about someone's average driving speed from their moving violations, or using a Famous Web Search Engine (New Scientist's trademark-avoiding phrase) to find the Highway 401 exit number for Division Street (and whether the OPP have radar that accurate). The problem-based approach appeals to our mental hardware for stories, shows both the math geeks and the math-impaired how math can be useful, and helps each group appreciate the other's talents.
I can't be sure, since I don't teach the appropriate grade, but I think Mary and Martha's problem would work a lot better than something about two generic people converging along a straight line.