As it was expected, that strategy is too risky. I had very bad matches afterwards. A good example is the last one: SRM 582.
In SRM 582, I opened the division 1 hard, it seemed a bit complicated. Then I opened the div1 medium. I spent the remaining tens of minutes trying to code an easy (but super slow) dynamic programming approach. In the hopes that maybe, once that approach is coded and understood, I can optimize it to O(N^2). (This is an approach that has worked for me in the past). But I kept having issues with the example cases, so something was probably wrong, either in the code or in my understanding of the problem.
I opened 250 points problem. I only had 10 minutes. I realized that it could be solved by a binary search. The matching afterwards could be done with some greedy strategy. But I had the *brilliant* idea to use min-cost-flow to solve this. Unfortunately, it seems I spent more time than I planned pasting and tweaking my min-cost-flow solver (It didn't help that KawigiEdit has the habit of turning slow when there is a lot of code).
At the end, this one last SRM has taught me. The strategy is too risky. I need a change.
This is the reason that , from now on, I will change my strategy: I will no longer open the easy problem during the coding phase. I will only open the medium and hard problems and dedicate all the coding time to attempt to solve at least one of them.
I bet this new strategy will be much less risky!
(Wikimedia Commons)
