Top mistakes of competitive programmers

Please note that this answer is dedicated to competitive programmers only, as well as some recommendations in it. Competitive programming is not about readability, but about being able to code and debug fast.And still, the mains problems that I've seen: laziness and do not caring about code style even a little. That's ok if your program gets Accepted on first try, but otherwise you're gonna have a bad time debugging it. In general. So, mistakes (all of them are real stories):
1)Focusing on easier and 'cooler' things (like using of bitwise operations a lot instead of straightforward mathmatical formulas) instead of making code simpler to read and debug. Not only for them, but for the one who will help them too.
2)Copy-pasting it all around. "We don't need no architecture, just a little hack here is not bad. Oh, and here is another one. And here. C'mon, I still can tell you how is this supposed to work, but it doesn't work somewhy, can you help me?". "Re-using same code and introduce extra parameter to make it behave little differently in two cases with a bunch of local ifs? Nah, let's just copy this 50-lines procedure and make changes in the new instance.".
3)Having global counters for local loops. Ex-Pascalists do this a lot more than others. Good luck having recursive calls with that.
4)Using global variables for passing parameters instead of, well, parameters. EVERYWHERE. Combine this with copy-paste and you get a monster. Like, if you have three big integers stored in arrays name A, B and C, what is the best way to write a procedure for subtracting one from another? Correct, you write two procedures: sab (subtracts B from A and writes result to C), sbc (subtracts C from B and writes result to A). Oh. My. God. Why don't you make it a pass-by-reference-parameter and one procedure instead of two?
5)Re-using same variable 'because I'm too lazy to declare another one'. So, in this half of program it means 'number of elements in the input' and in the another it serves like 'for' counter.
6)Naming ALL variables and arrays with single letter. For the sake of typing speed, of course. Like this: f[p2] = c, a[i++] = b;. It can be ok if they would be able to completely understand that and debug it by themselves, but, well, beginners are typically not the case.
No identation. At all. "Why do I need it, I'm gonna write this, get OK and noone will read this again ever?". "Oh, yeah, indentation, I'm gonna add this in my next solution, not in this, it's already too big for formatting". This applies to non-competitive programmers too. Thank God, we have Python especially for them :)
7)Concentrating on writing full solution at once, instead of splitting it into several smaller parts and debugging them one-by-one. "Would you mind looking at my 250-lines program which uses two algorithms? It doesn't work." - they ask. I ask: "Which part of your program does not work?". They answer: "I don't know, I've just compiled it and it gives wrong answer". Please, split writing code in small steps, so you can be somehow sure about previous code when writing next.
8)Trying to go and solve IOI problems 'for training purposes' without enough practice. Imho, it's much better to save this problem for the time of actual IOI training, and start with easier ones - there are a plenty of good problems for beginners, that are interesting and challenging.
Courtesy:Quora