My coding odyssey continues and as a result I stumbled across the how to ask a good question page on Stack Overflow. It’s a site for people to ask questions of a large community of coders (I shan’t share what led me to browse the help centre of a help centre 😇).
While much of the page is understandably specific to questions about coding, reading it gave me several thoughts for some universal guidance for good questions.
•Pretend you’re talking to a busy colleague and have to sum up your entire question in one sentence: what details can you include that will help someone identify and solve your problem? Include any error messages, key APIs, or unusual circumstances that make your question different from similar questions already on the site…
• If you’re having trouble summarizing the problem, write the title last – sometimes writing the rest of the question first can make it easier to describe the problem.
So often people come with a simple question or problem that they have buried in so much story/minutiae as to make it boring/unintelligible. But if you really want to find an answer, and quickly, it’s probably best to approach it like click bait.
What are the details that will hook me into your question? Can you summarise as to confirm I even know the answer?
The busy colleague is a good device. When I first started as a journalist my producer told me something similar – I should pitch ideas to him as if he was a stranger in a pub who would leave or find me boring if given a long preamble.
Then:
In the body of your question, start by expanding on the summary you put in the title. Explain how you encountered the problem you’re trying to solve, and any difficulties that have prevented you from solving it yourself. The first paragraph in your question is the second thing most readers will see, so make it as engaging and informative as possible.
Help others reproduce the problem
Not all questions benefit from including code. But if your problem is with code you’ve written, you should include some. But don’t just copy in your entire program! Not only is this likely to get you in trouble if you’re posting your employer’s code, it likely includes a lot of irrelevant details that readers will need to ignore when trying to reproduce the problem. Here are some guidelines:
•Include just enough code to allow others to reproduce the problem. For help with this, read How to create a Minimal, Complete, and Verifiable example.
Good questions contain context and are rarely just one question (more reason press conferences and panels are bad).
When I’m really trying to pick someone’s brain or find an answer I often break questions down into their component parts. If it’s code we need to establish we’re all using the same version. This applies to basically everything.
Questions can go awry when we’re each making assumptions about intentions, definitions, steps etc. So if you’re trying to find something out it’s often best to start small, at first principles.
You can then walk through the problem with the person, just as the respondents on Stack will try and replicate problems. Sometimes you may discover you’re asking the wrong question. Are the assumptions baked into the question the real answer?
Obviously this only works in a medium where you can go back and forth.
Lastly there needs to be some amount of good faith. This is why I like anonymous questions delivered by a moderator at events, and why short interviews make little sense. Is the question a genuine attempt at knowledge or is it trying to convey something else?
As usual my emphasis.