Lessons from teaching CS 1: Code fast

From that viewpoint, I'm wondering about what the minimal set of language features you need to have committed to memory to enable you to code fast. These are the pieces of code that without which you can't make even a passing claim of competency in a language. I'm thinking about the crib sheet of functions/definitions/language features you have to have ready to go in your toolbox so you can code fast. It's the stuff you'd want candidates to demonstrate knowledge of in an interview as well and be able to apply at least in conversation to a new problem.

I'm interested in figuring this out for a multitude of reasons, not least of which is retention of knowledge related. Years ago, I hacked in C for performance reasons in the domain I was working in Lots of pointer junk, tiling of data (interleaving of row and column data to blow up memory bottlenecks), and a healthy dose of bit twiddling to make it all work nicely. I realized not too long ago that most of these skills had faded due to lack of use.

I'm playing some with spaced repetition software for memory training (think SuperMemo and Mnemosyne) and thinking about plugging in those pieces of programming languages that you have to be ready to throw out to code fast in a language. I'm just testing for now, but I think I might even try throwing something like the question/answer pieces from The Little Lisper in there for fun. Kind of a daily brain teaser.

Since I spend most of my time at work hacking SQL, it's pretty easy for me to stay fresh and also identify the minimum set of concepts and ideas you need to even think you can write halfway decent SQL: SELECT,INSERT,UPDATE,DELETE,JOINS - all types, ansi sql functions - including analytic functions, nulls, subqueries, boolean logic,etc. It's a non-trivial set of stuff to have in your head so you can think correctly about problems.

To make it even more fun, you need to have a meta-sense of when to apply what tools and languages? When do you want a RDBMS versus rolling out hadoop? What data do you want to send to your web app so your users can muck around with it - which means understanding enough Javascript to be able to provide them with some intuitive tools to munge data there.

I'm pushing towards the idea of internalizing not only the specifics of a language, but the idea of what programming language and tool fits a problem best at any given time.

Software folks get all the best toys to think about . . .

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.

I remember that I didn't code fast in my CS1 classes. The reason was because it was scary. The compiler and all syntax errors seemed cryptic.

Now one of the goals of the class should be to make students not afraid of trying things out. To get there they have to understand the tools and the basics.

Having a good langauge + compiler/interpreter definetly helps. For example, Python's REPL is a way to try things fast. Especially when used with something like ipython, where you can explore an object's methods as you type.

C/C++ and gcc is not so great in this respect. You get a segementation fault, and the next thing you do is pepper code with print statements or fire up gdb. Now they have another problem to solve -- how to use gdb. Very useful, but perhaps not for someone in CS1, unless CS1 as a filter and its purpose is to scare everyone away.