If you're asking somebody to help you, you want to make it easy for them, not harder

re: If you're asking somebody to help you, you want to make it easy for them, not harder

Alex Cohn — Sun, 11 Nov 2012 05:14:39 GMT

I wonder, did the liason refer to Raymond's response, or to their own original question?

More often than not, e-mails chain the replies. Usually it's OK to drop this duplicate text when quoting; but here, this context is important.

Actually, the situation is somewhat similar to the original question.

re: If you're asking somebody to help you, you want to make it easy for them, not harder

Timothy Byrd — Fri, 09 Nov 2012 20:17:30 GMT

In c:\Program Files (x86)\Microsoft Visual Studio 10.0\vc\atlmfc\include\afxwinforms.inl, we had to change

extern "C" void AfxmEnsureManagedInitialization();

extern "C" void __cdecl AfxmEnsureManagedInitialization();

re: If you're asking somebody to help you, you want to make it easy for them, not harder

Gabe — Wed, 07 Nov 2012 15:56:08 GMT

Jolyon Smith: Even if you do manage to reproduce the customer's problem, you still don't know if you actually reproduced the SAME problem. Maybe you figured out how to get that error on line 42, but there's no telling how many ways to get that same error. Who's to say you did the same thing to get that error?

re: If you're asking somebody to help you, you want to make it easy for them, not harder

Neil — Wed, 07 Nov 2012 10:27:02 GMT

@pete.d Not sure whether you could class it as a typo but VC2005's intrin.h misdeclared _interlockedbittestand[re]set (the volatile keyword was accidentally omitted from the first parameter). [Fixed in VC2008.]

re: If you're asking somebody to help you, you want to make it easy for them, not harder

cheong00 — Wed, 07 Nov 2012 09:58:00 GMT

@Jonathan: Hey, you're assuming the staffs working at customer liason know the product.

While some of them do, in my experience most of them have "user" level of knowledge of the software they're supporting (i.e.: they themselve don't necessary know more than us). What they're required to do is to search in their knowledge base, hoping there is similar problem recorded there, and esculate to supervisors or even engineers if they're unable to handle the problem.

Their knowledge base don't necessary have information on which part of VS installation is NOT localized. So I'm not surprised if some of them do not know this.

re: If you're asking somebody to help you, you want to make it easy for them, not harder

Jonathan — Wed, 07 Nov 2012 08:40:23 GMT

Regarding Localization: Presumably header files are not localized. However, the customer didn't know that, so they helpfully tried to include whichever info they believe is relevant, including the fact that their version of Windows/VS/etc. is German. The support person should know whether this detail is relevant or not.

re: If you're asking somebody to help you, you want to make it easy for them, not harder

meh — Wed, 07 Nov 2012 06:11:41 GMT

Based on, "If you're asking somebody to help you, you want to make it easy for them, not harder", then I think one would have to agree that providing the header would ease the task (and probably a simple project that includes the header and build log showing the error). And that the best person to obtain this is also the person asking for help.

Anyways, I find the reaction entertaining. Sometimes one can be lazy about these things by asking (for example) someone you know is a pickle junkie to help... he'll go out of his way to get a hot dill fix. This wasn't one of those times.

re: If you're asking somebody to help you, you want to make it easy for them, not harder

Gechurch — Wed, 07 Nov 2012 02:22:11 GMT

@Joylon

"Yes. Somebody can. But since Nobody has been asked to..."

That's a classic children's game you're playing there:

Mum: "Can you wash the dishes, Billy?"

Billy: "I am capable of doing that, yes"

The difference is that the child is trying to get out of doing something. Here, the customer liason is getting assistance with an issue they're responsible for getting sorted out. It's in their interest to do what is asked. And I certainly don't buy the argument that they didn't understand that they should have done. This is a Microsoft employee. They should understand what is required to look into a problem like this, and they should also understand that the tech helping them is a valuable commodity who's time they should not be wasting.

Your speculation is exactly as it should have played out. In fact, it should never have gotten that far. If I was working triage on an issue where line 42 is causing a compiler I sure as heck know what my first question would be... "What's on line 42?".

re: If you're asking somebody to help you, you want to make it easy for them, not harder

cheong00 — Wed, 07 Nov 2012 01:54:42 GMT

On somewhat unrelated note, I remember a bug cased by Chinese character caused the source control to break... a few labelled versions contains only the label and that version of source is not retrievable. Eventally the company banned the use of Chinese in all future versions of source code (except the string resource table).

re: If you're asking somebody to help you, you want to make it easy for them, not harder

Jolyon Smith — Wed, 07 Nov 2012 00:59:37 GMT

@Raymond, yes of course that is a possibility. Identifying additional possibilities doesn't preclude the existing ones, but when helping people to help themselves by sharing all relevant information it can often help to return the favour by sharing what /you/ already think or know. That can often help the other person come to a realisation of something they had previously overlooked, all on their own.

(In which case such a post would have become one of those that ended with "We never heard back") :)

It's also important to investigate the real bug, which is why reproducible test cases should *always* come from the customer. Trying to recreate a test case in blissful isolation is a waste of time. If you succeed then you just spent time recreating what the customer already had. If you fail then it proves nothing because you cannot be sure that what you recreated is actually a perfect model of the customer's problem, so you still have to go back and ask for the test case.

In our case (middleware software), because such test cases are usually highly complex and contain a large number of variables and external systems which often aren't relevant to the bug, we further stipulate that the test case should be reduced to the simplest possible scenario that demonstrates the problem.