The screw and the hammer: Love the problems, not your solutions.
How many times in your software development career have you heard the following quote?
If the only tool you have is a hammer, you tend to see every problem as a nail.
Also known as The law of the instrument or golden hammer this quote by Abraham Maslow describes a cognitive bias that involves an over-reliance on a familiar tool.
In software development that hammer could be anything you are accustomed to: a design pattern (Factories and Strategies anyone?) a language ( writing lots of NodeJs code when a tiny shell script would do the job), a framework ( React + Redux even for the tiniest simple web page), or architecture approach ( API Gateway + Lambda vs Containerized application with Load Balancers).
One solution to rule them all
Briefly, the law of the instrument means that we often tend to over-rely on a familiar tool, in fact, as soon as I hear someone speaking about an API/microservice, my first thought is:
well, easy! let’s use APIGateway and a Lambda written in NodeJs, eventually add SQS and DynamoDB if we need queuing or persistence, done!
That might be the right solution, especially for an MVP; but it could prove very wrong under some circumstances.
This cognitive bias could be very dangerous in problem solving.
At the very least it is just a big constraint to our creativity, but it could lead us to major problems like completely wrong approaches to the problem or over-engineered implementations just because, well, we really struggle to drive that screw in with our hammer.
(many years ago, I had a colleague that, for fun, on a pet project, decided to use every single design pattern he recently studied. Believe me, it was not fun in any way, the code was terribly — and of course unnecessarily — complicated.)
Recently I read this quote that summarises very well this concept (sorry I could not track back the source):
Fall in love with the problem, not the solution
Sometimes it is not just a simple bias of being used to a certain tool, which makes us see it apt for any job. Sometimes ( consciously or not) we are so in love with a solution that we really want to apply it for any problem that comes at hand (again, we could be taking about the Decorator Pattern, Docker or Blockchain, it doesn’t matter).
The thing is, no matter what problem you have to solve, you think you know already the answer:
Oh, yes… that is definitely the case for XY!!
Bias, bias everywhere
The way we perceive, see, and make sense of the world that surrounds us and inside us is strongly influenced by biases, and our problem solving skills are impacted too.
Just a few examples. ( You can see an interactive map here)
- Confirmation Bias : the tendency to search for, interpret, favour, and recall information that confirms or supports what we already know and believe.
- Occam’s Razor bias : the simplest explanation is usually the best one.
- Attentional Bias : individual’s failure to consider alternative possibilities when occupied with an existing train of thought.
The law of the instrument is just another one, a mix of many, if we like. We like a solution, we invested time in learning and understanding some tech-stack, we are conservative, or tend to favour shiny new things, we google and read only blogs that share our point of view and so on. It is perfectly natural that our creativity in problem solving ends up constrained and bias. So what can we do?
Well. like for any other bias:
- Be aware of it
- Try to resist and challenge it.
The analysis of the requirement, and the process of problem solving should not stop immediately just because you already have a solution in mind.
Keep asking questions, keep digging.
Do not rush. Always come up with a 2 or 3 alternatives, so that you can at least compare them and present them to other people ( which may have different bias than yours):
This one is over-engineered, this is not scalable, this is scalable and simple but too expensive, this is the quickest.
Put extra effort to become your own devil’s advocate.
If you have many options, you ( and the stakeholders) can make an educated choice.
We are paid to solve problems not to write code.
Of course we mostly solve problems by writing code, but that is not the point per se.
We are not paid by how much code or how long we write code. ( hopefully your company does not rate your performance in LOC), so it does not matter if you wrote a super cool designed strategy pattern, or if you wrote a very complex, perfectly unit tested, algorithm. Maybe it was not even necessary, had you tackle the problem from another angle.
Or maybe it could have made more sense to buy a ready made solution instead of implementing it in-house.
Is that really a problem?
Another important aspect I’d like to touch is that we must learn to love problems.
Many people feel stressed as soon a problem arise.
They get anxious, feel overwhelmed by obstacles.
But, unless, there are other factors like impending deadlines and very unhealthy team mood, it is often a matter of perception and perspective.
Try to reframe what a problem is:
A bug?
A need that has to be fulfilled?
As much in my early days as developer I hated my Project Managers telling :
There are no problems, only challenges.
I really stopped to see problems ( bugs or requirements) like annoying obstacles to my happy and relaxed working day, rather as challenging tasks which indeed make my working days always interesting and fun.
And I started to love the quote “GOOD!” from Jocko Willink:
Unexpected problems? Good! it means we have the opportunity to figure out a solution.
I love problems — I do boulder!
I love climbing and bouldering. In bouldering the routes — basically the way, the path you want to climb — are called problems.
Think of it like that:
You are there, facing a wall ( or if outdoor a block of stone — literally a Boulder), and you ask yourself:
How do I climb that?
That is your problem. And you have to find a solution.
How do you use your body, your balance, your strength, how do you take advantage of every hold, grip, texture in the surface to finally get to the top?
This sport has taught me so much about myself, my strengths and weaknesses, and about looking at difficulties and finding ways to overcome them that it had inevitably an impact in my problem solving skills in my life and in my job. I will definitely dedicate a separate post about it.
Recap
- stop and think, don’t rush into quick solutions.
- avoid the temptation to settle to general, known and safe approaches.
- understand the problem first, understand the context. are we trying to solve the right problem?
We fail more often because we solve the wrong problem than because we get the wrong solution to the right problem. Russel Ackoff
Of course I am not stating in any way that you should not be happy with the solutions you come up with, and even be proud of yourself when you solve a problem brilliantly, on the contrary, give yourself and your team all the recognition you deserve, but just be aware of the trap and don’t be tempted next time you have a (similar) problem to default to the same solution.
Photo by Konstantin Evdokimov on Unsplash
Originally published at https://dev.to on November 11, 2021.
