Orienteering is a sport in which you navigate terrain using only a map, compass, your legs, and your brain. The goal? Reach all control points as quickly as possible. The only thing you have is a map which looks like this:
Beyond physical endurance, it tests analytical thinking, planning, and risk management—skills that directly overlap with software development.
Doubt yourself (but not too much)
Confirmation bias can cost you a lot. Trying to confirm to yourself you’re on course can lead to costly backtracking. Critically compare the map to what you see around you. Like a tester who tries to break the software instead of confirming it works. But when overdone, this can make you second-guess every step and ultimately stop moving altogether. Verify you’re on track, then just shut up and run.
In software engineering, this represents keeping contact with stakeholders, having end-to-end tests, keeping the feedback loops short, validating often and course correcting. But there needs to be a balance. You can tell this has gone too far when people are just discussing things back and forth without making any forward movement.
Map is not the territory
As someone who loves to think and loves maps (and yes, I LOVE maps!), I sometimes lose myself overanalyzing them. Embarrassingly many times I got lost in the esoteric squiggles searching for the control point there instead of lifting my head to see it’s right in front of me.
When working on a software product, your head shouldn’t be buried only in Jira and IDE. Stop from time to time, look around, talk with the people. Get a sense of the real world that you’re building the product for.
By the way, the closer you’re to the destination, the more you should lean towards the territory in the “map vs territory” dichotomy. Delivering soon? Talk to the people, and forget what the ticket says.
Long shots are perfectly doable, they just consist of several shorter shots
In most tougher races there’s a pair of control points that are really distant from each other, I mean almost across the whole map. This point might sound trivial, but you can’t just go from A to B in that case. It’s too complex and you’d get lost. You need to first find a series of points on the map that get you gradually closer to the destination. Then come up with a detailed plan for getting to the first one. You’ll figure out the rest along the way. Swallow your pride and replan in case you mess up. “In battle, planning is essential, but plans are useless.”
In software, this directly maps to iterations. Big goals are achieved through a series of smaller wins. It’s enough to have a vague idea about them and how they’ll get you to your destination. You need a detailed plan for getting to the first one though. And be clear about how to recognize that you indeed got there. It’s strategy first (the overall plan), then tactics (how to get to the first point), and then execution (the “shut up and run” part).
Catching features
“Catching features” is a technical term that means an easily recognizable terrain feature that will tell you you’ve gone too far—for example, a major path or a valley right behind your destination point. Once you see it, you know you should stop and reevaluate.
It takes a certain self-awareness to realize your plan might not work and designate catching features proactively. In software, this relates to time-boxing (“Once we have wasted X hours on this let’s stop and reevaluate). Also, be clear about what adds value in this iteration and stop once you notice you’re just gold-plating or adding needless complexity. Techniques that help: planning the demo upfront (written in the ticket) or writing an acceptance test before you start implementation. Once you’re there, you’re done. Stop trying to be done-er.
Conclusion
Both software development and orienteering require a balance of strategy, tactics, and execution, along with a mix of humility and belief in your abilities. This mix of planning and adaptability is what makes both pursuits so challenging and rewarding. I learned that complexity can also be fun and I love to spot the connections between the disciplines.