In my experience there are two kinds of programmers. Those who program (largely based upon practices they are told are good) and those who also really think about their own programming and try to develop their own paradigms in response to their own problems.

The latter tend to be, in the long run, far more productive than the former. However, this takes both motivation and it takes extra time between iterations to think about what problems you are having with development and how to solve them. Continuous iterations get in the way of it, but it isn't clear that the heavy engineering waterfall model gets people to do it either.

Sometimes you need some distance so you can come back and ask "is this good code? What can I do better?" Without distance, it is like editing your own essays.

After 10 years of coding professionally and over 20 years of programming experience, I find that that capacity, which is entirely independent of how many hours someone actually spends coding, is the best indication of how productive someone will be.

If I am ever hiring programmers, my questions won't be puzzle questions. They will be questions like "how do you decide what needs testing?" or "when and why do you comment your code?" Those questions are likely to tell me more about how much someone has thought about their own code experiences than whether they can solve a certain puzzle or not.