Computing has come a long way in the past few decades. Originally, programmers used to write code by themselves, using punch cards, and only later be allowed to run them on machines. The end result was a process of writing code and debugging as completely separated steps.

I never used punch cards (I’m not that old), but I had similar experiences. In high school, I didn’t own a PC, but I had about 2 hours of lab time per week. I normally stretched that to 4 hours, but for a nerdy teenager with lots of programming ideas, that wasn’t enough time. This made me maximize the quality of the time I actually spent with the school’s computers: I would spend the whole week writing code on paper, and when I got to the computer lab, I could spend the whole time actually typing the code rather than thinking on what code to write, or debugging. I’d then run the program, print a list of the error messages I got, print the source for the whole program, take that home with me, and spend the next week debugging the code by hand, doing corrections, and writing new code for the next time I had access to the computers.

That is obviously a very alien concept today. We’re constantly writing code and running it to see if it works, and we get immediate feedback from our code writing tools so simple mistakes can be quickly fixed. In fact, if something takes more than a few seconds to compile it frustrates me to no end, and a slow environment – for example, API calls that time out – can drag my productivity to the ground just out of sheer impatience.

Recently, I started an experiment in doing something a little bit different.

I have a project that I’m doing at home using Unity, C#, and Visual Studio. Those are great tools, and the project is evolving well.

However, from time to time, I find myself having just a few minutes of free time (e.g. just before meetings), or conjuring some idea that I want to quickly implement in this project.

In these cases, rather than firing up Visual Studio and Unity to write the code out, I’ve started editing the project’s source files directly, with minimal feedback. That means opening the files in a simple text editor (Notepad++) and writing code with no regard for how (or even whether) it is running. Of course, I try to write something that I believe is correct, and that hopefully will run at once, but the interesting thing about this approach is that I don’t care about errors that much. I am not checking them, either via the (helpful) IDE checks or by running the code. I am writing code, not fixing it.

The result of this approach is a deeper concentration in what I’m writing, rather than how it’s running.

Of course, this approach requires a second step, which is getting home and actually testing the project. That means running my environment – Visual Studio and Unity – and fixing any errors that show up in what I tried to accomplish. These are typically plentiful; sometimes, really stupid syntax errors creep in too.

Still, it has been very interesting seeing how much can be accomplished with this system. By keeping my focus on writing code only, it’s easier to do it in bursts of a few minutes at a time, as if I’m writing the blueprint of something and delegating the responsibility of testing and getting it to actually run to someone else. It also allows me to spend time dedicated to testing and fixing errors later, so I don’t have to constantly switch between different frames of mind: writing new code and testing it.

I don’t have any valid data points here. This is something I just started. Still, it’s something I definitely recommend other people try, as it’s giving me a new perspective on code writing and debugging.