Hammock-driven Development

Posted on Feb 11, 2015

When I moved to Nepal in August, I started working for Ona as a Data Scientist. The team besides me is in Kenya and the US, so I have been working remotely. I hadn’t coded full-time since all the way back in 2008, but it has been fun going back into full-time programming.

One of the things I really like is that I’m focused on one thing at Ona. I make the data views / visualizations for our upcoming Ona product awesome. And that’s it! One area of improvement I had identified for myself last year was to not work on too many things at once, so the focus has been enjoyable.

Part of what I work on: map views for visualizing survey data. Screenshot here is from a dataset collected by the Kathmandu Living Labs, also available on OSM.org, about Brick Kilns in the Kathmandu valley.

Another enjoyable aspect of the job is that we use Clojure (well, Clojurescript and Om on the client-side [1]). All of these base products feel extremely well thought out, and are a pleasure to work with, especially for a functional programming nerd like me. But beyond that, the clojure(script) community has a pretty interesting philosophy and attitude. I’ll call it “move thoughtfully and fix things.”

Rich Hickey, the founder of Clojure, for example, has given a talk on Hammock Driven development. He says: don’t just rush in and start programming when you have a tough problem; tough problems are rarely solved in front of a keyboard. Sit with the problem in a hammock instead, and think through the problem. Solve it in your mind first, and test little ideas as prototypes, and sit on the computer only when you have designed the solution to the problem. This is my own simplification (watch the video for Rich’s version), but I think makes rough sense of the philosophy of hammock-driven development.

In today’s tech world of rush-rush development, this is a pleasant attitude in many ways. You don’t always need to work with the next-best thing; you can think about your problem and use the right tools and the right approaches to solve the problem.

It has fit well with my own work. I have been working remotely on a product that is yet to be publicly launched [2]. I have a lot of time to think about how to implement things before I actually jump into the implementation. Even for day-to-day issue solutions, I often use pen and paper to think through my solutions, or just write out my approach in prose before I tackle the problem with code. And over the last six months, the process has felt good: when I go back and touch parts of the codebase I wrote when I just joined, I don’t have to cringe my way through the revision!

Its a small thing: just thinking about solving the problem before sitting down to solve it. But I find it easy to forget, so the image of sitting in a hammock is a nice reminder.

Working from a hammock in Kenya.

Working from a hammock in Kenya. Sadly, this is not my everyday office.

[1] – I will likely be leading a Clojurescript and Om class in Kathmandu in March and April. If you want to become a better front-end developer, you should take the course! Send me an email at FIRST_NAME.LAST_NAME at gmail.
[2] – I originally wrote this post in December. By now, we have had some soft launches. The public launch is coming soon!