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.