How to solve any technical problem?

BINGO!

I loved saying it every time when I solve a problem and it took me a while to come up with a solution for any problem or tricky scenario.

No, I don’t ever say it loudly to attract or disturb anyone sitting around me. But, just a slight raise of Fist and BINGO. 🙂

I have worked on hundreds of projects (both big and small) during my professional career of almost 10+ years. During that I have solved so many problems and my success rate was quite high. We can say that I was fortunate enough to come up with solutions for those problem in time. But, you know that it’s not just the luck every time.

So, in this article, we will discuss how I have been able to solve problems and what was my approach towards problem solving.

 

If you can’t explain it simply, you don’t understand it well enough. – Ablert Einstein

That’s why to solve any problem we need to understand it and to understand it we first need to go deep enough and simplify it.

So, how can we go deep enough? It depends on the way with which we get this problem.

This is easiest. If we have received a problem in a properly documented format than we can read it. But, we need to read it again and again if we are not able to understand it first time. We can highlight or mark some keywords. We can add comments, so we can elaborate it in our words.

I usually read a document or problem at least twice. In my first pass, I just read from start to end to clear my mind. In second pass, I start reading it slowly to pick words and build scenario in my mind. Anyhow, that’s my approach. You might have different approach for this.

Most of the time people or client don’t like to document a problem or they don’t have time to do so. In this scenario we need to discuss it with them. We can record that conversion (with permission, obviously) and watch or listen it later. Because, we can’t understand it in first time usually. By recording a conversation, we are basically documenting it.

And what happen when we watch or listen that recorded conversion? Yes, we will have more questions. So we will have to go and ask those questions for further clarification. We need not to hesitate to ask questions. Because, if we ask right logical questions, it will help us understand the problem and we will be able to come up with better solution.

We can also include other people in our discussion as well. For example, we can discuss a problem with staff or employees in case we are working with a bigger organization. Because, no one else can explain a problem better than the one who is actually facing it.

So another way to understand problem is to put ourselves in the shoes of people who are actually facing this problem. This way we can go through everything ourselves and understand the problem by observing or facing it in real time.

There can be many other ways to understand a problem. But, as per my understanding, these three are commonly used by most of us.

As we have understood the problem so, now, it is time to do some action.

By doing some action, I don’t mean to start solving it right away and start writing code. We need to simplify it further by breaking down into smaller logical parts, module, projects, etc.

Remember that Divide and Conquer rule. We need to do that exactly with all the problems if possible. I am saying if possible, because, sometime we over-complicate problems and situations instead of simplifying. So, we need to breakdown only if it is required. And by doing so, we can focus on those small parts or modules and solve those quickly and efficiently.

Now come the last phase, that is, to solve a problem by executing, suggesting, implementing or writing a solution.

Although, this is the last step and usually last step is the most difficult. But, if we have performed initial steps carefully, we should have the solution in our mind by now. And we just need to execute it to solve the problem.

I usually divide this in two parts as well.

Writing a solution in simple plain English or in any other language we understand is always a good idea. Because, when we have a solution in front of us it will be easier to program and it will have less errors or none at all.

I try to write a pseudo code most of the time. Or I try to have it in my mind if I can’t write it. Most of the time, I write it. Because, it helps me execute a dry run even before writing an actual program.

Now it is the time to write, program or implement your solution.

To me this is always the easiest part. And that’s why I have been able to do projects in different computer programming languages. Because, I have always tried to go with the basics. If you have your base covered and you are confident enough that your solution is going to work, you can program it in any language for any project or client.

Please share your thoughts.

And

Be a Solution Provider, not just a coder.

Thank you.