Problem Solving: Introduction & Why Questions Matter

It often happens to software engineers that we get asked about anything that has electronics in it (because obviously, if it has wires and chips it must be IT-related) and are expected to be experts at it. For example, if someone was to ask me how to fix their refrigerator’s ice maker or why their washing machine display is showing error code E47, I would have to say that I have no idea. For me, that specific problem, at the time I was asked and with the knowledge I had, was hard. On the other hand, problems which I solve everyday would look “impossible” for some other pair of eyes.

Problems are relative to the knowledge and context of the person tackling them. Even some of the simplest ones we can think of are so because we understand a lot about them. Otherwise, you could ask a toddler about anything that we consider simple and see if they could do it. (WARN: Careful with what you ask a toddler to do, they would try to find a way).

Understanding Problems is Already Solving Them

It is obvious that without problems there won’t be problem solving, hence dedicating a good amount of time - I’d say at least 40% of your problem-solving effort - to understand the problem is already solving a big part of it. But understanding problems is a problem by itself so, what do we need to know about the problem? How much time shall we dedicate? How do we know we are dealing with the REAL problem?

Throughout this series, we’ll explore these questions and more:

There Are No Answers Without Questions

Every problem starts with a question, so it should not hit us by surprise that there are no answers without questions (let’s stop the metaphysical conversation here), and neither should it be unexpected that often the right answers are given to the right questions.

“O Deep Thought Computer,” he said, “the task we have designed you to perform is this. We want you to tell us…” he paused, “…the Answer!”

“The answer?” said Deep Thought. “The answer to what?”

“Life!” urged Fook.

“The Universe!” said Lunkwill.

“Everything!” they said in chorus.

[… Seven and a half million years later]

“Alright,” said Deep Thought. “The Answer to the Great Question… Of Life, the Universe and Everything… Is… Forty-two,” said Deep Thought, with infinite majesty and calm.

[…]

“But it was the Great Question! The Ultimate Question of Life, the Universe and Everything!” howled Loonquawl.

“Yes,” said Deep Thought with the air of one who suffers fools gladly, “but what actually is it?”

A slow stupefied silence crept over the men as they stared at the computer and then at each other.

“Well, you know, it’s just Everything… Everything…” offered Phouchg weakly.

“Exactly!” said Deep Thought. “So once you do know what the question actually is, you’ll know what the answer means.”

Douglas Adams, The Hitchhiker’s Guide to the Galaxy*

This paragraph from one of my favourite SciFi books just illustrates how much frustration a wrongly framed question can generate. Even if it has an answer, it does not mean it was the answer you were looking for. We should be thorough when asking questions, in the same way when you make your 3 requests to a jinn - if you miss a detail on the request, it may backfire on you (and it could be both because of ignorance or because of malice, but jinn ethics is a topic for another book).

Questions Work in Two Directions

There are multiple ways of improving at asking questions. Remember that questions are not only to be asked to others, but you can also ask yourself certain questions. As you read this series I want you to think about questions in both directions: asking others and asking yourself.

You will observe that more often than not, when we ask questions to ourselves we could also benefit by framing them like if we spoke to others. This is a millennial technique but in Software we have often defined this as rubber duck debugging - the practice of explaining your code or problem to an inanimate object (like a rubber duck) to find the solution.

The Two Pillars: Context and Intention

There are many things that make a good question but for a good question that can help us find the problem we are trying to spot, I would highlight 2 areas:

The Context - Everything that surrounds the question: assumptions, the where and when, the expected behaviour
The Intention - What kind of answer you’re looking for and why you’re asking

The best way of getting these right when asking questions is by answering two simple questions:

“What information do I need to provide so that the other person can reproduce/observe the problem?” (Context)
“What kind of answer do I want?” (Intention)

In the next posts, we’ll dive deep into each of these pillars and learn practical techniques to master them.

Next in the series: The Context - Learn what information you need to make your problems reproducible and observable.

PS: Eat your veggies 🌱