Reading the post again, it seems to me it isn't about raw speed in producing a finished product; it's about the ability to explore a problem space by writing small throw-away trials, before you know how the result should look. Physical speed is just one part of this; I'd say it's really about fluency. Do you use code as a medium for thought and expression, or do you have a separate step where you translate your ideas into code from some other form?
This is a real distinction I see even in experienced developers, and in that case I think it's more a matter of habit and practice, rather than skill. Some of my co-workers have an ingrained habit of sitting down at a REPL and trying out several ways of doing things, whenever they're thinking about a problem. Others have apparently never tried this way of working, even though they are probably quite capable of it.
Yes! That is the kind of speed and skill to which I was referring. The ability to use code as a medium for thought and exploration rather than just viewing it as a final product.
Maybe I'm one of the slow coders, but for sizable problems, I find that thinking about the problem on paper speeds things up greatly: I don't waste a bunch of time re-writing my half-written class as I discover it's not what I want. (Not writing in C++ helps) I'm thinking of things that require a few classes here, rather than a large algorithm.
This is a real distinction I see even in experienced developers, and in that case I think it's more a matter of habit and practice, rather than skill. Some of my co-workers have an ingrained habit of sitting down at a REPL and trying out several ways of doing things, whenever they're thinking about a problem. Others have apparently never tried this way of working, even though they are probably quite capable of it.