itrat – iterat – iterate!

Recently whilst helping students in the labs I found one student who was compiling directly onto a memory stick.

This is bad for a three reasons.

One is that memory sticks have a “life” in terms of the number of times you can write to them, and compiling a project in visual studio does a lot of writing, so the student was shortening the life of his memory stick. Additionally, the memory stick will likely not be backed up in the same way that a students networked storage.

Reason number two is that there is no real reason for a student to be using a memory stick to move code around. All our students have a source code repository which will look after versioning for them as well as providing access to their code anywhere that there is a network connection.

The third reason is writing to a memory stick takes significantly longer that writing to the local hard disk, which meant that he was wasting time waiting for his code to compile.

Compiling: time waiting is time wasted

Waiting for code to compile is waste of time. You should do anything that you can to minimize it, because the more iterations you can get into any allocated amount of time the better the result will be. This is true in industry, where they try to make their tool chain as efficient and intuitive as possible to get more iterations out of their workers. Some game engines use scripting languages like Lua to control game objects. That’s because even though it looks like code, scripts are data. A change in a script doesn’t require any code to be compiled. That means that you can make and test more changes to scripts in a day than you can changes to code.

I used to have this T-shirt, but then my ego outgrew it 😉

Learning is no different. There are lots of competing models of learning, but probably the most prevalent is Kolb’s learning cycle, which involves some thinking, some experimentation, some observation and some reflection. In the context of programming every hit of the compile button begins a trip round Kolb’s learning cycle. Each time you make a change, observe the results and modify or verify your mental model of the problem you’ve done some learning. The faster you can iterate the faster you can learn.