In high school, I took a class called “Computer Troubleshooting.” This may sound like a weird class for a 16-year-old to take or a high school to offer, but in practice it was savvy: the school netted a built-in, small workforce for IT support and repairs. Nothing like a little free labor to make things go.

Going in, I didn’t think I’d learn anything and when I finished I felt the same way. After all, I’d grown up around computers and was already the de facto family IT person.

Over a decade later, working as a software engineer, I realized that I’d learned something very important. The course started with the group tackling problems together. Our teacher would approach the problem and guide one of us through it, asking questions.

“Is it plugged in?” “Is the power light on?” “Zap the PRAM,” etc.

After a few weeks, we were fixing problems on our own. My first case put me in an office with a frustrated administrator three times my age. I couldn’t figure out why the printer wouldn’t work. I ran through everything I could think of before heading by to my teacher and asking for help.

By now the problem is probably obvious to you, but to me it was anything but that. The printer was not plugged into the computer.

Thus, my teacher’s mantra became “always check to be sure it’s plugged in”.

Today I would add to that “…especially if you know its plugged in.”

This is the lesson I learned. Unlike technology failures, when people fail we are blind to it and don’t easily self-correct. Instead, we need to learn to step back, question our assumptions and be willing to re-check everything.

This article was also posted on Medium.