4:13AM. Sunrise was still hours away. My hands throttled the oversized steering wheel in front of me. My gaze was fixed out on the dark road ahead, too afraid to even blink. I was responsible for delivering sugar beets from the field to the processing plant, and this weighed on me more than the load’s collective 45,000 pounds.

When I reached the plant, I felt as if I’d rolled into the world of the Mad Max film series. Massive trucks flanked me on all sides. Extended green semis roared past, sounding sirens that chirped and warbled like you’d imagine from a UFO. The plant’s central tower belched plumes of thick white smoke into the black sky. I drove to the piler, so-named because it is where the fleet of trucks dump their beets. I eased my truck to a stop, looked ahead, and saw the lighted picture of a truck and a flashing green arrow pointing up. This meant that I was supposed to lift the back of my truck, the box, and thus dump my beets. I applied the parking brake by smashing a big button on the dash with the palm of my hand, flipped a red switch and then flicked the lever to my right, just as I had been shown.

Nothing happened.

I went through the entire process again, checking each step. The box stayed put. The sweat began to pool on my brow and I could feel my cheeks flush. I looked back and saw a line of trucks idling behind me. I scanned the dashboard of my rig, and I found a bunch of printed labels taped under switches and buttons. I recognized their names, but their functions escaped me: “PTO,” “axle,” “differential,” “engine break.” It was hopeless.

I’ll try to excuse my failure by explaining that I’d never done anything like this before. By day, I teach English literature and composition classes at the University of North Dakota in Grand Forks. My experiment moonlighting as a trucker, I would come to realize, exposed me to the technical and conceptual barriers to learning new tools, even in seasoned students like myself. In hindsight, I’ve begun to think of my experience primarily as an experiment in remembering how difficult it is to learn. During the fall semester of 2015 — the same period that saw me driving for the beet harvest — I taught a course on diversity in US literatures, focusing on the problem of socioeconomic class. I knew from the onset that I wanted my students’ projects in this class to help them think about their own lives like they do stories. To accomplish this in the ways I imagined, my students would have to confront tasks both intimidating and technical: composing and editing audio files on their personal computers. For class’s final project, I asked my students to compile an audio oral history using the open-source audio editing software program Audacity. These histories were to be comprised of a few different types of narratives: self-testimony, interviews with a parent, a student peer, and a member of the opposite sex. In these projects my students were supposed to highlight the ways socioeconomic class (defined broadly as the impact of education, family background, income, occupation, and taste) has inspired dramatic events in these people’s lives. I had never assigned an audio project in a literature class before. I hoped that the drama of my own experiences as a student of truck driving could help me figure out how to help guide these undergraduates students into accomplishing something they didn’t know they were capable of. I wanted to give my students new ways to tell their own stories.

The Anxiety of New Tools

During a daily class discussion session early in the semester, I asked my students to reflect on the economic climate of the states from which most of them hail, North Dakota and Minnesota, states that a 2013 Gallup Poll ranked as the #1 and #4 “happiest,” and with the lowest and eighth lowest unemployment rates, respectively. Before long, I turned our conversation towards the status of farmers in these agricultural states. When I asked what social class a sugar beet farmer would likely occupy, my most boisterous student, I’ll call him John, responded immediately: “upper middle, definitely.” When I pressed him on why, he provided an intriguing rationale. He explained that a farmer had offered him“$2800” to drive truck for the ten to fourteen day harvest. Anyone able to pay so much for so little work, he reasoned, must be exceedingly wealthy. In essence, I think he designated beet farmers as “upper-middle” because they don’t fit the Post-War conception of the middle-class American as an employee, not an owner, as Andrew Hoberek reminds us. This discussion with John occurred just after I had been asked to drive and from then on, I felt connected to this student. I felt like we shared the status as a farmer’s employee. John had opted not to drive, but we weren’t all that different, he and I. This identification between us helped me interpret John’s reactions to the final assignment. In essence, John’s struggles reinforced in me the need to think of education as more a matter of process than product.

Much later in the semester, just after midterm, I introduced the oral history assignment sheet and dedicated a day of class for a technology workshop. I asked my students to bring their laptops, phones, and/or tablets as well as any MP3 file with them class so that I could guide them through the basic elements of audio editing: cutting, pasting, trimming, and merging, After a short demonstration of the software, I walked around the class to survey my students’ progress. John sat there, hands still, eyes bouncing between his smartphone and his laptop.

“I’m sorry, Professor.” he said, eyes cast downward. “I don’t know how to get the song onto my laptop. Computers just hate me.” This conversations sticks with me because there I heard John admitting that his anxiety about controlling the things his laptop could do prevented him from using it for anything beyond word processing and web surfing.

As I explained to him that he could easily drag his audio file from the iTunes on his laptop onto the desktop, he pushed the laptop towards me and threw his hands up.

“Go ahead. You do it,” he said, meekly.

Eager to help, I did. And as I described the process as clearly and logically as I could, I realized that this was the exact wrong thing to do. This intervention was the equivalent of pushing me out of the driver’s seat and letting the farmer handle my problem, something that Nick and his team never did even when I was putting their crops and machinery, their livelihood, in danger. Doing my best to alleviate my mistake, I instructed John how to import the file into Audacity and walked away to help another student; I needed to give John some time to tinker. When I returned five minutes later, he had successfully opened the audio file in Audacity, but he still couldn’t figure out how to perform the basic editing techniques I had demonstrated on the projector.

John pushed the laptop towards me once again, and this time I pushed it right back. He groaned, slid his computer back in front of himself and did his best to follow my step-by-step instructions. Eventually, he managed to trim his audio file. John had overcome this first hurdle, but I knew that there would be plenty more. And what’s worse, I had no idea of knowing exactly what would trip him up next. Just as I lacked even the rudimentary toolkit for problem solving in the cabin of my truck, so did John lack the toolkit for problem solving in this digital composition task. Without troubleshooting strategies, the solution to his problem might as well have not even existed.

Another student, I’ll call her Casey, also faced an up-hill battle with this assignment. On the surface, she and John are complete opposites — she comes from Portland, Oregon, wants to be a lawyer someday, and she likes to play her guitar at open mic nights around town. When I first envisioned this assignment, I figured that Casey would be the ideal audience. Again, I had misjudged my students. I came to learn that Casey benefitted from a more structured learning environment. She immediately admitted her lack of comfort with computer software. In response, she attended my office hours. I watched as she follow my instructions step-by-step and I aided her where I could. She e-mailed me repeatedly. Throughout this process, Casey expressed exasperation, but she never appeared embarrassed in the ways John did. She always seemed confident that she would conquer this challenge. Her attitude seemed to say, “I learned to read music, I can learn this, too.” Casey’s learning strategies and goals were starkly opposed to John’s, which meant that my sense of troubleshooting the project had to expand as well.

Learning from Mistakes

Driving for the beet harvest reminded me how dramatic learning can really be. My friend Nick Hagen, a young farmer in the process of taking over and expanding his family operation, had offered me this chance to drive a truck for his farm when a driver bailed at the last minute.

To prepare me Nick gave an exhaustive training session. He rode along with me for my first few deliveries. He did everything he could make this learning experience as boring, his words, as possible.

It became painfully clear to me at that moment behind the wheel of the truck, sweating buckets into my bucket seat with what felt like a thousand disgruntled real truckers waiting for me, that I didn’t really know what I was doing. Nick’s best efforts as a teacher had failed. I had failed him. I gathered the courage and reached over from the wheel to detach the two-ray radio transmitter.

“My box won’t lift! What do I do?” I pleaded.

Nick responded by calmly telling me to repeat the process as I had before. I did so, just to make sure, but it didn’t work. The piler attendant offered to go back and check if he could raise the box manually. Still no. My short tenure as a beet trucker was quickly coming to an unceremonious end. I wondered how long it would take to climb back into the box and huck out all of the beets, fistful by fistful.

Nick’s voice came back over the radio, “Wait a second, you’re in the Freightliner, right? I forgot to tell you that you sometimes you need to give the truck some gas in order for the box to lift. It’s not like the truck we trained you on.” Sure enough, once I depressed the gas the mechanical whirr of the box lifting immediately filled the cabin of the truck followed shortly by the sweet clang of beets pouring onto the metal floor of the piler.

Radio Free Troubleshooting

I knew full well that this audio composition assignment wasn’t going to be easy for my students, but I had figured that their general comfort with digital environments and social media platforms would have already laid some of the groundwork for what I’m calling “troubleshooting.” Looking back, this was as silly as a farmer assuming that I would be able to fix problems with the truck just because I had been driving a car for fifteen years. Nick had shown me everything I needed to know to complete the basic processes of driving and dumping my beets, but, through no real fault of his own, he hadn’t prepared me for dealing with the minor differences between trucks. I took this breakdown of the system as a personal failure because I didn’t know how to experiment with methods to fix it. I was determined to not make the same mistake with my students.

I know now that demonstrating what to do was not enough to reach all of my students. Taking their laptops and doing it for them certainly was not enough, either. But for some, hands-on instruction could help. What I needed was a broader approach. Since my students lacked a radio with which to ask me dire questions as I did Nick, I offered what I think of as three provisional strategies for troubleshooting:

1. I required them to keep a process log where they could document their decisions and difficulties. I described this to them as “a rough draft” of the e-mail they could write to ask me for technical or conceptual feedback.
2. I highlighted the location of the built in manual for the Audacity software package.
3. I reminded them of resources that everyone working with digital tools often take for granted: YouTube and Google. I warned them that these were not perfect or universal solutions, but that they can often help you get out a jam, or at least find a temporary fix so that you can move on to the next step of the process. Adeline Koh conceptualizes this practice this as a hallmark of flipped classroom environments but I found this suggestion just as helpful as a guide for students completing work on their own.

I needed a variety of troubleshooting strategies to match the variety of needs of my students. John, I would later find out, had transferred to UND in order to pursue a degree in commercial aviation, which made his fear of this interface all the more interesting to me. John was clearly proficient with all kinds of tools. Indeed, I imagine that, for him, airplane dashboards and beet trucks are machines, tools squarely within his comfort zone, whereas computers and their software are something else altogether. Given my course topic on socioeconomic class, I couldn’t help think of this distinction in these terms: trucks for blue-collar work, computers for white. In this, I saw an opportunity to encourage John to adapt his comfort with one set of tools as a larger approach to learning.

Unlike some of his more tech-savvy peers, John never ended up e-mailing me for help. He did ask some follow up questions during another technology workshop class during the final week of the semester and he briefly attended my office hours. But he never reached during using his log during his composing or editing. Once I listened to his final project, though, I happily discovered that he had made it work. Much of his editing was still choppy and the volume was uneven and non-normalized, but John had successfully told his story. After consulting his final log, I realized that the reason he hadn’t contacted me was because he had turned to a YouTube channel with Audacity tutorials instead. While this was the strategy I least preferred, his choice offered evidence that I had successfully offered him ways to troubleshoot this software, even if I had not wholly succeeded in teaching him to use it. To that end, I now speculate that he chose this option because it saved him what he described in office hours as “looking dumb” in front of his teacher.

In the end, Casey also succeeded. Not only did she tell a moving story about her “hippie” parents’ conflicted feelings over her attending college, but she used Audacity to record an acoustic song she wrote for guitar to serve as background music. What I learned later through her process log was that the basics were what had held her up the most. And by basics I mean installing the software, installing the LAME encoding library so that she could export her files in Mp3 format. After I had walked her through that during office hours, Casey was able to figure out the rest on her own. After I helped her get past the initial hiccups, Casey gained a sustainable outlet for producing and sharing her creative output. This particular success thrilled me because I realize now that those basic barrier too often quash projects before they start. But they wouldn’t hold Casey back any longer.

My experiences with John and Casey reinforce for me that there are many different kinds of obstacles that students face when they approach an assignment, any assignment. With such a range of obstacles, educators cannot be afraid to offer a wide a range of strategies for coping with this diversity as best we can. The fear of failure, the worry of “breaking something” too often prevents our students, and, ourselves as scholars/teachers, from putting ourselves in the position learn something completely new. Sean Michael Morris’s eloquent defense of taking risks speaks directly to promise of autonomy in digital writing practice and pedagogy. But we cannot overlook how multiple forms of anxiety stands in the way of risk tasking, especially for students who take pride in their ability to perform all kinds of other highly complicated and creative feats.

A New Kind of Proficiency

The most valuable thing I got out of truck driving was the proof that I could accomplish something which I had never imagined myself able. I have always been good at learning things within the safe confines of a classroom, but by testing myself with a frightening and foreign task, I proved to myself that I could adapt those learning strategies to the real world, too. And, more importantly, I realized that I could spin off those strategies to better reach my students — those who prefer to learn within a structured environment, and those who do not.

I’m optimistic that John got more than just rudimentary audio editing experience from the process of completing my assignment. By developing his own pragmatic strategy for working through technical computer problems rather than avoiding them. Once he could overcome a new set of technical difficulties and, perhaps more importantly, his anxiety over not being able to immediately fix these problems, he could finally get to the good part: the story that he wanted to tell.

Freely available open-source digital software tools make students voices easier to record, edit, and share than ever before, but even students like Casey still need a reason to take the risk and some help to get past the initial obstacles to sharing their work.

By putting myself in a risky new situation behind the wheel of a beet truck, I realized how strategies for troubleshooting are necessary supplements to even the most comprehensive step-by-step instructions. Delivering a product, in the form of beets, was the operative goal for my farmer employers. But teachers aren’t employers. My students’ final projects served as proof of the process that brought these products into being. At its best, education provides techniques for solving different kinds of problems, not a linear pathway towards accomplishing goals. I hope that their success in these situations likewise puts them in position to take more risks in their careers as students and beyond. I will never be there waiting by the radio again, but it seems as if they won’t need to be.