Any developer can attest to the fact that the greatest feeling while programming is the one we get when we fall into “the zone”. The biggest obstacles to getting into the zone are interruptions. An interruption can come from anywhere, like construction workers outside the window or laughing coworkers. One of the most significant, however, is when a coworker asks a question. Asking the question itself is not a bad thing – if it helps save 30 minutes. When asking a question, you should focus on keeping the interruption as minimal as possible.
Try to Communicate Concisely
Let’s start off by looking closely at this conversation:
This may look like a typical conversation, but let’s take a look at the many opportunities for improvement.
First of all, Bob started out with a pointless greeting. By doing that Bob interrupted Marley twice, with a pause between interruptions. Marley started going back to work, when Bob interrupted her yet again.
Secondly instead of asking a question in a single well structured message, Bob kept sending each individual thought separately. He even made a typo along the way, which he corrected in a separate message. In essence, he was keeping Marley’s attention on the chat needlessly and making the interruption impact as large as possible.
Thirdly, once Marley gave Bob feedback, he notified Marley that he will look into it. Unless it takes hours or more to try out an idea, he shouldn’t really bother to tell that that he is going to do it. Marley already assumes that he will and simply wants to know the results.
Finally, Bob sent Marley a massive wall of text in network logs. Now Marley needs to scroll back and forth in an awkward chat client trying to make sense of what Bob just wrote. What he should have done instead, is send Marley a secret gist. After she is done reading it, Bob can simply delete it. If your company has very strict rules, Bob could have even just sent Marley a text file.
Avoid Inviting People Over For Trivial Questions
Here Bob ended up pulling Marley out of her entire workflow. Now Marley needs to drop everything, completely clear her head, and go to Bob. It isn’t that you should never invite someone over. Discussing a difficult problem can be a really good exercise, save lots of time for the company, and teach both parties a solid lesson. However, you should invite somebody to my desk when you are absolutely sure you are dealing with a difficult problem, the problem is too complex to write down in IM chat or you have some other sensible reason for it, like doing pair programming.
Write Your Questions Down
So what happened here? First Bob interrupted Marley. Then while Bob started to write his question, he started to deeply think about the problem and came upon an answer. Finally, he decided to interrupt Marley again. The entire conversation was a waste of time.
What he should have done is write the introduction and question down in a single message like this:
This is a perfect way to ask a question. He was polite and did not demand attention before he wrote the question. The moment Marley sees the message, she can start helping Bob. Bob minimised the interruption when asking for help.
Another benefit of this approach is that you start thinking about the problem before making contact. This is really important – when you are stuck, you might try all kinds of solutions without really thinking about the problem. When you start to articulate your problem to somebody else, though, you will often shift your focus from solution to problem. The answer often hits you just by writing out a question or new idea that comes to you when asking a question. This is called rubber duck problem solving.
Ask About The Problem, Not Your Solution
Now that we have gone through the subject of how to ask a question, let’s talk about what to ask. When asking the question people often fall into the trap of the XY problem. This means that instead of asking about your actual problem, you ask the question about your solution. From stack overflow: That is, you are trying to solve problem X, and you think solution Y would work, but instead of asking about X when you run into trouble, you ask about Y. This usually makes answering the question take up a lot more time then it should. For example:
I think the article in Stack Overflow addresses the XY problem in a beautiful way and I suggest every reader of this article also go through the stackoverflow link. But in terms of software development – when you ask your co-worker a question, try to always include the context and broader picture. Experienced people in field know that you can solve a problem in multiple ways and your approach might not be the best approach. Do not be offended when they ask you for context and offer alternative solutions.
In conclusion, keep in mind that whenever you ask a question, you not only spend your time, but the other person’s as well. Don’t be afraid to ask questions, but keep the interruptions at minimum and think about the etiquette you would expect when being asked questions.
