Don’t be helpless: You can find information too, if you try (episode 3)

Sometimes the information you receive regarding the location of a document or other resource is not perfectly correct.

I put the script on \\scratch\temp\bob\widgetstuff\enable­widgets.cmd.

But then you look, and oh no it's not there!

Don't give up yet.

Look around you.

Maybe the script is in a nearby directory. Maybe Bob misspelled the path or file name.

Got it, thanks. It was actually in a scripts subdirectory, but I was extra smart and figured that out for myself! I deserve a cookie.

I have been known to give information that is intentionally ever-so-slightly incorrect in an obvious way (like misspelling a function name or providing the wrong number of parameters), so that the person receiving the information will be forced to look around.

Comments (29)
  1. Kirby FC says:

    “I have been known to give information that is intentionally ever-so-slightly incorrect”

    Some people call that “being a jerk”.

    1. Wear says:

      Give a person some information and you help them for a day, teach a person to find information and you help them for life.

      Until they complain that the information you gave them is incorrect and just wait for you to fix it for them.

      1. or find another expert, which in some cases, is an equally acceptable outcome.

        1. cheong00 says:

          Just that “the other expert” may not come. :P

          It’s known that in MSDN forums, for most of the time, when a simple question is asked and a known helper is answering that, the other helpers will just skip that question in order to save some time seeing if there are other people need help.

    2. Ken in NH says:

      Depends on the circumstances and Raymond did not provide context. If said recipient is a repeat offender, then this is the nicer way of telling them to start thinking for themselves.

    3. It’s obviously wrong (i.e., doesn’t even compile), like a function name is misspelled or the parameters are in the wrong order, or there are too many/too few parameters. It’s not like I told them to pass 2 when they should be passing 3.

    4. parkrrrr says:

      If you didn’t know it was intentional, you’d just assume it was an accident, like we all make. It’s devious, but I’m not sure it’s up to “social skills of a thermonuclear device” level.

      1. Kevin says:

        I thought our standard for “social skills of a thermonuclear device” was “knitting during a meeting.” This is definitely not at that level.

  2. Dave says:

    this is why I always follow my own link before sending an email that has one, to ensure that it does actually link to what I intended

  3. Ray Koopa says:

    Giving out slightly incorrect information as a newcomer in a company gets you some bad reputation though… ;)

  4. IS Support says:

    Impressed that Raymond has referenced a niche UK series like the mock BBC Schools science programme Look Around You!

    1. Arezz says:

      It’s really not that niche in the internet, it’s grown into a meme many years ago. :)

  5. morlamweb says:

    It’s for this very reason that, when I give out standard file paths to customers in response to support tickets, I use “Drive:\Program Files (x86)\Blah…” instead of specifying a drive letter. The path is correct in most cases from “Program Files (x86)” on (since the software that I support is all 32-bit and my customers usually have 64-bit Windows) but the use of “Drive:” makes it invalid syntax, and forces my correspondent(s) to adjust the path to their local conditions. Even if it’s a 32-bit OS (and thus, in “Program Files”), the use of “drive:” requires the customer to evaluate the whole path in the context of their machine. It’s much more compact and efficient than what I used to write: “Look for the file C:\Program Files\Blah (by default, could be on a different drive, or in a different path if on 64-bit)…”.

    1. Mike F says:

      You could use an environment variable for that.

      1. morlamweb says:

        @Mike F: that variable doesn’t exist on 32-bit Windows.

    2. Tanveer Badar says:

      That wouldn’t hold true for PowerShell I assume where you can actually have a drive named “Drive”.

      1. morlamweb says:

        @Tanveer Badar: the one customer that I know of who regularly uses Powershell for admin tasks doesn’t use it to browse to a drive path. From what I’ve seen, and I have had remote sessions with users where they copy the path straight from my email, they paste it into the Run prompt, not into Powershell.

  6. PatH says:

    Considering that most people don’t even read and/or understand typed instructions and just go into ‘help me more” mode I’m not certain it makes a difference one way or the other. You might as well instruct “Look in c:\blah\blah\” directory.

    And let’s not forget those circumstances when you first need to explain that the folder may be hidden and needs to be unhidden in Windows Explorer along with screen shot instructions on how to unhide.

    Then explain in a later email that you were talking about Windows Explorer, not Internet Explorer.

    I could go on.

    1. PatH says:

      Or just “I like toast”

    2. morlamweb says:

      @PatH: in my experience, my customers do read instructions, but they tend to follow those instructions to the letter, including looking for files/folders in the wrong places. The “Drive:\path\blah…” trick is a subtle way to break that pattern and force them to evaluate the path. It’s not quite the same as providing purposefully incomplete info – more like providing info with a placeholder – but the effect is the same: to get the recipient to think about what they’re doing. I can’t promise that it’ll work every time, but it certainly has worked out for me.

      1. PatH says:

        @morlamweb – I’ll give it a try. I was mostly being sarcastic.

  7. Boris says:

    Aha, but what if the file in the scripts subdirectory is merely the old version, while the one in widgetstuff was supposed to be the RC you were to evaluate, except that it was actually saved to Bob’s Documents folder because he didn’t look where he was saving it? I definitely prefer to research stuff by myself, eg. by searching another team’s files or source code, but the tradeoff is that the truth is sometimes subtle and the wrong conclusion possible. However, I’d always give people points for trying.

    1. Kevin says:

      Well, then you just prefix your reply to Bob with “(Assuming you meant \\scratch\temp\bob\widgetstuff\scripts\enablewidgets.cmd)” or words to that effect. That way, if your assumption is wrong, he can correct it, and if it’s right, you can both move on with a minimum of fuss.

  8. Ian Yates says:

    Giving slightly wrong info is also a good way of knowing if someone actually bothers to look at some source document now for a deadline of two weeks from now (for a task that should take 2 weeks). If they come to you the day before the deadline and ask about that file they can’t find then you can at least lower your expectations :)

  9. OT: the “Archives” link in the right-hand column (under Basics) is redirecting to an article from 2012.

  10. Jan Ringoš says:

    I used to have a blogpost up advocating using OpenInputDesktop rather than SwitchDesktop to check if user’s console is locked (because a lot of apps broke Mark Russinovich’s Desktops this way). The example of right code was small and nice. The example of the wrong code had big red labels “wrong, don’t use” all around and hidden syntactic errors just in case. Every two months or so an enthusiastic bug report came from someone trying hard to use the wrong code.

  11. McBucket says:

    I try to follow the old programmer dictum (er, it’s an old dictum, not a dictum for old programmers :)): Be liberal in what you accept; be conservative in what you send. In other words, if someone sends me instructions, I’ll try them literally first, but look around if something doesn’t work, but on the other hand, try to be as precise as possible in the instructions that I send to others.

  12. rich says:

    “I have been known to give information that is intentionally ever-so-slightly incorrect”
    Ha! MSDN is written on the same principle!

Comments are closed.

Skip to main content