How to Ask Calibrated Questions That Will Help You Find a Solution to Any Technical Problem
Why learning how to ask the right questions is one of the best career skills to have as a developer
Programming is hard.
Unfortunately, I don’t see a foreseeable future where a developer can automatically conjure up the solution to a complex requirement without having to consult Google or spend a lengthy amount of time constantly searching for the correct way to do something.
The library of what there is to know about any given programming language and its potential uses is far too large to memorize and adapt immediately. If you can manage to do that, kudos to you. You’re a legend and a savant and I commend you.
But for us mere humans, I’ve found that in order to find a solution to any problem, you have to first know what questions to ask — whether it be for the simple purpose of reversing a linked list or running a large-scale, real-time integration with a specific API that requires further algorithmic processing with the retrieved data.
Albert Einstein even had this to say about approaching problems:
“If I had an hour to solve a problem and my life depended on the solution, I would spend the first 55 minutes determining the proper question to ask, for once I know the proper question, I could solve the problem in less than five minutes.”
Needless to say, knowing the right questions to ask is imperative to development.
This concept drastically changed the way I approached programming and I know I will never trade this philosophy for any other.
It’s exactly what allowed me to implement such large-scale integrations in a matter of days, accomplish tasks that I had no experience doing before fastidiously, and achieve and learn more than I ever have before with relative ease and efficiency.
The real question is this: How do you ask the right questions that’ll bridge the gap between you and the solution?
Spend Time Reflecting on and Analyzing Exactly What You’re Aiming to Accomplish
You don’t want to approach any task blindly. This may seem very obvious to you, but more often than not, we tend to hop straight into things without really understanding the task we are trying to accomplish.
This might lead to you either do more, do less, or completely stray away from what was expected to be implemented.
What better way to define a goal than by asking your manager or technical lead the exact details of what you’re trying to accomplish?
This is all for the purpose of trying to understand the requirements you receive.
I know I regularly feel that I get a task that falls short on details — something I sense I’m not alone in feeling. Instead of trying to hop straight into things trying to piece together the missing details, just ask and get the task distributor to fill in those blanks.
A few example questions may look like:
- Where do you want this to lie on the user interface?
- How do you intend this particular feature to fit into our current implementation?
- Is there a specific functionality that I should be aiming to achieve?
- How do you imagine the user to be interacting with this particular component?
Again, this is nothing more than gathering requirements. And once you understand the requirement, you can adequately form a clear path for how you intend to accomplish said requirement.
This way, you have a clear-cut goal to work towards.
When the Requirement Appears Too Large, Break It Into Pieces
This is the most crucial skill to have in the whole of software development.
Don’t take my word for it, though.
During a Talk at Google about the philosophy of software design, Stanford Computer Science professor John Ousterhout made the point that problem decomposition is the most important thing in all of computer science.
I couldn’t agree more.
When you’re assigned a task, it more often than not is something rather large in scale, making it hard to understand exactly where you should start and what direction you should be going in.
That’s why you need to ask yourself how you can break apart a problem into tinier, more achievable components. When a task is separated into tinier micro-tasks, you can then approach the goal of the large task in a milestone-like fashion — getting lovely hits of dopamine every time you achieve said microtask.
So ask this question: How can you take this problem and make it smaller? Exactly how can you dissect this beast?
This is for the purpose of making your life way easier and less stressful.
For example, when I tackled building my first real-time integration between Salesforce and another CRM, I had to first understand every different tiny project that existed within this larger one. What were the steps I needed to take to make this easier? This led me to ask some of the following questions:
- How’s the API and JSON response structured and how do I find that out? Review other CRM’s API documentation, write mock rest callouts that emailed me the response from the other system.
- How will Salesforce receive the changes that are made in the other CRM and update accordingly in real-time? Rest Web-Service with HTTP Post, publicly expose the web service, add the service as a webhook in the other system.
- How will I display and process that information in Salesforce and update the other system with changes made inside of Salesforce? Create a class that acts as an object to parse the JSON response and store variables in the class, utilize GET, POST, and PATCH requests to the other CRM, understand how a post request is structured in JSON.
- And the list goes on and on.
When you look at the questions I asked and the answers I then came up with as I was approaching this problem, what I needed to focus on each step of the way became evident in order to maximize my productivity in getting this requirement done.
That’s why you need to do the same by asking very specific questions to extract the exact path and plan you need to follow to achieve the task.
The #1 Tool for Consistent Progress: “How” Questions
Asking “how” questions is the bedrock of any inquiry a programmer puts in the Google search engine in order to find an answer to their pressing technical needs. Normally, you can find yourself landing in some programming forum like Stack Overflow.
As you see from my examples above, it’s clear that the “how” question is not solely utilized to answer technical questions but rather as a tool to drill down from the initial requirement to the expected solution.
But honestly, it’s not always as simple as just asking a very direct question — though it is an amazing feeling when you do find the answer right away.
If the question is too broad, you might not find exactly what you’re looking for. Or if the question you’re asking is too specific to a unique problem, then you probably won’t find an answer there either.
These are the easy and straightforward questions that we ask every day in programming, but what about when a problem gets way too complex and things suddenly no longer become obvious?
“How” questions drive development through specific goal-oriented action, but when things get difficult, you must understand the subtle art that surrounds these complexities, as the straightforward question may not always output a straightforward answer.
When the “How” Question Can’t Be Answered, Apply the Power of the Meta-Question
I’m sure you’ve experienced this scenario many times: You don’t know how to do something and you go inquire Google about it. No luck on the first go, so you try again and again and again. You keep on going until you’ve exhausted all of your options and restructured your question in so many ways that you eventually just slam your head on your keyboard with hands grasped tightly around the follicles of your hair, preparing to just rip it all out. You’ve convinced yourself that you’re stuck.
I’ve been there many times and I’m sure that I’ll personally never stop experiencing this feeling so long as I maintain my seat as a developer.
But maybe you’re just experiencing this because you’re asking the wrong questions.
As programming is a craft that requires quite a bit of critical thinking, you have to understand that you can’t find everything you’re looking for through a simple search.
You need to be asking the right questions.
The questions that surround the most obvious and specific “how to” questions. I like to call these meta-questions. The questions that are manifested as a product of strategic critical thinking exercises that surround the initial obvious question — the questions within the question.
Now that might be hard to wrap your mind around, but think about it: This aligns heavily with the idea of problem decomposition that I spoke about earlier.
Imagine you were given a requirement to take an online form that has to automatically generate that information upon submission onto a templated PDF and store that as a file into the cloud database.
Your first instinct is probably to outright ask how to generate a PDF from the information stored on the online form. You’ll most likely get information on how a PDF is rendered but nothing specific about how to accomplish the uniqueness of your task.
In this situation, it’s best to think in terms of what information you’ll need that surrounds this pickle that you’re in.
So what you should do is ask:
- How is a PDF generated and formatted in the first place? This will bring you to exactly how you should go about building out the template of the PDF and passing in the proper headers.
- How do I pass this specific information from the form into the templated PDF? This might bring you to the idea of making the PDF a web page that grabs information from parameters in the URL so the proper queries can be made for that form information.
- How do I save the PDF page as a file without redirecting away from the current form page? This might bring you to the need to store the generated binary data from the PDF into a blob (binary large object) data type that can then be inserted as a file upon form save.
This is a problem that I actually had to face while building around the limits of Salesforce cloud development, and it is these exact questions that I asked that ultimately got me to the solution.
What you need to know is that most programming problems aren’t going to offer a beeline path to completion. You’ll need to think about the structures that surround a specific problem and aim to answer those foundational questions that’ll allow you to build out the material to form the larger solution that you need to achieve.
This by no means is an easy task, but it’s effective and gets you to understand a lot more about the language and the systems that you are working with.
Steps Summarized (TL;DR)
Remember the importance of asking calibrated and purposeful questions whenever you approach a new task.
It is these exact types of questions that allow you to deconstruct a problem to make it more achievable and understandable. Once you think this way, hardly any task that you’re given will cause any major roadblocks to forward progress.
- Define the goal and purpose of the task by gathering more details on the requirement that was handed off to you.
- Break the task down into microtasks by asking internal questions of how you imagine the tiny structures that make up this task.
- Ask the straightforward questions first to find answers to problems that other people have faced before.
- When the straightforward questions don’t work, think about everything that surrounds the task that can make it possible. These are the questions within the questions, and they go hand in hand with understanding the structures that make up the microtask.