Tomorrow I’m heading out to The Orange Conference. While this does mean I’ll be going to Atlanta were the weather is much warmer, it also means I’ll be spending about four hours on an airplane. On my most recent flight I had a little epiphany: programming on an airplane is a lot of fun. While your intuition leads you to believe that without wifi it’s impossible to get anything done, I’ve discovered that in reality the opposite is true. Airplanes shelter you from distractions, making you more productive.

I stumbled upon this by accident. Prior to my last flight I was learning more about Git, and solidifying my Git skills. The day before my flight I was troubleshooting a problem with a script I made to convert audio recordings from wav to MP3. Eventually, I figured out that it was a problem with a Ruby gem I use. There was a bug where it wasn’t properly handling the case when converting a wave file with a zero second duration. I was determined to fix this problem myself, and submit my very first Github pull request.

I was starting to get very excited and pumped that I could fix the problem. I had the project’s Git repository checked out on my laptop and I was going over the code, isolating the problem and working out a solution. I’d created a branch to write my changes. As I rushed to fix my code I realized I didn’t have much time before I had to board my flight. So I shut my laptop and got up to board the plane. But after we were in the air and the seatbelt sign shut off, I opened my laptop and started looking at the code again. By the time the plane had landed I had the issue fix, plus all the tests I needed to verify the solution worked. Since I was using Git, while I was in the air I had been committing all of my changes to my local repository as I made them. So when I had wifi again at the airport terminal, all I had to do was run git push origin my_branch and all of my changes were sent to Github.

This whole experience felt good. Not only did I make my first Github pull request, but I was also very productive. It made me think about the value of a distributed, offline workflow.

The Value of a Distributed Workflow

In an interview for TED, Linus Torvalds comments about how he needed a distributed workflow, and that is why he created Git. Distributed means everyone can have their own copy of the code and use their own repository to commit changes. The idea of having your own local copy of the code is something I didn’t realize until now can you make you very productive as a programmer. If I can do all of my work offline, without a connection to the Internet, I can be much more productive. Then if there’s an easy way to share, or ship that work I did offline, this keeps the workflow sustainable. Distributed workflows also mean I’m not dependent on others completing their work, I can do my work and pull in their changes when their tasks are complete.

In order for this to work I need to have everything I need on my laptop. In my line of work, one of the common issues that I face is often I need a remote server in order to work on a project. I’ve solved this problem by using a tool like Vagrant to run a Linux server instance in a virtual machine on my laptop. An added benefit is that these instances are easily reproducible, so when it comes to deploying my work to production it’s usually a matter of running a few scripts.

So now with this distributed an offline workflow, not only can I work at 25,000 feet, I can also work in the park on a nice day. I’m no longer restrained to my desk where their are tones of distractions, but I can work anywhere that’s comfortable. This is also my reasoning for switching to Jekyll. It brings the same distributed and offline workflow to my blogging. Now before I head out tomorrow on my flight I’ll clone all of the Git repositories that interest me, as well as download all of the documentation I may need for reference.

Let’s see what I can create in four hours.