ECOO 2016 Reflections: maker spaces and iteration

The maker movement isn't a fad to
engage students.  The people who
believe in it live it.

Back from the 2016 ECOO Conference, I've let things mull over for a couple of days before reflecting:  

On maker spaces...

Last year's conference was very excited about Maker Spaces, and that focus seems to have died down.  To develop meaningful maker spaces means believing in and adopting the thinking behind it.  The people behind the maker movement believe in it passionately, they live it. Education's ADD means that making was never going to go that far in the classroom.  The moment I heard teachers complaining about the extra work makerspaces created I knew it was doomed.  Most teachers aren't curious about how things work and don't want to play with reality, they're concerned about delivering curriculum.  

I suspect many maker spaces in classrooms have become either dusty corners or play areas.  It was nice to see the monolithic educational system flirt with something as energetic and anarchistic as the maker movement though, even if it was only for a short while.

On Iteration...

This came up a several times in the conference.  A couple of years ago Jaime Cassup gave an impassioned keynote on the value of iteration.  His argument, based on the software industry's approach to building code, was to fail early and fail often.

This time around Jesse Brown brought it up again, citing Edison's, I didn't fail a thousand times, I found a thousand ways that didn't work quote.  He then (strangely) went on to compare his being let go as a radio broadcaster and lucking in to a tech startup as an example of iteration, which it isn't.  Doing one thing and then stumbling into something completely unrelated when it ends isn't iteration.

In education this misunderstanding is rampant.  Good students learn to do what they're told as efficiently as possible in order to succeed in the classroom ('lower level' students are much more willing to take risks - they're not as invested in the system).  A misunderstanding of iteration is what we use to justify and even encourage failure.   It has become another way to let digital natives' video-game driven process of learning have its way, but it isn't very efficient.

There is iteration in the engineering process, but it's never
a fail early, fail often approach. If you don't know why you
failed then you shouldn't be rushing off to fail again.

The other week I gave my grade 12 computer engineers detailed explanations of how to build a network cable, a video showing it being done and then posted wiring diagrams showing the proper order.  The most capable students followed engineering process (a directed iterative process, rather than a random one) and produced working network cables more and more quickly.  The end result was no real cost for me (all my ends and wires were made into functional cables).

The majority of the students, perhaps because they live in our brave new Google world of fail often and fail early, or because people keep misquoting Edison at them, didn't read the instructions (who does any more, right?) and just started throwing ends on cables, crimping them badly and producing failure after failure.  This is great though because they're engaged, right?

When I got angry at them they were belligerent in return.  How dare I stifle their creativity!  Unfortunately, I'm not assessing their creativity.  They are trying and that's all I should be asking for!  I'm not grading them on engagement either.  I have been brandishing the engineering process throughout their careers in computer technology, but these video-game driven iterators think their die early, die often approach in games is perfectly transferable to the real world.  Bafflelingly, many educators are gee-whizzing themselves into this mindset as well.  You'll quickly find that you run out of budget if you do.