What I learnt from coding offline

During the last weeks, I’ve been writing a lot of code while commuting.

Since I was working on an application that uses Facebook’s and Amazon’s APIs and I was working offline, I often found myself unable to test the code I was writing against live data.

I must confess I struggled at the beginning.

I had no chance to try out my small application while I was working on it and, generally, I had to code during 1-hour trips, waiting until I got to work/home to see whether everything was performing as expected.

The outcome? I was surprisingly productive. And I’m sure it was not just because of the absence of common distraction sources (IMs, Email, Twitter and the like).

So, what made the difference? Here are some of the insights I got from the experience.

Write shorter and cleaner code & write for reuse: two long-time classics, they are even more important in this kind of scenario. Minimizing code means you have less stuff that can break, while maximizing reuse means you can rely on a lot of tested and stable code, focusing on the feature you are building.

Think before coding anything: getting it right the first time is significantly more effective than going through multiple rounds of debugging. While I was used to this when I started this career, this habit was getting weaker over time.

Working with fast development machines and powerful IDEs was slowly changing my approach to an iteration of the same sequence: code → test → debug. Working offline forced me to keep a clear picture of what I was trying to accomplish and think thoroughly before writing anything.

Write more accurate unit tests: I was forced to think about everything that could possibly go wrong with my code. Unit tests were the only significant way to test my code while I had no access to live data.

Be feature oriented (this is my favourite): since I had to work for a while without being able to perform a significant integration test, I tried to pack features into 1-hour slots, so that I could test one single feature each time I got online again. Also, if my app started misbehaving, it was easy to track the culprit.

Switch to a peer to peer SCM (mercurial, at the time): this granted me the possibility to bring the entire project history with me, commit local changes (again, grouped by feature) while still allowing me to sync my source code across my different machines.

What then?

As usual, I wouldn’t learn so much if I didn’t have so much to learn. While none of these points is certainly new by itself, what’s relevant to me is that this kind of experience taught me a lot of good habits and strengthened some others all in the same time. Not only I learned to cope with the disadvantage of being offline, but I even got better as a consequence.

UPDATE: a friend pointed out to this excellent post by Robin Wilson which expresses a similar opinion. If you liked this post, you might be interested in his one as well.