10:12 > hey, can I ask you a question?
10:24 < fire away
10:31 > my css is broken
It can be quite frustrating to have someone ask you for help, and have it turn into an exercise of interrogating them to get all of the contextual information that they didn't provide.
When you ask someone for help, even if it's part of their job, you are asking them not only for their time and attention, but you're asking them to take that time and attention away from what they were doing before.
Thankfully, this experience can be designed to be as friction-less as possible for all involved.
"This page isn't working."
"Okay, are there any errors in the console?"
"Um." *opens console to check*
If something has gone catastrophically wrong, there will likely be an error message, either in the console of your web browser, the debug log of your sever, or in... wherever it is that desktop applications log their errors to these days (sorry, I just make websites). These messages tend to be pretty daunting. Stack traces dozens of lines long, file names you've never even heard of, but there's a positive twist: you can almost always ignore everything except the first couple of lines.
Read the error message, understand the error message. Become the error message. Only then should you proceed.
This applies mainly to asynchronous communication, where an immediate reply isn't necessarily expected or guaranteed, and there is already the expectation that whoever you are contacting will respond to you when they have time.
I get a lot of messages along the lines of "hey", "are you around?" or "can I ask you a question?"
Realistically, the answer to these questions is almost never going to be "no." Especially if we're co-workers. Am I really going to say "no, you may not ask me a question!"? I get that you're trying to be polite and unimposing, and I do appreciate that, but the real end result is that now I either have to a) spend more of my attention waiting for the other shoe to drop or b) go through the extra work of interrogating you to find out what it is that you need.
Unless it's obviously a bad time, or you expect it may take some time to answer, please just ask the question.
If you're asking for help with something, and you think it might take a while, you can work that into the question.
"Hey, do you have
<amount of time>to help me with
<description of issue>? When would you be free to do that?"
Chances are, the person you're asking will be able to give you a much better answer if you provide them with the following information:
- What are you trying to accomplish?
- What, specifically, have you tried so far?
- What, specifically, went wrong?
If you give them as much context as you can think of packed into the question, it brings them up to speed immediately, and they can look at the problem from where you are now, not where you started.
I'm trying to
<do thing>but I get the error
<flargon uninitialised in flange>. I tried
<rebuilding the doodads>but that didn't make any difference. Do you have
<ten minutes>to show me what I'm doing wrong?
I hope these short tips help you to supercharge your questions to get better answers, faster, with less friction for everybody.
Does anybody have any other pointers for asking effective questions?
All coders welcome
Level up every day