Yes , I have to admit this , when I see solution , I instantly jolt down to type it without even thinking , how will the actual solution look like ,
Like the last time div2 500 , seeing the solution instantly I saw the approach but then two blunders 1. I don't correct give order to my dx[] and dy[] coordinate. 2. Second As I have copy pasted the condition for two if's L and R I never changed the second if condition to 'R' until I was printing everything from my program for debugging. Also as I am able to recognize the repetative blunders , I now developing habits to spot those mistake first . On Aug 11, 12:24 pm, Bartholomew Furrow <[email protected]> wrote: > > Stay calm. The costs of a debugging a bug are still relatively enormous in > > terms of development time. Rushing has a negative expected value, > > occasionally it will pay off when you hack out a solution that just works, > > but most of the time being slow and deliberate will be much better (is this > > off by 1? what happens when n = 0?, etc) will save you oodles of debugging > > time and will make it a lot more likely that your submission is correct. > > Rob nailed it. Particularly when you're > new to competitive programming, it's easy to rush through things and > tempting to take a risky approach. > Consciously slow down, consciously think about boundary cases, and leave > the speed for when you get more comfortable. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-codejam" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-code?hl=en -~----------~----~----~----~------~----~------~--~---
