Like it or not, technologies are a part of our lives today and show no signs of completely going away. While I resonate with those advocating for more time spent outdoors in unstructured environments, dream of working for hours in my own garden someday, and often have new-Luddite sentiments about a variety of topics relating to technology, I remain a staunch advocate for the thoughtful and appropriate uses of technology to improve learning and our lives more generally.
Given this reality, it is essential we recognize the importance of technical troubleshooting skills and intentionally seek to cultivate these inside and outside our classrooms. I was intrigued to hear Dr. David Thornburg discuss the importance of “tinkering” in the contexts of learning and development at the TCEA conference in 2006, particularly in the context of the logo programming language. John Seely Brown is another advocate of tinkering, as well as thoughtful educational reforms which I respect. My notes from his interview with Steve Hargadon last year, “Architecting School 2.0,” includes some of my earlier reflections on “tinkering” and how we need to be intentional about encouraging tinkering. John notes that for past generations, who repaired their own flat bike tires and may have generally had more opportunities to work with tools and raw materials to build treehouses and other creations, “tinkering” may have been a more common, incidental play activity than it is today for many media-focused young people more attracted to their console game than a traditional toolbox. Given these realities, and the importance of tinkering and troubleshooting, I’m convinced we need to not only talk more about the importance of these learning activities but also WORK to provide and encourage these activities both formally and informally.
My experiences both in the classroom, in administrative support roles in education, and now working as an education advocate for a telecommunications company continually reinforce the importance of troubleshooting. Why don’t our teacher certification programs at least require a rudimentary introduction for students of successful strategies to resolve a copy machine paper jam?! I can’t tell you the number of times I’ve had to wrangle with a copy machine, NOT because I want to immerse myself in the technical details of fixing a paper jam, but because I HAD to get something done (copied) and no one else was available at the time to assist me. This reality and need has been present not only in elementary schools where I’ve taught, but also in non-instructional work settings.
This morning, I had an opportunity to help some co-workers troubleshoot a problem with a PowerPoint presentation which was, for some inexplicable reason, misbehaving. They needed to embed two sound files to auto-play in the presentation. The first file on the first slide worked fine, but the last music file wouldn’t play consistently. It wouldn’t autoplay at all, and sometimes would play when the visible icon during the presentation was right-clicked. Left clicking didn’t work. Renaming the file, re-inserting the file, and changing the auto-play options didn’t work. Finally I suggested converting the mp3 file to a WAV and seeing if we could get the file to autoplay as a WAV. Preso! That worked. Everyone was happy.
What lessons can we draw from this situation? There are several keys to successful technical troubleshooting. Two of these are:
- Past experiences (background knowledge or schema) from past troubleshooting experiences on which to draw ideas. Often this knowledge is acquired tacitly “on the job” rather than explicitly in formal instructional settings.
- Creativity: The ability to creatively brainstorm and “try out” different possible solutions to a given problem.
I am glad to be able to help different people troubleshoot different technical problems, and I have had this role (even if it hasn’t been an official part of my job title or role) for many years. Organizations and work cultures always require and utilize “go to” people for different tasks. Who can fix this? Who can figure this out? If you develop a reputation of competency in the field of technical troubleshooting, watch out! Word will “get out,” and if you’re not careful you can find yourself beset with EVERYONE’s technical problems to troubleshoot! One of my former professors often joked about the benefit of “projecting incompetency” when it came to other individuals within an organization, particularly those who assigned “committee roles.” Sometimes it seems those without apparent skills are rewarded within an organization by NOT getting tapped for new assignments or tasks, while those who project competency and gain a reputation as someone who “gets things done” seem to get punished by receiving an overload of formal as well as informal assignments within the organization. I’ve often thought this dynamic should be written up as a formal organizational theory. I’ve seen and experienced this repeatedly so I KNOW it exists. I’m surprised no one has formalized a theory about this yet. If you read this and go out and write up the theory, you have to at least give me a “shout out” somewhere in your publication!
One way to tangibly and intentionally help students cultivate their technical troubleshooting skills is by having a student technical support helpdesk for teachers and peers at school, and include a certification program like TechYES. Another way, particularly for schools implementing 1:1 laptop learning programs, is to include free Scratch software on every computer hard drive image and find ways to encourage as well as support its use for both formal learning as well as play.
I agree with Dr. Gary Stager and others who contend every student should learn to program. The problem solving and creative troubleshooting skills which are developed when learners write computer programs must be INTENTIONALLY cultivated inside and outside of our classrooms today much more than they are in most “traditional” educational settings. Kids need to tinker more so they can develop experiences as well as the creative capacities to be effective technical troubleshooters.
Have you played with Scratch software yourself yet? What’s holding you back? Ah yes, of course. TIME. That’s the number one obstacle we all face for any instructional change proposal. How will we find the time?
We definitely need educational reform in our nation which acknowledges the already overloaded nature of teachers’ “plates” at work, but in the specific context of Scratch software and encouraging tinkering / troubleshooting maybe we need to rephrase the above question. Instead of asking “How can I find the time?” perhaps we should ask “How can I make the time?” Are any of the schools or educational professional development organizations in your area offering a summer workshop institute on Scratch? If not, ask them to. There’s no telling where some dedicated time and your own creativity can take you, as well as your students who can likely benefit from more avenues for constructive, digital tinkering.
Check out Wesley's new ebook, "Mapping Media to the Common Core: Volume I." (2013) It's $15!
If you're trying to listen to a podcast episode and it's not working, check this status page. (Wes is migrating his podcasts to Amazon S3 for hosting.) Remember to follow Wesley Fryer on Twitter (@wfryer), Facebook and Google+. Also "like" Wesley's Facebook pages for "Speed of Creativity Learning" and his eBook, "Playing with Media." Don't miss Wesley's latest technology integration project, "Mapping Media to the Common Core / Curriculum."
On this day..
- Student Oral Reports with School Hallway Dioramas via AudioBoo - 2013
- Manipulated FoxNews Video Shows Why eBooks are the WRONG Choice for K-12 1:1 Environments - 2011
- Civil War Augmented Reality Project Becomes HistoriQuest - 2011
- Photo memories in an old box - 2010
- WordPress for iPhone 2.2 Even Better - 2010
- Fun with XTimeline and myWebspiration - 2009
- Howe Oklahoma Students lead virtual field trip at Fort Smith, Arkansas - 2009
- BYOB - Bring Your Own Bandwidth - 2008
- Podcasting from the Windows side - 2007
- Criticizing policies not people - 2007