You are here

First the work, and then the theory

I love this quote shared by Gary Stager via the Daily Papert.

“They first learn engineering, then from there they progress to learning the ideas behind it, and then they learn the mathematics. This would be inventing, it’s a little probe toward inventing a different kind of content. It’s not a different way of teaching; it’s not pedagogy. It’s different knowledge. It’s a good example of turning knowledge – turning learning – upside-down. Instead of starting with this abstract stuff we had from the nineteenth century, let’s start with stuff that’s really engaging for the children, out of which the deeper ideas can develop.” Seymour Papert, 2004

Instead of students learning a bunch of theory, and then being able to apply it to practice, they would engage in building and in creating, which would provide a need and a motivation for the knowledge behind the thing that they are building. One thing that is missing in great degrees from our school is motivation. Why do I need to learn this math when I can see no use for it?

It's not to say that there aren't fascinating ideas which are worth learning without something practical to support them, but this is not the general tendency of school. We do not usually teach (with obvious exceptions being good teachers) that which is interesting. We teach practical knowledge. We tend to say, "Oh, we'd like kids to be able to be doctors. Well, what do they need to know? Let's teach them that." with the result that students do not see the connection between what we teach, and what they can do with it.

About David

David is a Formative Assessment Specialist for Mathematics at New Visions for Public Schools in NYC. He has been teaching since 2002, and has worked in Brooklyn, London, Bangkok, and Vancouver before moving back to the United States. He has his Masters degree in Educational Technology from UBC, and is the co-author of a mathematics textbook. He has been published in ISTE's Leading and Learning, Educational Technology Solutions, The Software Developers Journal, The Bangkok Post and Edutopia. He blogs with the Cooperative Catalyst, and is the Assessment group facilitator for Edutopia. He has also helped organize the first Edcamp in Canada, and TEDxKIDS@BC.

Comments

Sorry, for bringing up programming into this, but I read an article that had a similar idea to your post.

It's titled "Nobody Wants to Learn how to Program." People just want to jump in, try to see what there is, try to see what they can do to accomplish a task, then the theory stuff becomes something of interest if nothing can be done.

Personally, I'm guilty of teaching theory first, then the get-something-up-and-running stuff later. Time and time again, I've noticed people lose interest in the craft of programming. If only I started out with HTML--which will actually show them a simple page that is actually something of value-- instead of going full on with Python for useless command-line programs.

Anyways, it's an interesting read. Check it out.

http://inventwithpython.com/blog/2012/03/03/nobody-wants-to-learn-how-to...

David Wees's picture

The post you linked to is absolutely appropriate. Learning how to program from for/loops and variable declarations is boring, and seems useless. You have no motivation for why you would want to learn about the various structures in programming, until you see them in action. So I'd say, let students see code in action, play with it, mess around with it, and when they want to understand it better, give something they can read they will help them disect the code.

See http://davidwees.com/content/automaticity-programming-and-math where I say almost the same thing but with slightly different reasoning.

I think I know why people go as far as to teach the boring stuff first: things will become a disaster without them. People that teach the theory stuff (myself included a few months ago) had a bad personal experience when they did not apply the abstract concepts.

I know, because I had one of those bad experiences myself.

I was working on a game, and me being a completely naive programmer, put all the logic in one big class, and in one big function. No abstraction between space ships, the enemies, the bullets. Everything were arrays of "vectors" (in the game programming world, a vector is a data structure with two floating point in it. That's it), one for the bullets, another for the enemies, and such and such.

And there was no separation of game logic, of drawing code, and audio. Worse, everything that ran the game was stuffed inside the main game loop. Never mind maintaining the code, just reading it was a mess!

I never ended up finishing the game because I gave up trying to add to it.

This is one of those things that I try to avoid. And this is one of those things that I want others to avoid.

But it turns out, that's exactly what deters people from doing what I'm trying to persuade them to do.

I think patience is key. Face it, people have to learn first, and only THEN will they appreciate a more formal theory to what they learn.

David Wees's picture

I think that was annoying to you, but you learned an important lesson - separate your code into smaller chunks as much as you can, and re-use code when you can. It's like someone telling you, "that oven is hot." You hear the message, but you don't get it until you burn yourself and you say, "Oh, that's what HOT means."

Hah, your burning oven analogy is actually pretty good. :) I'll keep that in mind when I teach the next person some programming.

Add new comment

Subscribe via email

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
AFCBCTURMSOZNOP
Enter the word shown above.

Links

Subscribe Subscribe to my blog

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer