First, in the context of CS1, in my experience, the assignments just aren't long enough that speed writing code matters. 20-50 lines of C just isn't that much typing.
Second, in the world of real work, the hard problems rarely boil down to how fast you can get the thoughts out of your head, through the keyboard, and into the computer. I often spend hours or even days pouring over existing code and in the end change a single line of code. If I just started typing right away, I might fix the immediate problem faster, but there's a strong chance I'd end up with a larger diff that makes the code base worse and possibly introduces new bugs and corner cases.
I may be misinterpreting the author; perhaps by "code" he is referring to the full analysis, design, and implementation process, in which case I suppose it is inarguable that a good developer should do this fast (or faster than a poor developer). To a degree he seems to be saying, "start prototyping right away", which is also valuable at times. But still, in either case, what seems odd is the idea that CS1 students ought to already have the skills of an experienced developer. Of course they don't; they're beginning students and the job of the teacher is to guide them to these skills. Perhaps what would be truly helpful here is suggestions of how to improve the curriculum or pedagogy to help students gain these abilities more quickly.
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.
I think he was referring to the students difficulty in "expressing" themselves in code. In the same fashion non-native speakers have a hard time expressing ideas in a foreign language.
For example, I know I want to ask for another beer but composing the sentence along with all the right grammars is hard for me in Spanish. Similarly, to a novice programmer she may know she wants a loop but writing out the correct syntax is simply difficult for her.
You're right this type of coding doesn't work well in maintenance. However, when exploring a problem, fast coding is phenomenal. Once I discovered I could write code quick enough to do experiments, and that the whole iteration took less time than reasoning out, planning, doing back of the napkin style calculations, and still maybe getting it wrong, I moved to exploratory programming. This is where fast coding shines. Further, a lot of infrastructure can be built up this way, helper functions, I/O frameworks, etc can get massaged into a good solution.
At the end, there is still refactoring, and maintenance (particularly by people not intimately familiar w/ the codebae) may need some more thought, but the initial build... fast is good.
First, in the context of CS1, in my experience, the assignments just aren't long enough that speed writing code matters. 20-50 lines of C just isn't that much typing.
Second, in the world of real work, the hard problems rarely boil down to how fast you can get the thoughts out of your head, through the keyboard, and into the computer. I often spend hours or even days pouring over existing code and in the end change a single line of code. If I just started typing right away, I might fix the immediate problem faster, but there's a strong chance I'd end up with a larger diff that makes the code base worse and possibly introduces new bugs and corner cases.
I may be misinterpreting the author; perhaps by "code" he is referring to the full analysis, design, and implementation process, in which case I suppose it is inarguable that a good developer should do this fast (or faster than a poor developer). To a degree he seems to be saying, "start prototyping right away", which is also valuable at times. But still, in either case, what seems odd is the idea that CS1 students ought to already have the skills of an experienced developer. Of course they don't; they're beginning students and the job of the teacher is to guide them to these skills. Perhaps what would be truly helpful here is suggestions of how to improve the curriculum or pedagogy to help students gain these abilities more quickly.