Troubleshooting Moving Parts

From age 13 I was troubleshooting computers. Learning a language or thinking about computers as a science was the furthest thing from my mind. I just wanted to make games work. I wasn’t trying to create games, I just needed to fix little problems and I happened to learn a lot along the way. Far too often, with early versions of Windows, graphics or sound would stop working. It was always at the least opportune time, Friday afternoon with a new computer game and a full weekend ahead. I was never a fan of instructions, so my first instinct was to open the computer case and search out the problem with my own eyes. If I didn’t know what to look for, I just looked for something out of place. I didn’t realize it at the time, but I was conditioning myself to troubleshoot logically and begin with the physical components of the system. Things that move are often to blame. Even the slightest change can mean the difference between on or off. 
 
Picture of a Windows BSOD Blue Screen of DeathLooking back I probably spent more of my free time as a teenager tinkering with hardware than actually playing games. My motivation was to play, yet my unknown reward was the experience of self education. There was no guideline to follow, just a series of unexpected obstacles that I was genuinely interested in overcoming. After a few years of hands on computer troubleshooting, I was already beyond the high school course material available to me. I thought of computers as something I could just do. I didn’t have to think much about how, so I challenged myself with finding multiple ways to solve the same problem. 
 
The last two years of highschool I was an office assistant in two different jobs. I worked for a dance studio, which taught me little to nothing new about computers. I also worked in a university Botany Building. The first day of work, I didn’t know what botany was. Luckily, I was sitting in the office of a botany professor. He had many books, so when he stepped out, I borrowed one and quickly referenced the definition of botany. I like to think this was the first time the professor’s book was ever used for this simple purpose. 
 
Somehow the question of what the job is never came up in the interview. I later learned that the professor knew as much about computers as I knew about botany. There was a divide between our experiences and neither one of us chose to discuss a topic at length that we knew little about. My logical troubleshooting helped me reveal just enough understanding about botany to do my job. 
 
I enjoyed the puzzle that was my uncertain work environment. Working on computer hardware is boring. For motivation, I needed an outside purpose for why I was working on the computer. For me, that motivation was the challenge of overcoming uncertainty. I wanted to understand the core need of the request. What was the computer being used for? Was there a way for me to improve upon the request? Every day I would arrive at work with less knowledge than I needed to finish my job. By days end I would have a completed project and understand even more about computers. 
 
There was rarely just one answer, there were variations of quality based on the intended purpose. That job taught me the importance of defining purpose and understanding intent. Without knowing why something was needed, I was unable to offer the best solution. I could blindly follow directions and deliver exactly what was asked for, but often the request fell short of the intended use. I learned that people often assume others think just like they do, and what they really want should be obvious. 
 
Allowing myself to openly work outside my comfort zone is what allowed me to extend my reach. I didn’t always have a best solution, but I developed a heightened sense of what the average solution was and improved upon it. There’s a common expression of putting yourself in someone else’s shoes to know how they feel. That way of thinking works for empathy, emotion and situational compassion.
 
To understand the motion of another’s experience, look at the path they took, where they started and where they are going. You need to start at the moving parts. I unknowingly taught myself this as a teenager and it still holds true today.
 

Confirm core certainty or revolve around assumption.

 

   

Add new comment