What Learning to Sail Taught Me About Building Software

This summer, a small crew from Atomic decided to try something a bit out of our comfort zone…sailing. It turned out to be a lot of work–and a lot of fun! While captaining a sailboat may seem disconnected from the software development work I do at Atomic, I’ve noticed a connection between the two that has made me a better software developer.

A Quick Decision Is Better Than No Decision

When sailing, it’s often necessary to make decisions without taking too long to think. Conditions can change rapidly on a boat, and you have to be ready to react. I’m predisposed to want to collect as much information as possible before acting and have become trapped in analysis before. Learning to sail showed me that when acting is time-sensitive, it’s better to make a decision. Once you act, you can see the result and course-correct as you go. At least you’re still moving forward–or close to forward.

This is in line with Agile methodologies for software development. The Agile Manifesto encourages you to value “responding to change over following a plan.” To me, this means accepting that some decisions and plans I make will be wrong. But that’s okay, as long as I make a conscious decision and am open to correcting it later when I know more information.

Defining Boundaries

In sailing

When I first began to sail, I was afraid to sail in any direction that wasn’t exactly perpendicular to the direction of the wind. When you’re perpendicular to the wind, there is a minimal risk that the wind will change directions relative to sail. As I turned upwind or downwind and got closer to sailing parallel to the wind, I was afraid of what would happen. My path was changing.

In sailing, there is a literal boundary of not being able to sail “into the wind.” In my effort to avoid that “no-go zone,” I was overcompensating and not using the full range of directions where I could sail.

One day, I was out with a more experienced sailor, and we talked about how to sail near the “no-go zone” safely. It turns out that when the boat gets near this position, there are natural indicators that are easy to see (when you know what to look for). I decided to test it out by steering the boat close to where I thought the boundary was. None of the indicators that I now knew to look for were manifesting. I turned more. And more. Finally, way beyond where I had anticipated, I observed the warning signs. Now I knew exactly how far I could push it. My range had expanded, simply by investigating and questioning what the boundary was.

And in software

This may sound far-fetched, but the sailing mentality has helped me push through tough spots in software projects. Before sailing, I created artificial boundaries for myself and my projects.

Suppose that a user story is not ready for development because some of the dependencies (which are out of the team’s control) are not complete. The artificial boundary is that the team needs the dependent work to be done before they can continue their work. One solution is to allow the team to mock out this unmet dependency. Defining the boundary of responsibility can allow the team to see how far they can continue without giving in to an artificial, unspecified boundary.


Learning to sail pushed me out of my comfort zone and helped me learn a lot about myself and working under pressure. I’m glad that I did it, and I think it made me a better, more confident consultant. What activities outside of the office have helped you grow professionally?