| Two things: 1) The grammar and writing style has some problems with run on sentence fragments. Perhaps this is not the OP's main focus, but learning to code well is similar to learning to write well (in fact there was an article about this posted to HN a few days ago). 2) By focusing on the idea of 'the best' code, the OP implies some kind of fitness function, but is pretty vague about what that might be. The most obvious fitness function in this context would be that the code works and was written faster than anyone else. Why talk about best-practice and industry standards if your fitness function is speed of writing and correctness? Experienced programmers don't talk about the "best" code in general, but rather the best code for a given purpose. Code clarity, speed of execution, elegance, reuse, size in memory... these are all different fitness objectives that have various trade-offs... even saying "yeah, I want ALL of those!" implies trade-offs. It's like saying you want a D&D character with all max attributes... it doesn't work that way. But there's also a problem with this model of learning. The fastest coders are going to likely be the coders who already know what they are doing, or who work out cheesy ways to game the system. Likely, their incentive for playing will be showing off, not genuinely helping others learn. Meanwhile, coders who are learning will always be slower. Yes, they will see a lot of other possible solutions, but without critically understanding the differences between code examples, it all becomes a sea of noise. Stack Overflow is already like this in places -- many answers don't demonstrate an expert analysis of a problem, they simply devolve into: "I tried this", "I reinstalled", "Yeah, it works!", "I'm still having issues". Now, if bitlean's 'tail' in the game was a nice social community built around commenting and critiquing code AFTER it was written and judging its fitness for various stated purposes -- then I could see that really building a community of value for learning programming similar to the ways that we learn critical reasoning in writing courses by contributing to critique and discussion. 'Fast' has its purposes. For example, in Shamus Culhane's book "Animation: from Script to Screen", he talks about the advantages of sketching fast without critical interruption to maintain creative flow. He was adamant about not even erasing one wrong pencil line because it brought critical analysis into the process and disrupted the flow. However, after the sketches capture an idea, that work was always followed by extensive analysis and critique to see where ideas and execution could be improved. |