In high school, I did the USACO programming competition. I was one of four or five high school students chosen to represent the USA at the IOI (international hi

In high school, I did the USACO programming competition. I was one of four or five high school students chosen to represent the USA at the IOI (international high-school programming competition, akin to the math olympiad). In college, I did the ACM collegiate programming competitions, and we placed eighth in the world. These competitions are useful to me now when I look for jobs, because I have a Ph.D., and people assume that Ph.D.'s can't code. (This is actually, sadly, true more often than you would expect.) So I can point to my programming contest experience to demonstrate my ability to quickly determine the correct algorithm and deliver correct, bug-free code under pressure. Additionally, in the ACM competitions, you get one terminal for three team members. The general strategy is that you code on paper when you don't have the terminal. At USACO training camp, we were did exercises coding on paper. In general, an undisciplined coding instinct is to bust out code quickly, favoring typing over thinking. This can lead to a lot of pain when you need to change things, or need to debug. Coding on paper encourages good design, by privileging thinking over typing. Coding on paper is very useful. I won't dwell on the job thing, but since a lot of job interviews involve coding on paper or on the whiteboard, it's a useful skill. The more important thing is that coding on paper enforces a certain programming disciplines, and teaches you to design things correctly the first time. By "correctly", I don't mean "comprehensively", but rather in such a way that if you do need to modify your code at a later date, or change your design in some way, that it doesn't involve a lot of pain.