Taking the quickest route
Having recently moved to Auckland, I’m currently walking to work each day. Being new to the area, I rely heavily on Google Maps to show me the way.
Google Maps is amazing - it show’s me the optimal route to my office with a few alternate routes and how each alternate route will delay my estimated time of arrival.
For the first few day’s I took the optimal route - at the time I thought to myself why would I ever choose take a longer route when I know there is a quicker one - that would seem absurd!
After a few day’s I realized that Google Maps was optimising for one thing - the quickest way to my destination. Did I really want to quickest way to my destination each time?
Taking the longer route
At first consideration the thought of taking an alternate route seemed ridiculous - I knew the quickest way, it would be stupid to knowingly take a slower route. However, on thinking about it further, I realized that there were learning opportunities I was missing out on by always taking the same old route.
For instance, I had only learnt very specific streets in Auckland, should I ever need to get to another place in the city I would be lacking on ‘local’ knowledge.
Also, I didn’t just walk to get to the office, intrinsically I wanted to see different buildings and places - adding a minute or two to my walk would give me a great opportunity to explore the city.
So now I mix it up. Some day’s I take the quickest route, other days I intentionally take a longer route to explore new areas - I’ve even reached the point when sometimes I keep Google Maps turned off.
How this relates to software development
What has this got to do with software development?
“Sometimes we think we know the quickest route to delivering a feature. When we are in this situation, do we ever explore other approaches that while taking longer may have other learnings available?”
I think the challenge many of us face is that we revert to the quickest route to the solution, this seems to be part of human nature. The reality is without experimentation and trying approaches that may seem unfamiliar or ‘longer’ we are missing out on great learning opportunities.
For instance, off the top of my head things I have learnt about that I didn’t know about before I tried something new included:
- Pair Programming
- Mob Programming
- Code Retreats
- Distributed Version Control
- Vim
And so the list could go on…
Next time you have the opportunity to “try” different things, try it - even if the value is not obviously clear - this is often called the unkown unkown opportunities. You never know, you may learn something you never realized was useful until you learnt it - and often that leads to the biggest breakthroughs!
