In the job interview, they asked if I knew Linux. Sure. I’d played around with it a little. I used it as the operating system for a “server” that I set up in my classroom. I was running a MUD for my students. It worked, too. But it was tough to get eighth graders interested in text-based adventure games, even in the 90s. So I had played around with Linux a little. At least I knew what it was, which was more than they could say for the other candidates.

I quickly learned, after taking the job, that the school had just purchased a new Linux server. It was going to handle logins and shared storage space for the school, as well as serving as the district’s web server. I was in charge of it. A consulting company had been brought in to set it up, and they were finishing up their work just as I was arriving. They handed me the metaphorical keys, and suddenly, I was a server administrator.

That worked great, until it didn’t. I would get a phone call or a line of people at the door telling me that they couldn’t log in, or their network drives were gone, or the web site was down. They would remind me that this is a really bad time for the tech to not work, and how busy they are right now, and how much time they had put into those documents that they couldn’t access. Then, they’d hover around the doorway and wait for me to fix it.

But I didn’t know how to fix it. I didn’t even really know what was wrong. There were no manuals. There was no support agreement. There was no budget. It was me and Alta Vista against the world. I had to figure it out.

I had all the ingredients for effective problem solving. I had a real-world problem (the server’s broken and nobody can do their work). I had motivation to solve the problem (it’s your job, and these people are going to stand in the hallway outside your door until you do it). I had constraints (there’s no one to call; you’re on your own). And I had some resources (the Internet is at your fingertips, as long as you don’t break that, too).

So I learned to be a problem solver. I used what I knew to find out more until I reached the cause of the problem. I observed symptoms. I did some searching. I learned about log files. I read those, and didn’t understand them. So I did some more searching. That explained what the logs meant. Eventually, the trail led to the cause of the problem. The disk is full. There’s a memory problem. A file is corrupted. There’s an incompatibility between two different applications. That configuration option doesn’t do what you think it does. Once I knew what the problem was, I could find a way to either solve it or work around it.

I got into the weeds a lot. I learned a lot about how Linux servers work. I learned about networking and protocols and databases. I picked up some new programming and scripting languages. I figured out how to more quickly diagnose common problems, and even how to prevent them.

Along the way, I learned some ugly truths about technology, too. A lot of the time, software doesn’t work the way it’s supposed to. Updates can help fix security problems, but they usually break things, too. Simple solutions are more reliable than complex ones. Things are often designed to work well in a home, where you have half a dozen devices, but fall apart in a school with thousands of networked computers, phones, and tablets. And whenever two systems need to work together, they will inevitably blame each other when things go wrong.

But mostly, I learned that none of this is insurmountable. There are no great mysteries. Observe. Hypothesize. Test. Revise. Iterate. That’s how you solve problems. And if you can do it in an environment with just enough pressure to motivate you, there are no problems you cannot overcome.