Questioning Your Questions

As a dev lead, people often ask you questions. The questions come in many shapes and sizes; one type of question that is constant, implementation questions. In this post, we are going to talk about what defines a good implementation question. To start, this blog features a handful of posts that emphasize the importance of asking open-ended questions. There is absolutely a time and a place for that style of questioning. That time and place is when the scope of the question is of various sizes, but always with a limited set of constraints or a well-defined, globally understood set of constraints. Meaning, you can ask anyone in the industry who has a working knowledge of the technology or understands the domain at a high level. For example:

• What is a way to build a case-insensitive dictionary key lookup in this specific technology?
• How would one structure data to store user product purchases and preferences?
• What data do you expect this form to collect?

All of these examples are open-ended and can be answered without much context or the need to add additional constraints to refine the question. A general working knowledge of the engineer's task is satisfactory. If you need more context than that, an open-ended question is not for you.

We are not in a position to ask an open-ended question, so what do we do? In this scenario, the engineer is hard stuck on the problem. What then? I love it when someone leads off with the question to focus the conversation, then begins to add the constraints and issues they are struggling to overcome. This sets the foundation. I now know the one-to-many issues that we are up against and the constraints of the problem at its current state. From there, we can begin to dissect each problem to overcome the obstacle. Often, questions fall in between these two extremes. They are not well understood by all parties, and the engineer is not hard stuck on the problem.

Similar to the previous example, state the question you have, then add context. As you are adding the context, I find it very helpful to bring along your opinions on how to proceed. Normally, during this phase of the discussion, I am already forming my own opinion of experiments to try or appropriate solutions. Knowing where each of our heads is at, we drive the collaboration to a solution. Continuing this pattern of sharing often yields more experiments to try and outside-the-box thinking needed to navigate the problem space.

As you and your team are working together to solve problems, try different styles of questions to see what works best for your situation. Avoid one party dominating the communication and focus on experimentation to prove out the solution before committing any drastic changes.