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.
If you enjoyed this post and found it useful, subscribe to Wes’ free newsletter. Check out Wes’ video tutorial library, “Playing with Media.” Information about more ways to learn with Dr. Wesley Fryer are available on wesfryer.com/after.
On this day..
- Tags and Hashtag Literacy – 2022
- The Mobile Storyteller of North Canton City Schools, Ohio – 2018
- Security, Privacy, and Digital Citizenship (February 2017) – 2018
- Learning at #TXeducamp in Denton, Texas – 2016
- Find & Highlight Duplicates in Excel 2011 for Mac – 2015
- 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
Comments
10 responses to “Technical troubleshooting and tinkering are essential skills”
Wes,
What strikes me as problematic are teachers who simply are not curious. They do not seem to have the ability to think beyond the situation and are afraid to try things. They seem afraid to click on the “help” button. Or, when they do, they just look at the list of resources and topics that are generated and their head swims with confusion. I think there is a mindset here – deeper than the idea of tinkering with new technologies. It is simply the idea of tinkering. Period. This ties in with your idea of creativity. I have graduate students who just throw up their hands in frustration when their first few attempts at something don’t work, while others “google” for answers, use the help feature, ask each other, and ask me. Perhaps there are some clear personality traits of an effective technology-using teacher that are interrelated with traits of persistence and creativity.
I agree that some people seem to more naturally be “tinkerers” than others, and some seem entirely averse to the entire idea. This relates to the theory of people taking on “procedural” or “navigational” styles of learning. Those who are more navigational (these can be younger learners sometimes termed “digital natives,” but it can be older learners too) seem to be the “tinkerers,” while those who insist on “procedural learning” with step by step instructions are often the helpless ones asking for (or demanding) assistance when something goes wrong or looks different than it did during the workshop.
In addition to advocating for “tinkering,” I’m also an advocate for teachers (as well as all flavors of learners) embracing navigational learning styles which are supportive of problem solving as well as independent learning. We’ve got to get beyond this idea that I have to have my learning SERVED to me. Learning today can be increasingly self-serve. Self-serve learning is not available for people who refuse to tinker or experiment with navigational learning styles, however.
Curiosity IS key. I agree we need to be talking about and encouraging the constructive pursuit of curiosity inside out outside of classrooms too! What do we do with those teachers or students who seem to not be curious, however? This relates to what Miguel Guhlin and others are discussing about “passion based learning.” If we can help learners connect with ideas, topics, and issues about which they are passionate, often I think we find a seed for curiosity and perhaps also creativity for that specific person.
Wes,
I totally agree with your thoughts about tinkering and the need for students AND teachers to have basic troubleshooting skills. Unfortunately, I’ve found that teachers frequently throw up their hands at the first sign of trouble and use it as an excuse to avoid technology. A computer will never be as reliable as a chalkboard…
On a more encouraging note, we will be implementing a 1:1 program this fall and Scratch will be on every middle school machine. It has been a great tool for teaching “tinkering” in our math classes and we are going to make it a larger part of the curriculum. Gary is right; every student should learn to program and Scratch is a perfect way to get them (and their teachers)started.
With technology there is still a fear by users who are afraid they will blow up the computer if they try something different, and others that know that there is no problem. As you stated, some of us grew up pounding boards into trees to make a “fort” and from that we have a good idea of how to make structures. Some of us have time to mess around and try different things on the computer and with that we learn how the structure works.
Many teachers do not have the time to mess around with the technology to get it to work, just like I really don’t have the time to work on my car, nor do I have the desire. We have been preaching that computers are a tool for teaching and learning, but we really don’t experiment with tools, they do what we expect them to do and nothing else.
I like to explore, some folks do not, what makes the difference? I don’t know.
Most of the “tools” that we use are really not uni-dimensional, like the screwdriver or hammer. These are tools that just get picked up and used. The router, on the other hand, takes some training and a great deal of practice to master. I would be foolish if I picked up a router after seeing someone demo it and expect to be able to create a masterpiece. And, I would also be foolish to blame my crude attempt on the router or the person who told me about the router. However, if I see a need and experience a desire for its use, I will persist. I would suspect that those who don’t persist, tinker, or experiment with technology-based tools either have little need or desire to make it happen (finding time is a problem that we all face). So, how do we approach teachers with either of those mentalities? I think that we have a pretty good idea after many years of research and implementation (failed and successful). These ideas just don’t get applied all that consistently. I think that ACOT had it right oh so many years ago. (http://www.apple.com/education/k12/leadership/acot/library.html)
Wes –
I very much agree with you. I find it frustrating as an elementary “computer” teacher to have my students CONSTANTLY stare blankly at a computer screen and then shout across the room to me asking for help when an instruction doesn’t immediately pop into view. I’ve started using the acronym RATS (I did NOT come up with this, but am not sure where I initially read it) with them. It stands for Read All (of) The Screen. Very simple, but it helps them remember that if they get stuck, oftentimes reading the entire screen/window will help them troubleshoot. If this works so well with 4th graders, I would think that it would be easier to instill in other educators! Not so, unfortunately.
Thanks for the mention, but can we please stop using Luddite so freely? The Luddites were not against or afraid of technology. They were pro-employment.
One powerful idea required by programming is debugging. This used to be the main justification for computers in the classroom, but you rarely hear debugging discussed this day. This is not surprising when the wretched new ISTE Standards don’t mention programming or computer science once while alleging support for creativity. Such and anti-intellectual stance denies children agency over the machine and rich learning opportunities.
Bricolage, a French word for tinkering, is explored in this seminal work by Sherry Turkle and Seymour Papert, two experts who remain unread by too many educators.
I recommend investing the effort required to understand “Epistemological Pluralism and the Revaluation of the Concrete”
http://papert.org/articles/EpistemologicalPluralism.html
BTW: Who tinkers with a router? I hardly thinks that is in the spirit of what Thornburg, Papert and I mean by tinkering as a form of knowledge construction. The router has a very narrow range of functionality.
Also, I vastly prefer MicroWorlds EX to Scratch as a construction environment for kids. Scratch has a very low threshold and low ceiling, in addition to other significant deficiencies. Scratch DOES get aspects of social networking nearly perfect though. I have been meaning to write a thorough critique of Scratch for months and hope to get to it soon.
@Gary, I am so thankful that I don’t have to debug on every single task that I perform on computers. I would never get anything done. There is NO WAY that the average teacher will ever get to the point of programming and debugging code if they cannot get past mere tinkering and being unafraid to explore, test, try, revise and try again, seek all forms of help, persist… That is why any technology that requires those traits is such natural fits with kids. You have taken this conversation from a very basic level to a very high one with respects of tinkering as a form of knowledge construction. Yet, here we are with teachers who ARE at a very basic level in this respect. While wrestling with what we both believe as being this very problematic situation, we still need to meet them where they are. To hit them over the head and tell them that they should be programming when they are struggling to figure out why their PowerPoint media will not play, file will not open, or why they cannot move their clipart to where they want it on their parent newsletter is not all that helpful, I think. It is like telling someone who is trying to get their car started that they should have been an auto engineer.
Steve,
Your arguments seem based on several logical fallacies.
1) Any child or teacher should use PowerPoint, let alone “learn” it.
2) That anyone suggested debugging every single task you perform on computers. Debugging is fancy thinking or problem solving. Is thinking only possible after some sort of of prerequisite activity in the computer lab?
3) Your comments suggest that schools are designed to cater to the whims, desires or deficiencies of adults. I disagree.
4) You seem to imply that programming is hard, or harder than doing anything else with a computer. Sure, some programming environments are better suited for specific tasks than others. True, some programming environments are better designed for learning, particularly child learning. However, the degree of difficulty involved in programming increases with the sophistication of the programmer and her task.
5) Your comment suggest a commonly held belief that there is an agreed upon sequence of computing experiences kids should have. What if every child’s first school computing experience consists of programming?
6) I do not agree that the learning benefits of say, PowerPoint and designing something in MicroWorlds EX are equivalent. Not all technology contains the same “objects to think with.”
7) Nobody suggested hitting “them over the head.” Why be so defensive?
8) Surely you believe that the intellectual strategies involved in programming help develop valuable habits of mind.
9) Your PowerPoint example suggests that the teacher is on a remote island free from others, kids perhaps, who can help them find the remarkable video clip they wish to play at children.
10) You ignore the fundamental issue of agency. Who is in charge of the computer? Who is central to the learning process? The examples of ed tech justifiably lampooned recently by the Washington Post all gave agency to the teacher or the system, thereby depriving the learner.
Gary,
Good luck with #1. I am just addressing realities here.
#2 – that where you took the conversation. Not me. If you are equating “tinkering” as was originally brought up in the post with a broader “debugging”, that’s fine.
#3 – not sure how I suggested that.
#4 – again, just addressing realities of where many struggling teachers are right now.
#5 – I agree with you.
#6 – Never said they were “equivalent”.
#7 – Just an interpretation of your tone. Sorry if I was wrong there.
#8 – Yes
#9 – No. That’s my point. They are afraid to ask.
#10 – I agree.