The art of describing a problem

Now that I’ve been answering AskTom questions for a while, there is obviously a huge amount of variety in the topics and the problems that people are encountering.  And it always feels good when I can help those people.  Chris and I don’t always manage to solve everyone’s problem (sometimes we just have to say “Get in touch with Support”) but I think we’ve got a pretty good hit ratio   [For those unaware, we don’t publish every single question/answer – we answer a lot more than what you just see on the page]

But there is one common theme that has come through in the past few months, that I think we as developers could all improve upon, and that is our ability to describe a problem.  What I tend to see all too frequently on AskTom is what call an “excessive closeness” to the problem, which clouds the ability to define it.  The question comes in without setting the scene, or explaining the requirement – it becomes a description more of the precise road block that has led to the poster coming to AskTom.

Don’t get me wrong – that’s totally understandable, but if you are trapped in a maze then describing the brickwork of the dead end in front of you won’t assist you finding an alternate path, and more importantly, wont help anyone trying to assist you.  Many times on AskTom I find myself responding with “What is it you are actually trying to achieve?” and then a “Explain it to me as if I have never ever seen your application, your database or your requirements… because I haven’t”

And here’s the interesting bit.  When asked to do so – the majority of our respondents are well skilled at doing do.  They step back, (then perhaps metaphorically) pause for breath, and their next round of input is far more articulate – we get the background, the options considered, and the current issue.  We get the thought that led to the current status.  And more often than not, we then get a test case as well, because of the realization that in order to describe the issue, they needed to manufacture some data to elucidate the various boundary cases.  And occasionally, we dont even get a chance to then solve the problem, because the poster will suffix the information with: “Oh…I think I’ve worked it out by myself” or similar, because the process of defining and describing an issue often presents a solution.

So when you’re asking a question on AskTom, pause for a moment and work on that all important skill of defining and describing a problem.  Chances are you might not even end up pressing the “Submit” button, but you’ll get clarity for the solution just by performing that process.  And of course, if you press Submit, then we’ll be that much more capable of lending some assistance.