Lessons from teaching CS 1: Code fast
imprompt.us
Lessons from teaching CS 1: Code fast
1–10 of 40 posts
Re: Lessons from teaching CS 1: Code fast
#2It's not just prom teaching CS1, it's also from teaching algorithms and OS and every other course I've taught. A willingness and ability to code fast and fail fast is universally applicable and useful.
Re: Lessons from teaching CS 1: Code fast
#3OP's title is a little too abridged for me. "Code fast" could mean too many different things. Many programmers whose code I maintain look like they adhered to the school of "Don't think, code fast."
I would prefer: "Code something small fast."
What's "something small"? It could be a just the core of what you propose with no features or embellishments. It could be a subset of the problem at hand. It could be one case of a general problem. It could even be a guess.
The point is that if it's small enough, you can code it fast and test it right away. If it's just right, you can build upon it. If not, you can quickly amend it and retest.
Many huge applications have started out as a tiny core with less than 50 lines of code, probably written by one person in less than an hour. I suspect that's the idea OP was getting at.
Re: Lessons from teaching CS 1: Code fast
#4OP's title is a little too abridged for me. "Code fast" could mean too many different things. Many programmers whose code I maintain look like they adhered to the school of "Don't think, code fast." I would prefer: "Code something small fast." What's "something small"? It could be a just the core of what you propose with no features or embellishments. It could be a subset of the problem at hand. It could be one case…
What I was getting at was that increased speed in coding has nonlinear effects n your time-to-solution and that students should code sooner --- before they have the solution in hand --- rather than waiting until they think they know the right answer.
Coding for classes should be done quickly and exploratively. But because students either can't code fast or won't code before they have the whole solution mapped out, this (measurably better) solution technique is unavailable to them.
Re: Lessons from teaching CS 1: Code fast
#5I keep a sandbox for myself open at all times, particularly when I'm working on a large project. I whip out a solution for a micro case, test it, refine it, then implement it. I hate it when people check in their not quite fully-baked solutions, and let QA test their proof-of-concept for them.
Re: Lessons from teaching CS 1: Code fast
#6I agree... personally I think you should not be allowed to code unless you can type somewhere around 60-70 wpm. It is only with extreme mental effort that I can watch someone hunt-and-peck out 5 lines of code fiddling with their mouse and looking for the "n" key or the ";".
There should be a minimal period of time between when the code appears in your head and you see it expressed on a screen. If you can't type that fast, write it down, if you can't write it down, use a voice recorder.
I'm serious, if you only type 20 wpm, you are like an soccer player who can't run. Sure, running isn't the objective of soccer, but it sure as hell is an important skill to be proficient.
Re: Lessons from teaching CS 1: Code fast
#7I find myself disagreeing on two fronts here:
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.
Re: Lessons from teaching CS 1: Code fast
#8I find myself disagreeing on two fronts here: 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 pour…
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.
Re: Lessons from teaching CS 1: Code fast
#9Seems to be another variation of "he who has the fastest iteration times wins".
Edit: As well as fail quickly, fail cheaply.
Re: Lessons from teaching CS 1: Code fast
#10I think what the author means is that students have trouble breaking down large problems into small ones, and quickly testing out solutions to these small problems. As a student, I notice that people I know have some difficulty doing this.