This is not going to be the next-generation framework for solving technical problems because it contains the word “problem” twice. Apart from its negative charge, the core idea is as simple as focusing on the most important questions to answer before working on problems.
Problems are addictive. As modern creatures, we need to have problems in order to have a reason to live. Solving problems brings positive feelings, like serotonin, which “ultimately the link between higher serotonin and a lack of rejection sensitivity allows people to put themselves in situations that will bolster self-esteem, increase feelings of worthiness and create a sense of belonging.”
When I was in university, I quickly figured that semantically, and technically, the word “problem” holds a different shade of meaning when logic kicks in: “an inquiry starting from given conditions to investigate or demonstrate a fact, result, or law.”.
Thus, it is perfectly valid to conclude that knowledge workers, like programmers, solve problems on a daily basis. Naturally, the process of solving problems becomes a brain habit, which mingles between the logical system of variables and the more humanistic problem solving psychology.
My personal observation comes to that many people working in the technical sector (the IT sector) sometimes solve problems which are not really problems, because of lack of focus or because of a habit or inability to set the emotions and the psychology aside while solving logical problems.
Asking/answering questions is the most natural way to manage attention and feelings. Questions are the leaders in both scenarios from above.
I think that seniors in any knowledge worker profession are those who have accumulated experience of asking good questions for the problems they are supposed to solve. (And browsing well through the ocean of information after this :)
The ultimate question one can ask recursively: “What am I really trying to solve here?” I believe that answering this question first, during meetings for example, could bring many positive outcomes without too many discussions and roundabouts which take attention and energy to focus.
This is a personal feeling and saying out loud: let’s please first find the problem we’re solving and then let’s look at the tools we’re using. Not to go into too many specifics of a profession, but I see so much energy being spent on things like: choosing programming languages, frameworks, etc. It’s so amazing sometimes to see projects like lebab. I am sure that it’s solving real problems, however it’s not so obvious.
My appeal here is simple: please consider the energy you will spend on tools well, and please base your solutions on real problems, rather than the inner drive to prove oneself as a great problem solver for quick gratification for solving insignificant problems or such that might not exist. That is touching upon the topic of the “fatigue” that developers complain about frequently. It’s a real feeling based on real situations in real life — having to solve many problems at the same time. Managing focus on using problem-first approach in our tool-chains and workflows is a vital part of preserving one’s energy and attention to what really matters.
Although being pretty abstract, the paragraphs above aim to basically communicate the following ideas: