Sometimes when you’re debugging, you haven’t the foggiest idea how someone managed to screw something up so badly that they got this particular error. Naturally they’ll tell you that they didn’t do or change anything, and sometimes they’ll even be telling you the truth! It’s at that point I try to teach my guys that it’s okay to wander off the script and start talking about anything else, in order to learn how the person thinks.
Everyone’s thought process is different. Some of us learn by reading, some by watching, some by doing, and others by listening. There’s no one perfect way to solve a problem, but that doesn’t stop managers from trying to codify the how-tos into a script to follow. We’ve all been there, where we’re told to reboot our PC to solve a modem problem. There is no secret shibboleet call to get you to the smarter people.
I will say that the reason the scripts exist is because they do work. I couldn’t begin to tell you how many help tickets are solved when I ask ‘Are you using the default password of changeme?’ Heck, even telling people ‘Reboot.’ is correct sometimes. That’s the thing, though. SOMETIMES. You have to learn how to tell when ‘sometimes’ is now and when it’s not. For example. I add a user to a domain group on Windows. Our setup of Windows XP systems pull down domain group info (and all permissions allocated therein) on login. User says the permissions that come with the group aren’t working. I tell them ‘Reboot so XP can apply the settings. Sometimes it gets persnickety.’ They reboot, we’re done. But notice, I know how and why the problem occurred, and I can explain it to the user.
But. Sometimes you get yourself down the rabbit hole with a crazy problem. “Hi! Every time I add a file, it locks the system.” Okay, time to sort out what’s getting locked. What’s not cleaning itself out, what’s acting ‘weird.’ Does it work for you? It does. Interesting. What’s HE doing? Let’s ask. “I’m using a home grown script to add files.” Oh. Betcha that’s it. I actually spent three days and a call to the vendor trying to debug a problem like this because the guy refused to accept that HIS script was POSSIBLY screwing things up. Actually he didn’t even mention the script until I started chatting about workflows and productivity and he mentioned, in passing ‘Yeah, we had to write a script because it took too long.’
This isn’t about how when you ask for help, be specific and tell them exactly what you’re doing in as clear and simple a way as possible. This is about how, when you’re talking to someone, it’s totally okay to wander off topic and ask something off the wall. “Are you using Firefox beta 4? You are? Did you know that there are problems with that and TinyMCE?” Sure the question sounded hella random, but it was the debugger’s brain pinging off the wall at a memory.
When you’re helping people, remember that they learn differently from you as well. As much as people tout ‘thinking outside the box’ as a call to innovation, I think that’s not what they mean. What they mean is being willing to take a chance, a risk, and make a stab in the dark at a possible answer. A genius is the one who looks at a moldy cheese sandwich and thinks ‘What the hell is IN that green stuff?’ A genius is the one who says ‘It’d be easier if could clone a server.’ A genius is the one who both thinks and applies the thought to something.
When you’re stuck troubleshooting, wander off topic. Be willing to think of the crazy things and voice them aloud. Be willing to say ‘I doubt this has anything to do with it, but what happens if you do this…’ Be willing to ask the ‘stupid’ questions. Go ahead and talk about Bad Wiener day. The scrunchy joke may make you remember something totally off the wall.
How low is too low?