Try contests in virtual participation and resubmit only after understanding why you got WA. Not even once "maybe it's long longs, let's see". It should help you.

Even more hardcore strategy: resubmit only when you find a test for which the previous code is wrong and your new one is right.

You think too much and stress too much. As I said, try virtual participation. It's something slightly less stressful — maybe a good start.

I am in the same situation as you I guess. In codeforces round #356 I knew how to solve problem B and I coded up a solution but I did not notice the '<' char in my REP macro and assumed it to be '<=' cause of which I ended up getting WA on test 3 but then I changed the macro after the contest and then it started working. I couldn't debug it during contest (note: my code was only failing one testcase) and spent all of my time on solving B. I knew how to solve C as well but by then the time was up :'( .

I have been gray for a long time. Now I am green(xD). And I realized that most important thing is don't worry. If you wanna be a good competitive programmer, you need to learn a lot. And sadness only stop your learning. For myself I remember one thing: "The most interesting thing in your goal is a way to the goal". Good luck :)

(Sorry for my poor English)

I had exactly the same problem. I think to cure this problem you should change your mindset about problem solving in general.

Here is my thoughts:

You can not solve a problem faster than your current level is. Do not care about speed right now, do care about correctness. Speed is something which slowly improve overtime as your brain develops "cache".

Try to not submit solution for problem "A" earlier than 90 minutes even if you are sure that it will work.

During these 90 minutes write clean and easy to understand code. Do not look at other's participants hard to read code. You should care about correctness, not speed right now.

Before testing your code read it and think how your code works. Then manually test your code on edge cases. Think slowly on different edge cases. Also, before you submit solution you can read problem statement again to check that you actually get it right.

Prefer not debug your code if you have wrong answer. It's better to read problem statement and code and think where you could make mistake.

When you get correct solution in first submission in five contests in a row then you can slowly decrease time needed to solve problem "A".

This is how I trained to get out of green zone.

Also, I noticed there is a fallacy that you may trapped into: no, no, problem "A" is very easy for me, I just made stupid mistake.

I had the same fallacy. Now, I think if you make even tiny mistakes then you are not on that level right now to solve this problem quickly. You should not hurry till you get 100% correct solution.

Also, don't try to write solution before you have clear understanding what to write.

I hope this will help you.

A general rule is: once you start coding, you stop thinking. I used to suffer from this a lot and still do now, to some extent.

Even when you think you have the solution, take a couple of minutes to go through it step by step until you have absolutely convinced yourself that it is correct. This also helps you figure out the simplest way to code the solution; you may think you are wasting time by not coding, but in the end, you will actually save time this way.

Also, try to only think about the problem and not about results. It's not easy to do, but important.

It would be nice to know how you improved yourself, assuming that you have become specialist on your own :p

One of my ACM teammate rarely gets WA even during practice sessions, I think he got less than 3 WA or TLE throughout 3 matches he competed in this season. (I averaged out around 3 WA/TLE per match on contrast :/ )

This is what he does — Adore his own code for 15 minutes before submission, and be aware of possible peformance improvements during implementation (He never uses untied cin/cout but scanf/printf, seldom uses recursion for dp but a for loop etc. ).

Although this is not doable in a short solo contest but you get the idea — Make sure you understand what your code is doing when you submit, instead of knowing what it should have done when you submit.