‘Why does this give an error?’ - ‘Why can’t I see my changes?’ - ‘What’s wrong with the pipeline?’ - ‘Do you have time for a review?’ - ‘What should we get for lunch?’

It seems, this is what we do. Or at least, what I do. A lot.

And like with everything I do a lot, at some point, I try to question (no pun intended ^^) the process. Maybe, there are factors to be improved. We probably all know the feeling of being interrupted by a question in our workflow that could have easily been answered with a little logic or a google search - I am sure as hell guilty of this (sorry!). My search for good questions started at stackoverflow (where I haven’t yet dared to ask a question) and ended here - in a short list of friendly reminders to myself that I wanted to share with you.

Timing

Might be the most obvious one, but also an easy one to forget in the heat of the moment. Is this the right time to ask? Are you blocked in your daily work until you get an answer to your question, or can your question wait? Especially if you are new to a team, a project or the job in general it’s difficult to figure out when the right time could be. But that’s also you can ask - when a convenient time for questions would be or whether it’s ok to shout out whenever. When I am not sure, I collect my questions as specific as possible (concrete example or even referring to a line of code) until the right moment comes.

‘Let me google that for you…’

I always get really embarrassed when what I thought was a super difficult question gets solved by a colleague in one single google search. A lot of the times, it’s about using the right search terms and differentiating sources. By no means, I want to discourage asking questions. But when I get too excited about solving a problem, I sometimes blurt out questions before seriously attempting to solve them myself. Just pause, google, check your notes, go through your options, google again - then ask.

Rubber duck debugging

This sounded ridiculous to me at first. Our coach at the programming bootcamp told us about this method where you have a little gimmick, for example a rubber ducky, next to your computer and when you get stuck with a problem, you explain it to the ducky. This way, you articulate your struggles, probably paraphrase and hopefully and very likely, get a better understanding of the problem at hand. Rubber ducky or not, I find the method itself super helpful: When I describe a problem in a slack message, there is a pretty high chance of me never actually sending it, because I gained some new insight in the process.

Focus

Even if you are generally confused and don’t know where to begin, try to ask one question at a time. The more structured your questions are, the easier it will probably be to deal with the answer. If you are lost and can’t narrow it down to one specific question, you might not be ready to ask yet. Return to your problem, your rubber ducky or draw a chart if necessary, until you have a concise idea of what you need to know.

Actually listen to the answer

This sounds very obvious as well, but is it, really? Many times, we have an idea in our head of what the answer could or should look like, are nervous about asking in the first place or get distracted by the office dog. Try to actively listen, ask follow up questions and make sure you understand the answer - this is not the time to pretend.