General discussion

  • Creator
    Topic
  • #2163190

    How do you document hunches?

    Locked

    by tonythetiger ·

    I’m getting close to retirement (576 calendar days, but who’s counting). My supervisor wants me to document everything I do [b]including how I know what to try when troubleshooting a problem.[/b] 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…

All Comments

  • Author
    Replies
    • #2787493

      From experince

      by jdclyde ·

      In reply to How do you document hunches?

      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.

      • #2787478

        I like it, but…

        by tonythetiger ·

        In reply to From experince

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

        .. 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?) 🙂

        • #2787474

          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.

        • #2787471

          That would not tell you how

          by jdclyde ·

          In reply to Maybe you should try documenting

          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.

        • #2784919

          Very true

          by dumphrey ·

          In reply to That would not tell you how

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

        • #2784726

          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……

        • #2787473

          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 😀

    • #2787462

      Focus on how things work.

      by bizman ·

      In reply to How do you document hunches?

      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.

    • #2787459

      Piquant, Tony

      by santeewelding ·

      In reply to How do you document hunches?

      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.

    • #2787451

      Huh ?

      by tony hopkinson ·

      In reply to How do you document hunches?

      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.

      • #2785032

        or deductive

        by tonythetiger ·

        In reply to Huh ?

        [i]Intuitive troubleshooting, use intuition….[/i]

        After awhile, you get to know certain users’ habits. We had another problem on two computers. Every time the user logged in, they’d get an error message “not found on drive”. I knew both of these users used cameras on occasion, so I figured they opened a file on the camera drive (instead of copying it off first). I emptied both of their “recent documents” folders. I might not have thought of that first had there been only one.

        My biggest problem though, has always been the “How do you know?” one. I can’t count the number of times I’ve wasted time trying to do things I knew wouldn’t work, because my boss didn’t believe me when I told him they wouldn’t work. I won’t miss it.

        • #2784752

          You don’t

          by tony hopkinson ·

          In reply to or deductive

          Sometimes if you care to put the effort in, you can deduce your way to the same conclusion, but defining intuition as subconscious deduction is always an assumption.
          When you get a feel for things, your hunches will often play out pretty well. The idea that you can document a lrage amount of experience so some one completely new to it, can come along and use it, is well, moronic.

    • #2785054

      Library of documentation.

      by mjd420nova ·

      In reply to How do you document hunches?

      Our service dispatching system does all this tracking for me. I usually write in the diagnosis field my observations and then use a resolution field for parts used in the order used and it can then pick out trends and make a flow chart. Too many things to observe that are not obvious and can’t really be charted except by the first item to be tried and fail. A flip chart is for those who want to learn by repetition and not by the true observation and resulting nonresolution checks. Race car drivers call it “seat of the pants” when it becomes the feel and not the observation that guides intuition or that semi-concious reflex. I guess you can do as he asks and maybe do yourself out of a job. Depending who you work for, this could become the next big dummies guide or something and you’d make a billion dollars publishing it, otherwise the boss may say it belongs to him as he asked you to do this and you use company time to do this. Eitherway it can be worked to your advantage. Be sure that when he lays you off that he agrees to paying double price to come fix something that he can’t. Soon the boss’s head will spin around and he’ll want you back. Anyone can be instructed to start here and replace these items in this order unitl you fix it. Then you have to worry about Murphys Law and you have one bad replacement part that throws him off into left field. The head won’t spin but the top will blow off.

      • #2785035

        The funny thing is

        by tonythetiger ·

        In reply to Library of documentation.

        [i]I guess you can do as he asks and maybe do yourself out of a job[/i]

        I stated that as one of my goals several years ago (although literally I said “to not have to do anything”). When ridiculed about that, I hastily added “in the firefighter sense”.

    • #2784983

      Document in secret

      by drowningnotwaving ·

      In reply to How do you document hunches?

      … and then come back post-retirement at $225 an hour to “consult”.

      Good luck ! 🙂

    • #2784973

      the real problem

      by jaqui ·

      In reply to How do you document hunches?

      is most likely that your supervisor is not a “problem solver” in the IT sense, he ( or she ) would never be able to follow any documentation on skills honed over the course of your career.

      newer staff, same problem, they don’t have the experience to do what you do the way you do it.

      with me having spent 20 years cooking for a living, I can do things in the kitchen that only others with the same amount of experience could duplicate. It’s not a “training” or “documenting” type of thing, it is straight experience.

      What you do in resolving issues is literally a learned reflex, it feels and looks like instinct and intuition, but is based on extensive knowledge.

    • #2784845

      Documenting hunches

      by bizzo ·

      In reply to How do you document hunches?

      I believe this guy did very well documenting them:

      http://books.google.co.uk/books?id=PWQRAAAAYAAJ&printsec=titlepage

    • #2784837

      Wow good luck!

      by tink! ·

      In reply to How do you document hunches?

      Having to sit down and document your experience from all your previous years is an insurmountable task.

      Something like that needs to be documented along the way, as the events happened.

      All you can do is pick the most common errors and document the steps you would normally do based on if it was a user you didn’t already know.

    • #2784824

      But to his question….

      by cupcake ·

      In reply to How do you document hunches?

      But how do you convey that you really cannot document
      “experience” to the “boss”?

      I had the same situation a few years back. Was brought in
      to help transfer a MainFrame based app onto a LAN Mac
      based computing system. Worked with engineering to
      rewrite the software, set up networks, hardware,
      subservient software, backup systems and did training for
      the users. This of course, was from years and years of
      experience and training and being a Mac user myself.

      Of course, then the “boss” came in and told me that I
      needed to ‘train’ the FTE who essentially take over when I
      left in support and maintenance mode. (Hoping that I
      would get it, but that’s another story).

      This guy hadn’t even touched a Mac and had a personal
      dislike for the system… let alone didn’t have a clue what
      the software and the users did.

      So after trying to explain this to the “boss”, he casually
      offered me the “just write it all down then’!

      I never could make him understand that I couldn’t
      document everything it would take, so I provided a
      cursory document that included a ‘Mac for dummies’ list
      of books and web site references.

      How do you get through that 95% of what I know I
      brought with me… the 5% I learned over a period of 18
      months doing the project!

      • #2784725

        Get real

        by jdclyde ·

        In reply to But to his question….

        all you do is push a bunch of buttons all day, how hard could that be? ;\

    • #2784722

      Start, as of today

      by jdclyde ·

      In reply to How do you document hunches?

      Keep track of all problems that users have, and the solution to resolving that problem.

      A years worth of trouble shooting the actual system will cover the majority of issues likely to be encountered after you leave.

Viewing 10 reply threads