I disagree strongly with that.

First, in all programming helps you become a better programmer, just in the same way as playing the piano makes you a better piano player. Even if you already know how to play the piano, you still need to put in the hours to improve (or even to maintain your skills). The more you program, the more parts of the act become total routine that you don't have to pay any attention to.

Of course programming contests or challenges might not be the optimal thing to do to increase your programming skills. But the comparison isn't to programming something else, it's most likely to somebody wasting time by playing a video game, reading blog posts, watching TV, etc. If a contest acts as a extrinsic motivator for somebody to program something, how can that be a bad thing?

In my experience it's incredibly common for someone learning a new language to lose steam quickly due to not having anything to write. We'll always give the advice of just writing some program they need. But amazingly enough many people just don't think of the world like that. To them a well structured problem set is just what's needed. It'll allow them to learn the new language, and learn something else on the side.

But you're also making the assumption that a coding challenge can't teach you anything useful which is blatantly untrue. I learned a lot about writing efficient data structures for a certain class of problems during the Netflix Prize. Likewise for solving some of the harder ITA software puzzles. I'd known the theory of stack smashing attacks on a very vague level, but having to properly figure out how to do (microcorruption) it was a completely different thing, incredibly fun and helpful. Likewise the Matasano crypto challenges -- learning to crack badly applied crypto made me acutely aware of ways in which I've badly applied crypto in the past.

I'll admit that there's probably nothing of practical value to learn from e.g. doing high level Perl Golf.

"First, in all programming helps you become a better programmer, just in the same way as playing the piano makes you a better piano player."

I think it's a good comparison. Programming contest would be a very specific part of piano playing, like playing scales super fast. It's useful, but still a very small part of what it takes to making music.

I agree that doing these challenges helps you play the scales super fast. But I think the important segue to acknowledge is that the fastest pianists don't necessarily make the "best" pianists in terms of the quality of the compositions they're able to churn out. I'm saying that being a super fast pianist is not a necessary and not a sufficient condition to become a great pianist. Does it help? Sure it does! It helps to move up and down the scales and play rachmaninov for the evening's entertainment effortlessly, but at the end, it becomes one of many ingredients required to actually "make" good music.

The question is, is there a really good balance that we could engage in? What part of lives are best spent practicing heavily (and perhaps "composing" lesser music) and what's the best indicator to transition into a part where you're not practicing as heavily, but you're composing more music.

Or for those more fond of sport analogies, practicing 3-pointers over and over again. It's a very small part of the whole game and you need to excel at all the other skills required to be a great player. But I disagree with the blanket statement of OP that it doesn't make you a better player.

What I generally don't like in these kind of puzzles is that the task itself is given with some specific method or algorithm in mind (but you're not being told). i.e. to efficiently solve some particular task you have to use K-D tree; Some specific graph algorithm for another task; Another specific DP method and so on...

I find this quite boring.

Well, I'd make the statement that almost any kind of programming (unless incredibly repetitive or filled with bad practices) will make you a better programmer. At the very least, it should make that person a little bit more practiced in their language of choice. These types of challenges may also take you out of your comfort zone, introduce you to new languages / paradigms, and so on; these are all good things in general.

Are they the best way to make use of your spare time, or the best way to improve as a programmer? That's a completely different question, I guess.

> programming challenges do not help you become a better programmer

Depends on the definition of "better". If fluency and coding speed in a (new) programming language, and knowledge/experience with algorithms and their efficiency are part of that metric, then programming challenges do help becoming a better programmer... or at least: a better coder. No, the challenges do not address the whole required skill set of a good programmer.

BTW, the most important reason that Project Euler is independent of programming languages is that the answer to a PE-problem is a number. It doesn't care or evaluate how you came up with that number. Some problems might be solved with some mathematical formulas, and possibly a piece of paper and a pencil. (Or a smart query towards Wolfram Alpha, for wider definitions on "how to solve a problem".)

Rosalind also supports every programming language (for much the same reason that Euler does -- you run the code on the provided sample data and give back the result.)

2) GCJ supports EVERY programming language (unlike all others I know of except Project Euler)

Does it support JavaScript?

Interestingly enough I did about 50 problems of PE in Javascript (no libraries except my own custom written helper functions) to see how far I could get. Output was simply writing to the browser.

I agree, these coding challenges only ever really come up in interviews and interviewers will grade you accordingly on whether you can solve them. The truth of the matter is, these challenges are your resume, not the experience you have.

It's actually kind of an interesting thought to consider. If programming challenges aren't good at helping you become a better programmer are they good for determining if you're a good programmer? These kinds of sites pop up because of how the engineering interview is conducted. I presume that the more engineers study to become better at these challenges the less effective these challenges will be at finding good engineers.

For example, maybe you get someone who can find the right data structure or algorithm to solve puzzles, but will that same person understand physical limitations of computer hardware and networks? Will they know how operating systems and CPUs work? Stuff like CPU interrupts, processes, memory management are important. The crafting of software is important, being able to design maintainable architecture, understand important design patterns, cache invalidation, testing, different programming paradigms.

At the other end of the spectrum of what I think programming interviews do wrong is test reference knowledge. Stuff you can look up online by Googling. Maybe you can gauge some amount of experience by familiarity of having been exposed to enough of some type of thing to have ended up memorizing a lot of documentation, but I would say not knowing documentation that is easily searchable online is not a good indicator of a bad candidate.

In my experience bad hires have tended to turn out to be bad for reasons orthogonal to programming challenges and reference knowledge:

#1 people with a bad attitude.

This can take several forms: mean to others is the first one. But bad attitude can also mean someone who isn't mean, but someone with a bad work ethic, calls in sick all the time, asks too much of others. Someone who is lazy or unwilling to learn from past mistakes and repeatedly breaks production code. Someone who doesn't actually like to program but does it for the paycheck. Someone who goes off and codes things by themselves without input from others and creates a lot of work for others. Someone who is politically motivated in the workplace and strives to make themselves look better at the expense of others. Someone who is insensitive to women. Someone who is insensitive to diversity. Problems with integrity.

Only twice have I come across an individual who was a good person with a good attitude, worked hard, but wrote shit code. Both of these people had a masters degree in computer science and were excellent at interview challenges. They didn't understand the code base, they wrote things that just didn't work. They wrote just really sloppy, bad logic that you didn't have to look through much to realize it wouldn't work. One guy ended up on a performance improvement plan and then quit under pressure, and the other sort of just fell in as a probably permanent junior programmer who needed supervision, but with help ended up adding value. His life though is one of very basic implementation of other people's designs. I don't know if he ever got better.

My point is, the modern programming interview fails in many ways. Still even I use it. There just isn't enough time in an interview to figure out if a person will be good and enough. I also think 3 or 4 rounds of phone interviews and in person is too stressful and time consuming and anxiety causing for a candidate, and not worth it.

The best hires have always been in network hires. Hiring someone based on someone else you knew. Those kinds of hires didn't even have formal interviews sometimes, you just knew they were good based on reputation. This also has problems, because maybe you just aren't in a network so you can't get hired this way, or maybe you've exhausted the network available to you and your employees when trying to hire.

Anyway, these programming sites are pretty fun. So I like it.