Improving at competitive coding

 How not to bitch about solving lesser problems

Whenever I ask anyone about how to improve, all they say is "Solve more problems". Bitch. I know that. Do you have anything else to offer? 

So just like other things, this too we have to do on our own. And what does that mean? Analysis!

So I thought of all the phases of solving a problem and made this shitty diagram : 

My main aim to find the most time taking stages. What I understood was, that the main "problem solving" stage, where we think the hardest is the most important one. It might not be the one that takes most of the time itself, but surely is the one that directly affects the total time taken.

Let's just say that I as a person can solve some problem in $T$ minutes, when no re-implementation or code changes are made.

Now let's consider the case that I ran some tests on the code, and it failed for some case. Either we did some silly mistake, so we need to debug it, or our solution is wrong, and we need to rethink the problem.

In this case, again, intense thinking is required, and immense time is wasted. What we can do is make sure that the solution we're implementing is the best version we can give. It's well tested, via dry runs, and should have the least amount of bugs. 

This is a doable thing. It's more of a good habit, than a skill upgradation, as it doesn't require you to improve problem solving, but just stopping a while, testing the solution well in mind, creating some edge cases, and then  implementing it. 

This should save massive amounts of time in competitions. Let's see if this actually improves anything, or is just the intuitive thing people anyways follow. Big eh time.