General discussion


How do you document hunches?

By TonytheTiger ·
I'm getting close to retirement (576 calendar days, but who's counting). My supervisor wants me to document everything I do including how I know what to try when troubleshooting a problem. I've been struggling with this for a few weeks, especially the bold part.

For example, after the latest batch of Windows updates, a user had one particular program (TopoQuad) quit working. My boss messed with it all morning, then asked me to look at it right after lunch. I had a hunch to try running it in "Windows 95 compatibility mode", and that fixed it. My boss asked me "How did you know to do that?". I don't know what to tell him... I don't KNOW how I knew.

I know he's trying to "flip chart" the whole operation, but there are just so many variables that "if, then, else" isn't going to be practical. I know I shouldn't care... but I do...

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

From experince

by jdclyde In reply to How do you document hunch ...

you know from experience what the best guess solutions are, and the order to try them in.

Ask him how he knows when he has to pass gas, liquid, or solid, and how he knows the difference. B-) He learned from experience, I hope.... ;\

Tell him you can't document decades of experience that got you to where you are now, but you will document what you are able to.

Collapse -

I like it, but...

by TonytheTiger In reply to From experince

Ask him how he knows when he has to pass gas, liquid, or solid, and how he knows the difference.

.. this guy has slightly more sense of humor than the funeral director! Shortly after he started working here, he was showing pictures of his new baby and I said "Awww Isn't she cute... Kinda looks like me!" and if his eyes had been phaser banks, there's have been a big hole where my chair used to be. I'm glad I never asked him if he had any naked pictures of his wife (You wanna BUY some?) :)

Collapse -

Maybe you should try documenting

by Dumphrey In reply to I like it, but...

how you think about solving problems more then how to solve them.
Does that make sense?
JD is right in that experience is key, and it can't be documented, but the basic steps you use to solve problems are probably the same as always, just much faster then when you started :0
What, how, scope, relation to other systems, changes... that sort of stuff.

Collapse -

That would not tell you how

by jdclyde In reply to Maybe you should try docu ...

to even THINK of compatibility mode. How many times have you ever had to use it?

Other than to keep D2 from crashing on my home system, I have never needed it, and certainly never at work.

Collapse -

Very true

by Dumphrey In reply to That would not tell you h ...

but like you said, you cant teach experience, the next best thing is to gove someone good tools to help develope their own experience.

Collapse -

Some take training classes

by jdclyde In reply to Very true

to off-set their lack of experience.

There are no short-cuts though, that a few notes from a departing tech could make in incompetent tech into a competent tech, even if he is the boss......

Collapse -

At your discretion

by jdclyde In reply to I like it, but...

on if you wish to use my example or not.

Just leave that part out.

I remember years ago, a guy I worked with lived just up the road. I commented as his girl was turning 5 and mine were 7 how it wouldn't be long before my boys were coming up the road and asking her out. I probably COULD have left off "and they are brothers, they do share everything......" :0

Collapse -

Focus on how things work.

by BizMan In reply to How do you document hunch ...

I've been involved in IT for many years. Taught adult evening courses at community colleges for about 10 years, and questions would always come up on the most bizarre "what if" scenarios.

I would simply state that I was there to focus on how things work, and to get them to understand what "normal" looks like. We could spend years talking about all the possible ways things could go wrong, but I was there to focus on the logic and reasoning behind how things work in a "normal" environment, by creating scenarios, and explaining the reasons for doing things in various scenarios.

If you document everything, and explain your logic behind it, give some reasons to your choices, why your network tree looks the way it does, how the naming convention works, how and why you choose the IP addressing schema that you did, the problems will much easier to troubleshoot.

Your right, you can't teach troubleshooting in a simple document, and a simple flow chart will not always work. But you can supply enough information to help someone with basic skills diagnose a problem.

Collapse -

Piquant, Tony

by santeewelding In reply to How do you document hunch ...

In spite of your effort to so closely identify your concern with specifics, you ask a question that goes quite beyond those specifics.

Probably what makes you interesting.

Collapse -

Huh ?

by Tony Hopkinson In reply to How do you document hunch ...

How you know what to try?

Now there's a guy who knows nothing about how to troubleshoot.

Basic Troubleshooting start at one end, check for problems at each step.

Advanced troubleshooting, binary search pattern.

Intuitive troubleshooting, use intuition....

There are some things you can document about the process, for instance assume nothing , and you can apply them to problems.

The idea that tick compatibility mode is somehow part of the process instead of the result of it is missing the entire point.

That is only useful, in terms of documenting a resolution to a specific fault.

Related Discussions

Related Forums