Students simply cannot code fast enough to express themselves. When confronted with a problem, particularly a small algorithms problem, my first instinct is to write a little snippet of code for every solution I dream up. I can do this, because I write code very quickly.
My students can’t. They simply do not have the practice at expressing themselves rapidly using these thinking machines which surround us, which means that any and all of their programs are arduous constructions which must be carefully planned in advance because the cost of doing it wrong is many hours wasted. This means that the subparts of homeworks where I ask them to write a program are arduous painful things, because they do not have the speed required to make the problems quick.
To make this make a little more sense, what I am claiming here is not just that if you code faster, you will get your solution written faster. I am claiming if you code faster, you will get your solution done MUCH faster. The speedup is greater than linear.
To a first approximation, I think this is because when you can write code rapidly and grow a big solution up from a small one, then you can develop your solutions using some single-person approximation of agile techniques. When you code slowly, the penalty for wrong thinking is extreme, which in turn means that you tend towards a single-person version of waterfall techniques, with lots of big design up front. This slows students down, because it is highly likely that their initial solution are wrong, and so the sooner they can implement those solutions and see the wrongness, the better off they will be.
Being able to code quickly allows you to code fearlessly, because wasted code is wasted minutes, rather than wasted hours. And wasting minutes is not just quantitatively different from wasting hours, but is qualitatively different. Wasting minutes is part of the standard accepted practice of problem solving, but wasting hours is a major error.
