Learning by tinkering

Liveblog notes from “Learning by tinkering”, an IET Technology Coffee Morning given by Marian Petre on 7 September 2011.

The talk is a mash-up of three related research strands:

• First strand is with children in robotics, with Jeff Johnson. Robocup Junior, Robofest – rich research base.
• Second is a long-term observational study of children as end-users at home pursuing their own objectives – children as unwitting programmers.
• Third stream is her primary work – empirical studies of expert software developers.

Children have always appropriated their toys – Papert, Logo. Distinction between programming in the course of play, and programming as a definite activity. Adults’ and kids’ views of the toys can diverge. Construction toys have been around a long time, very compelling for children – kids tinker, build, un-build. Components are almost wilfully tedious individually, so construction is the primary mode of play.

Computing is a routine part of play for kids, hardly away – it’s the milieu Papert was proposing. 14yo: “That wasn’t programming, that was simple.” – the programming-ness went un-noticed. If you called attention to it being programming, he’d turn away from it!

First strand – robotics

Jeff Johnson reckons robotics offers special educational leverage. Appealing combination of factors – only e.g. Meccano and computer games match up. Models of living things kids can experiment on. Incredibly concrete learning. Abstractions they derive are really grounded and very relevant to them and their goals. Open-ended problems, so learn problem-solving techniques. Argument that if you support this work effectively, students can generalise in really powerful ways. Motivates move to project-based learning in science.

Observed and interviewed all teams at RoboFest Robocup Junior in 2001. Clear that they had learned stuff – programming. Even kids as young as 8 understood programming in RCX code or Robolab wasn’t exactly what they did in school but was relevant and transferable. Learned about gearing, hardware, electronics, difficulties of robotics and simulation and complex systems – and working with teams, people, persistence, imagination. One team were from a school for kids excluded from other schools – and had learned about e.g. algebra, gearing – because goal of making it behave the way they wanted to behave was so powerful. Learned improvisation, learning from making mistakes.

Second strand – kids at home

Watched them over 18 months, and friends online, talked to them, observed home settings, co-located interactions. Fundamentally was parental observation – not exactly objective, but naturalistic, and long-term. 11/12/13/14yo, with diverse social group 11-17yo.

Mucking around on the Internet -> complex activities. Starts at level of tweaking parameters (e.g. colour change to dress). Then composing components to make new designs – re-adapting library objects (skins, widgets); built-in infrastructure that rewards cleverness. Authoring tools for interactive simulations, animations, games – e.g. Gamemaker, KPL, Flash – and Minecraft. Minecraft is effectively electronic Lego. Social space with an etiquette to it too.

Lot of stuff with kids is in an educational context. As soon as it smells of formal structure, they lose interest. KPL is a big hit – Kid’s Programming Language. Writing programs to do interesting visual things, picking up working code, experimenting, tweaking (hacking!). Now not as accessible to kids. Games and cheats – nothing is sacred, everything can be altered.

Not really about learning, about them achieving their goals. But fairly complex insight and understanding evident.

Model of programming is very much around assembly of components. Protected from some of the issues of large-scale software development – certainly no full version control! But can reason about modifications and consequences, and potential interaction of components. So spontaneously introduce disciplines – e.g. design for re-use, for readability by others.

But they still don’t think they’re programming – they think they’re playing with toys. Tinkering is the main thing, and the environment scaffolds that. So they tinker even when it’s not explicitly supported. They do generalise from e.g. published game cheats.

Motivations in social interaction, making cool stuff – without adults. Putting it in school is kiss of death, doesn’t matter how cool the environment is – e.g. Gamemaker, Alice – then when teacher picked up on it, they dropped it. They need to preserve idea that they’re just messing around.

Scaffolding – rich libraries of interesting things (so can get good results very quick), good tutorials (last resort), help, access to expertise (key thing – reinforcement for being clever, insightful when e.g. get an answer from the original designer of a game you’re modifying), opportunities to share user-created programs.

Starts with ‘see the cool thing I can do’. Socialising drives the tinkering.

Then ‘intelligent games’. Kids often do things in school to get round Internet controls. The controls don’t pose much of an obstacle, so doing something directly against it is boring. But they invent games, re-appropriating the Internet through play. Using resources to set challenges to each other, interestingly competitive.

Games: ‘Pseudo-friend’ game. Create in Facebook, see how many Friends that fake person attracts – social psychology, experimentation. ‘Simulate my sister’ – program that generates 14yo girl’s phrases (like Eliza/Turing test) – good social observation. ‘Internet collage’ game – meme photograph manipulation – mash up images, sound – kids are not just consumers.

Tend to be creative, inventive, imaginative, conceptual nous, often getting around constraints. Tend to be mischievous, not rebellious – pushing boundaries rather than smashing. Not arbitrary, but not predictable – field of play can expand. Also competitive.

Third strand – expert practice

Compare to expert practice. Experts – super-designers, generalist problem-solvers. People who can hold whole architectures in their minds right down to detailed consideration. Drive high-performing products, on time, budget, spec. Many resonances – use very systematic practices that are socially embedded; they play/tinker/bricolage, always seeking cool opportunities, blue skies; amazing tolerance for error – opportunity, not failure – being surprised by something; reflective practice.

In expert practice, tools support toys. Expert software engineer trying to solve a scheduling problem. Wandered around the building where people bring hobbies to work, including a dismantled racing car strewn across a corridor. Exhaust manifold beautifully shiny, stared at it for a while … and then said ‘ah!’ and went back to fix his problem. The tubes, bent in to shape in a confined space, gave an insight in to the scheduling problem.

Environments that succeed for kids: rich libraries; immediacy of results (effects clear); forum for sharing successes; room for growth and progression.

Less successful: hard to download and install; bad interface; no way to start tinkering by modification of existing things; or are too educationally wrapped.

These are our future students – able to wield tools, in context of social engagement. Doing clever stuff is more fun in the vivid social context of intelligent play. How can we harness that inventive, critical, analytics, mischievous set of properties and bring it in to how we teach. Crosses boundaries, thumbs nose at lesson plan – challenge in how we structure education system.

Final example – the SenseBoard – the toy going in to the new entry-level computing course TU100 My Digital Life. Can connect sensors, inputs, outputs, with plug-and-play functionality. Using programming language that takes away syntax issues. Get people tinkering from the beginning and drive the learning that way.

Questions

Richard: We shouldn’t actually be supporting these activities, we should be trying to prevent them, because otherwise it’ll turn it uncool.

Marian: Not exactly. Design studio – set activities that are open, take photograph, submit. Really interesting – even in that context, very prescribed (about learning to upload) but incredible imagination expressed. Can do some of it, but not all of it. Scaffolding, empowerment, play – are things we can incorporate. Already in some courses.

Mark: Boundary territory. BBC B and A computers, school, and home – also Raspberry Pi at the moment. Would be cool to push out some of the stuff from this course without signing up for it. Can hack around, leverage resources from the courses. Boundary between formal and informal. As kids, we went round a friend’s house to use computer, subverting things from school.

M: Tells us about our roles as educators. Not the same learning in the two types of contexts. E.g. of working with RCX code – doesn’t have variables but does have counters. 8yo, struggling, said what I really need is a place to put things, stuff I can remember, so I can call it back – articulated concept of a variable out of his need. Simultaneously in Uppsala engineering undergrads struggling with concept of variable. Key is, needed adult to say ‘hey, that’s a variable, here’s how you can do it’ – it’s about how we can structure things to segue in to a more structured and complete model. We can’t be replaced. Whole notion of reflective, learning dialogue is fundamental.

Perry: Not just for kids, but adults, academics. Social scaffolding included ‘usable help’. Can you expand?

M: One real issue is kids doing this in context of own goals. Help is useful when it’s relevant to my goals right now. Don’t want some random discourse about a philosophy of programming, or a tool – they want an answer to a question, how do I fix this now. Difference between a traditional error message – highly compacted . Andy Coe (?) version, enables you to point at a line and say why did that happen – debugging assistant would help elucidate. Was highly contextualised response.

Sandra: What children are doing sounds like what we’re doing in our research. We play around. To get here, we had to pass exams. It’s a shame that’s the way the world works. How do you bridge the gap between allowing them to play, and bridge over to the theory so they can take exams.

M: Working with robotics team, mentoring them – already a body of pedagogic literature, project-based learning. How we do that in distance education is a challenge, I don’t have an answer. Lots of different kinds of learning, and that’s cool, but we don’t have to do it directly. We do in the OU appeal to some of this stuff. Looking at how they work in casual settings might help us impose less.

Sandra: Kids as soon as it gets to school they get turned off.

M: Had summer interns, very bright, very systematic engineering, really nice work. Some of their A level results are risible. Why is education system not serving these bright young things? Academic software engineers do a lot of tinkering, very informal – that community has challenge in informal tinkering phase (thought products) to re-usable, robust tools phase.

Someone: Insight for software companies? Programmer’s job often has very little play.

M: High-performing teams already get this. They tolerate racing cars in the corridor! They have slush funds for mucking around. If you have a deliverable coming up, that’s what you do. But in fallow periods, encourage innovation. Disciplines of innovation.

Someone: Definitely not like this in e.g. bank environments.

M: Programming factories don’t get it. But the top-end, producing new concepts.

Liz: Google a good example of this.

M: Friend went to Google, felt like a Grandma because over 50.

Rob: Proximity of play and tinkering. Tinkering, it already does something already. Play isn’t necessarily purposeful, could be e.g. aesthetic. Is play right analogy?

M: They are different. Tinkering can be part of play. Play can be a character of tinkering, at its best. But not the same. For teaching, the tinkering is important, but has to have a playful aspect to it.

Liz: Conference a few years ago about learning and teaching programming, one keynote had CS4FN – computer science for fun.

M: Paul Curzon. Book Computing Without Computers. Really imaginative book, couldn’t publish, but is available online.

Liz: Hole-in-the-wall project. Let kids loose, not adult-directed. Incredible.

M: Alice was an amazing effort (with big investment) oriented to schools, but could create animation in 30 min. CS101 in 30 minutes, getting ice-skater to skate round a hole then fall in. Not mutually exclusive, but interesting tension between contexts.

Liz: 11-13yo girls – noticed particular gender divide. If work in CS Dept, in a university, the joke is that you could go weeks without seeing a girl. Reported biases in e.g. girls not liking sciences. But with playing, social element, may not find that so much.

M: Don’t have a sample representative enough to answer bias definitively. But casually – yeah. Even in robotics, girls’ teams are fabulous, wonderfully imaginative. Feathers were really important to them. Comparable levels of sophistication, but choose a different arena. E.g. storytelling. Had stated aversion, was really pronounced. Are overlaps, but also separations. What they do in sims.

Liz: Competitiveness more pronounced in boys?

M: No, just expressed differently.

Mark: Interests may be different, very intriguing. Social media may change environment. Rich research in there.

M: Not a great fan of gender studies, more interested in individual differences. Concern that may reinforce divisions. I didn’t look at gender issues. There are more boys than girls doing robotics, but there are mixed teams, girls teams, all doing good stuff. Internet may challenge that, talking across boundaries. E.g. age – 8yo talking to 14yo. When talking across, people who won’t talk in school will talk on the Internet.

Liz: Friend did PhD on gender difference in learning programming. Looked at KS3, KS4. Looked at spatial processing, gender differences there lead to difference in how they learn programming, but not in learning. Boys marginally quicker on average. More important to be good role model, not interfere in girls wanting to do that. There are stereotypes that are reinforced e.g. by peer pressure.

M: What we can show statistically across populations … we can still find exceptions. Men are on average stronger than women … but who cares? Can find women stronger than a man. Almost have the whole range of intellectual activity packaged up in to programming.

–
This work by Doug Clow is copyright but licenced under a Creative Commons BY Licence.
No further permission needed to reuse or remix (with attribution), but it’s nice to be notified if you do use it.