The core directive in ‘Competitive Programming’ is this: “Given well-known Computer Science (CS) problems, solve them as quickly as possible!”. Let’s digest the terms one by one. The term ‘well-known CS problems’ implies that in competitive programming, we are dealing with solved CS problems and not research problems (where the solutions are still unknown). Some people (at least the problem author) have definitely solved these problems before. To ‘solve them’ implies that we must push our CS knowledge to a certain required level so that we can produce working code that can solve these problems too—at least in terms of getting the same output as the problem author using the problem author’s secret test data within the stipulated time limit. The need to solve the problem ‘as quickly as possible’ is where the competitive element lies—speed is a very natural goal in human behavior.
Type Code Faster!
No kidding! Although this tip may not mean much as ICPC and (especially) IOI are not typing contests, we have seen Rank i and Rank i + 1 ICPC teams separated only by a few minutes and frustrated IOI contestants who miss out on salvaging important marks by not being able to code a last-minute brute force solution properly. When you can solve the same number of problems as your competitor, it will then be down to coding skill (your ability to produce concise and robust code) and ... typing speed.
Choose Your Language Carefully
Try to learn only one programming language very deeply. Use this language to solve problems. This way you spend less time debugging your code and more time debugging your algorithms.
The most common languages are C, C++, PASCAL, and JAVA. C++ is the most used language for contest problems.
Writing simple code eliminates chances for trivial errors. If you need to debug the code, it will be much easier to do so.
Use descriptive variable names. The time you waste by extra typing is nothing compared to the gain of having code that speaks for itself.
Perfect Practice Makes Perfect
Try to solve more and more problems. The best competitors weren't built in a day.
When practicing, try to simulate the contest environment. Eliminate distractions, work in a team of three if possible, share a single terminal with your team, use the same tools you'll be using at the contest, etc.
The contest is only 5 hours long. That's 15 man hours and 5 computer hours. So try to solve problems individually to get the most out of those 15 man hours. Computer time is very limited, so it should only be used for typing. Do not debug on the computer, print out the code instead and then switch seats with someone who needs the computer.
Snippets taken from "Art of Programming Contest" and "Competitive programming".