Dan Newcome, blog

I'm bringing cyber back

The value of free coding

with 2 comments

Climbers on "Valkyrie" at The Roache...
Image via Wikipedia

In a time where nearly every mainstream development environment has the benefit of IDE support including source-level debugging, auto completion and even incremental compilation as we type, I think that there is still value in stripping things down to just a text editor and a compiler. I have met developers who have been of the anti-IDE camp through-and-through, but the idea that I’m putting forward here is not that IDEs be avoided, but that in the process of cementing new programming knowledge, there is value in doing it `without ropes’.

When rock climbers go without equipment to aid their ascent, it is called free climbing. In this spirit, I’m going to refer to coding without extended tool support `free coding’. In free climbing, for safety, many climbers still use ropes and harnesses but they are never used to aid the actual ascent — only to prevent catastrophe in the event of a fall. Likewise, in free coding we still have some tools that keep us from falling: the compiler as well as language support for stack traces and debugging statements.

I’m not going to go as far as Charles Petzold and claim that advanced tool support is rotting our minds, but I am suggesting that by not forgoing the aforementioned occasionally, we are denying ourselves the opportunity to reflect contextually about the code that we are writing. Instead of pounding away immediately on the keyboard, hoping that Intellisense will know what to do next, we can pause and think for a moment, or perhaps consult the documentation for insight.

One of the main advantages to free coding occasionally is that we can get over the initial panic of not knowing exactly what to do next. I recently interviewed for a job where the first thing that they had me do was to code some simple algorithms in a text editor, without even a compiler to check the programs. Even though the programs were simple, I still had a healthy dose of insecurity about what I was entering into the text editor! I credit that I was able to perform well in this interview to my occasional free coding experiences.

There is another aspect of free coding that I will call `free designing’ which is to approach the problem without referring to prior solutions. I’ll leave this one for another blog post, but I think you can see where I’m headed with it: that others’ solutions can become anchors in much the way that a salesperson’s starting offer anchors a negotiation. Everything is wide open before the anchor drops, and it is valuable to see where your own solution lands in relation to others’. It is the comparison of the actual vs. expected that provides a huge opportunity for growth and understanding.

Reblog this post [with Zemanta]
About these ads

Written by newcome

March 22, 2010 at 11:47 am

Posted in Uncategorized

2 Responses

Subscribe to comments with RSS.

  1. In case of dynamically typed languages the IDE support tends to be a bit poorer (obviously, d’oh :) ). Of course proper IDE helps even a little bit with its visual aids.

    In a sense when writing code in this sort of environment, you start out with something really vague, pretty much pseudocode in case you are using Python, and constraint it to be your solution. I tend to think about statically typed languages in the opposite way. First you overspec a bit and then aim for generalization.

    Juho Vepsäläinen

    March 23, 2010 at 1:19 am

  2. This is how I first learned programming at Uni (emacs, command line FORTRAN compiler – and no I’m not that old, I just studied physics!) and it is what I do every time I meet a new language.

    Syntax highlighting is v useful but further than that is always a bit much for me – yes you can write domain specific code (like your IAbstractFactoryInterface implementation) insanely fast, but if you need to write a new component to the application rather than just patching it it helps to start with a programmer’s “blank sheet of paper”; a buffer and a terminal.

    As an alternative to project Euler every time you need to get to grips with syntax rules, just sit down for an hour and write some simple command line tools using only for example gedit, gcc and a web browser on the documentation pages; you’ll see how freeing it is.

    tehwalrus

    March 23, 2010 at 8:20 am


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: