I always get a kick out of reading Raymond Chen's blog, The Old New Thing. So many of his posts hit home way too often :). One of his latest posts simply highlights one thing I always try to do and get folks to do when they ask for support or help with such-and-such. I've caught myself doing this same thing many times. Don't ask how to implement your grandiose solution, simple present the problem you're trying to solve and then present your proposed solution.
Why present the problem? You've already thought about it (I presume) up one side and down the other. I should not have to bother this person with my problems; they're mine to solve, dag-nabit! First of all, why are you even asking for help? If you're suppose to be "God's gift to programming," why are you seeking advice? Your not? You're a fallible, imperfect human? Me, too! Good, now that we're all on the same level here, back to why should you present the problem? When you present and frame the question in terms of the problem you're attempting to solve, you have the highest chance of getting the information you want. In fact, in cases too numerous to count, I've gotten better solutions to my original problem than my own "awe-inspiring" solution.
I see this same thing all too often in the peer-support forums and newsgroups. A person will pop in and asking for help with how to implement their solution, only to be disappointed by the responses due to a lack of common information. Too much inference is going on. The same is also true of QualityCentral reports. Rather than simply stating that such-and-such is broken, a detailed explanation along with detailed steps go a long way to getting your point across. My parents always used to tell me, "To be terrific, you must be specific."
This time Raymond missed a crucial aspect of the issue though: The problem of an adviser being so certain of their superiority over the user that they don't think to consider the possibility that the advice they have given might not be as clear as they think it is.
ReplyDeleteIn this case the advice contained, and repeated, instructions to do something that the advisor themselves did not mean and would not have meant and which seemingly quite clearly was confusing the issue.
This was then compounded by a good analogy with a simple vocabulary error that also could have potentially confused things.
The issue Raymond was highlighting is perfectly valid and good advice:
Ask WHY a user wants to do something, as it will often reveal that WHAT they want to do is not what they are asking for, or at least not the BEST way to do it.
However, the example he gave is actually a better example of:
When explaining an answer, first be sure that you express the explanation both correctly and in terms that make sense to the person receiving your explanation.
If you give advice that sounds perfect in your head, but which causes unexpected confusion in the other party, consider that you might have made a simple error in your advice, rather than assuming that they just don't get it.
If you simply repeat the samed flawed advice, don't be surprised if the user STILL "doesn't get it" - this might be an even stronger indication that you aren't giving the advice you think you are - if it's "so easy/obvious/straightforward", why is it so hard to understand?
"You're a fallible imperfect human? __Me__too__"
[sic]
The users are much better than we expect in feeling their problems.
ReplyDeleteThe users are close to our expectations in reacting when a problem arises.
The users are much worse that our expectations in giving their solutions.
The exception which confirms the rule is that there are users with absolutely stellar solutions.
IOW, never, ever, trust the users in their solutions. Always obey in their needs. Don’t argue. It’s useless.
2c from someone bitten