The best programming problem solving technique
Problem solving is your main activity as a developer. Getting good at it is mandatory. Fortunately, there are specific techniques for exactly that. That’s exactly what we’re going to talk about today.
The technique is my personal way of doing things. I use it when faced with programming problems of course, but also more generally in life when it applies.
It’s not a stupid abstract way of thinking that makes no sense in everyday life. This technique is very concrete. It’s a very precise sequence of actions and analysis. I manage to solve just about everything in a relatively short period of time by using it.
I don’t magically pull that out of a hat. It is the result of two things.
- My almost 10 years of experience in development in front of all kinds of problems of all sizes.
- The timeless principles of the greatest book on the subject: How To Solve It.
This book is a monument for our subject today. For the sake of length, there are many things in this book that I don’t cover. But it’s one of the required readings if you really want to get good at problem solving.
For now, just know that these are timeless problem-solving principles used by generations of people. My experience has allowed me to twist them correctly to bring them into the world of development.
Also, not every problem deserves all these steps. The more complex your problem is, the more actions you will use in this technique.
It’s up to you to choose the actions you need.
A very large part of so-called complex problems are in fact misunderstood problems.
If you get into a task without really understanding what you have to do, you’ve already lost. I say that right away, because I know a lot of developers do that. I’ve done this quite a few times.
But it gets worse than that. Going into a problem and believing that you understand it when you don’t understand it at all. It’s much worse!
So how do you make sure you understand the problem?
I use three concrete actions:
Often, your problem is in a JIRA written in a hurry. The one who does the JIRA is rarely the one who will do the work. He doesn’t need to put all details. But for you, it’s absolutely crucial.
You need to rephrase the problem in a short, clear explanation. If you can’t do it on your own, you’re not ready to start. You only understand what you can explain simply.
A few sentences written in the JIRA task are more than enough here. We don’t solve the problem yet, we only define it. Believe me, it takes a few minutes, it can save you hours of work.
For the second action, it will be about simplifying, or even reducing, the problem.
Simplify your problem into a sentence that only addresses the key elements of what you need to solve. Remove noise and focus on the essentials. What is noise and essential to you is not necessarily reality.
The purpose of all this is to validate your reasoning against the reality of things.
Last action to clarify your problem, have it validated by the person asking you. Just send a mail/slack/JIRA to this person with the reformulation of the problem.
Can you validate that this is the problem you want to solve?
In my experience, it is almost 80% of the time that the problem is partially or completely redefined. This is where you reduce your problem solving time the most.
Yes, before you start.
Better than that, it’s not uncommon that the problem is actually not a problem at all! Sometimes the problem isn’t where you think it is. Sometimes the problem doesn’t exist. It takes the communication of two different profession to find out.
All this part is long to explain, not to apply. All this should take you a maximum of 20/30 minutes. Really maximum!
If you’ve gone through all this, you have a real, clarified and validated problem in front of you. Now, you need a plan.
As a developer, you spends very little time creating new systems. Most of the time, you read code and modify an existing system. It is these systems around the problem that makes the task complex.
It is therefore by strongly taking into account the system around the subject that you will facilitate the resolution of your problem.
Under these conditions, you have to plan what you are going to do before you start.
To do this, I do two concrete actions:
Paper / pen, or a whiteboard when I have one available, I make a diagram of the context of the solution. I visually represent the problem in its context. This is absolutely redoubtable for the rest of your work.
The idea here is to plan a first flow for a solution by representing a path for the data in the system.
This is the time when you try to think of everything and display it in a big way to make sure you don’t miss anything. Since the beginning of the pandemic, I have invested in a whiteboard to do this at home. What a pleasure!
I’m repeating myself, but quickly drawing a solution, it takes a few minutes, it can save you hours or even days of work.
Now you can plan what you’re going to do. Here, I make a bullet point list of each major step based on the diagram.
The objective is very simple. You should never have to ask yourself: now what do I do? Your past self has already dealt with this.
Now it’s finally time to launch your code editor and write the solution.
You should follow the logical steps from a textual and visual clarification of the problem you’ve done just before. Each major step, taken one by one, should then be broken down as you code.
I distinguish two major actions in this part:
You’ll find this advice everywhere, but I’m adding a layer because it’s far too effective. You have to divide each problem into simpler sub-problems until you think it’s doable.
Concretely, as long as you have a problem in front of you that is blocking you by its difficulty, don’t try to solve it! Break it down into smaller, simpler problems and try again. Very quickly, you will come up against a very small and simple problem. Now you can start.
The second action is to iterate quickly on the resolution of a problem before thinking about the quality of the solution.
Concretely, and in a short version, you have to get rid of your blockages and especially your analysis paralysis in front of a problem.
To do that, you need to allowed yourself to make fast, disposable code to prove the viability of a solution. Once you have validated that your problem is really solved by this solution, you keep the concept, but this time you make beautiful code.
This division/iteration sequence in the code part is monstrously powerful! When I started doing it this way, it changed everything. As time went by, the most complex problems were less and less impressive.
Unfortunately, I’ll be honest with you, I didn’t manage to do it all efficiently overnight.
Problem solving is a true skill in itself.
The good news is that, like all skills, you can become better at it. The bad news is that you have to work on it to improve and/or maintain it.
This is done over time and especially on a regular basis.
When I started preparing for important technical interviews, I did what everyone else did. I went to LeetCode to do some exercises.
I was absolutely terrified that even some of the easy exercises were out of my reach. Am I too stupid for all this?
And then I insisted. Over and over again. There’s no way I’m going to let myself be impressed.
I noticed that the more I did these kinds of exotic things, the simpler they were. My impression of these exercises then quickly changed. I went from a hellish puzzle to a funny puzzle to solve.
That’s exactly what I want you to achieve.
See things as funny puzzles to solve. By the time you get there, you’ve already done 90% of the work required. Your brain has been trained for this difficulty, the gymnastic is done. Problems that were heavy become lighter.
Only one action here: choose a free platform like LeetCode or HackerRank. Choose a challenging problem for you and apply the technique I’ve just unrolled in this article to solve it.
Do it on a regular basis (you decide the frequency), I promise you permanent results over time. Our brain is not a muscle, but it can be muscled. I don’t know anything more effective than regular exercise to do this.
I promise you immediate results with this technique. You’ll get even more along the way. As I said in the prologue, you don’t necessarily have everything for every situation. It’s up to you to choose the one that’s most optimized for your problem. If just one action from all of this will allow you to do your job better, I have already achieved what I wanted to do with this article.