Are you asking too many questions, or not enough?

Two scenarios that may sound familiar:

• You’re in an office space and there is this one person who always asks questions that they could answer on their own by spending two minutes using Google DuckDuckGo. He feels super productive because he’s getting answers quickly, but the senior who has to answer starts getting annoyed by all the micro interruptions. It makes it hard for her to focus.

• A new person joins a team, and they hardly ask any questions. Instead, they spend hours trying to figure out everything on their own.

In the first example, the person values their own time a lot and shows little regard for other’s time. In the second example, the person respects others’ time too much and doesn’t want to bother them with questions they can figure out on their own if given enough time.

Both cases are problematic. Ideally, as a developer, you try to find a balance between the two.

Here are some suggestions:

• Research suggests that interruptions can cost anywhere from 15 to 30 minutes. If you can find the answer on your own within 30 minutes, consider looking it up on your own. On the other hand, if finding the solution on your means that you have to study for several hours and you suspect somebody else on the team could answer it in minutes, then it’s worth asking.

• Batch questions. For example, if you’re new to a large codebase, you will likely have many questions. Take note of areas you find confusing or don’t understand well. Later, schedule a session with a senior developer to get these questions answered. If you want to be extra helpful, don’t keep the answers to yourself. Go back to the areas you had trouble understanding and improve them. Add some documentation, code comments or rewrite pieces if justified. Others who come after you will benefit.

• Use a rubber duck: Phrasing a problem and speaking it out loud or putting a problem into writing helps organizing your thoughts. Because of that, you often end up answering your own questions while you’re asking them.

• If you already spent one or two hours trying to solve a problem, take a break and recap: Did you make any significant progress? Do you have a plan to continue, or are you stuck and slipped into a mindless trial and error mode? If it’s the latter, try approaching a colleague with your problem and explain what you have already tried.

• Take the time to learn the basics. Sometimes you’re working with a system or a library that you’re not too familiar with. Often, you’re okay making a couple of minor changes. But every once in a while, you struggle because you lack a fundamental understanding of how the system works. If you only need to make changes occasionally, it may be a viable strategy to ask an expert from the team for help if the need arises. However, if you’re going to continue working with the system for a longer time, learning the basics will be worth the effort.

• Use an asynchronous communication medium to ask the questions. This lets the others control their interruptions. When they need to focus, they could close their chat or email client. But don’t sit idle waiting for an answer; either continue trying to figure out the solution on your own or switch tasks. And remember: Don’t ask to ask, just ask.

• Pair with another person. You can’t interrupt somebody who is directly working with you. This can be a great solution to get up to speed, but it isn’t for everyone.

These are no new world-changing insights and you probably already do some of this intuitively. Take this as reminder.