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.
I occasionally do Topcoder SRM's and Marathon Matches.
It's partly for fun, partly to keep myself in practice since I don't feel my current job pushes me as hard intellectually. The pressure and problems are also good interview practice--though, as a caveat, I feel that some of the ways they structure problem inputs locks you into a certain way of thinking. Though, that might be my own fault and means I should just switch languages randomly during SRM practice to broaden my perspective.
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.