Following George Pólya’s Methods of Problem-solving. How It Might Help You In The Process of Coding.

A few months back, when my coding instructor started teaching the topic ‘Approaching Solution Of A Problem’ in the JavaScript data-structures track, he introduced George Pólya’s methods of problem-solving.

As said, it’s basically the step-by-step roadmap of approaching the solution of a problem, not limited to just coding problems, but to every aspect of life. And over these months, I’ve started applying the same basic principle of problem-solving, and trust me, it works fantastically!

This method is extracted from George Pólya’s How to Solve It (1945).

In this article, I’ll try to break down this glorious method of problem-solving.

Basically, the method is divided into four steps:

1. Understanding the problem statement.

   
   

2. Making a structured plan.

   
   

3. Carrying out the plan.

   
   

4. Looking back and improving the solution.

   
   

That’s it. These are the magical steps to tackle any kind of problem.

Let’s further dive and understand them in brief.

First principle: Understanding the problem statement.

This surely seems obvious at a first glance, but when I analyze myself before I used to apply this technique, most of the time, I didn’t understand the hidden aim behind the statement and jumping straight toward writing the code was never a wise choice.

Understanding the coding problem is the most difficult and important stage for finding out the appropriate final result for the problem. Understanding what the instance demands from us and how we can break down the same into tiny parts helps a lot.

After I’ve read the problem statement and I feel I’ve understood it, the mind algorithm I follow is:

• Finding out is there anything more that can be extracted from the problem? Re-analyzing again the question always brings something more to ease my work.

  
  

• Can I break down the same into very easy and simplified words that I can explain to a 5-year-old? Sometimes, translating the question to my L1 is also very helpful.

  
  

• Can I visualize a clear picture or outcome of what is being demanded from me?

  
  

• Can I predict the output or result of what is being asked?

  
  

• Are there any constraints I might encounter while laying out the plan to solve it?

  
  

Giving proper time to this algorithm and executing is basically solving 50% of the problem.

Moving onto the next step:

Second principle: Making a structured plan.

From what is extracted from the first principle, try to write a pseudo-code in form of comments, draw a rough flowchart or timeline of how you’ll be approaching the end result, and gradually, the patterns of the solution will start bubbling up, making the work extremely easy.

The best practices to fully achieve the second principle while writing code are:

• Scribbling steps to solve the problem.

  
  

• Drawing flowcharts and timelines.

  
  

• Rough dry-runs and executions.

  
  

• Re-visiting ideas from the first principle.

  
  

It’s hard to believe that with these two principles, 70% of the work is already done, while we haven’t written a single line of the final code!

Let’s move forward and see how the rest 30% work will be achieved?

Third principle: Carrying out the plan.

This step involves writing the code, and trust me, this is the easiest of all the four steps.
From the formulation of the above three stages, convert your pseudo-code into a well-structured executable code.

This is just translating your words and flowchart (that you already have) to code, with the only challenge of remembering the correct syntax!

By now, you must have a working solution to the problem that executes without any errors and somewhat gives the expected output.

This marks the 90% completion of the problem.

Fourth principle: Look back and improve your solution.

The rest 10% will be taken care of by this fourth principle. In this step, we will re-visit our solution and try to improve it in such a way that it is better and more efficient.

This principle might include some of the following ideologies:

• Tweaking the code in such a way that it is more readable and self-explanatory (tough, but give it a shot).

  
  

• Any unnoticed bug or error should be fixed while analyzing the code again.

  
  

• The code should not be producing any unexpected behaviour for some edge cases.

  
  

• How can the code be made more efficient to improve its time and space complexity?

  
  

This might scale up your code to a new level, and that’s it! If you have implemented all the four principles properly and carefully, your solution must be 100% correct, or at least close to it.

I found this technique so helpful and insightful, and over time, I can see improvements in my accuracy.

Thanks for reading this far.