Why Programming is Like Fly Fishing

Image By Curtis Fry

Image By Curtis Fry

And why would you care?  To be honest, I’m not really sure.  But it’s fun to think about parallel lessons that can be learned from two dissimilar things, right?  Contrary to how Hollywood portrays programmers (think dark rooms, Mountain Dew, weird glasses, frazzled hair), some of us do like to get out from behind our computers and have a little fun in the out of doors (ok, I’ll concede the Mountain Dew).   During one of my recent trips to the river, I realized that I could become a better programmer if I simply applied some of my fly fishing principles to programming.  …Ok, that may be a stretch.  But it would be great if I could convince my employer that it was true.  Maybe I could get paid for a day on the water :).

Match The Hatch

Most people don’t ponder the intellectual capacity of a fish, but they are actually pretty clever.  They are wise to our schemes of tricking them into taking a bite of a tasty morsel attached to a line, pulling them to shore, flipping them into a net, taking their picture, applying the Nashville effect, and posting it to Instagram.  But most of the bigger fish have been around long enough to get big for a reason.  So one of the first principles of fly fishing is to match the hatch.  This means that you have to be aware of what bugs the fish are currently snacking on, and use a fly that most resembles that bug.  For example, if you use a fly resembling a grasshopper in early spring, you’ll likely get a lot of laughs from your fellow fisherman, and probably a few from the fish as well.  Grasshoppers generally don’t show up until late summer, and the fish know it.  So you have to be pretty selective in choosing your flies.  You must consider the fish’s appetite, time of year, time of day, method of presentation, water temperature, what bugs are currently hatching, etc., etc.

Programming can be much the same.  I work on custom software applications that are as varied as the day is long.  The success of a project starts at the very beginning, starting with choosing the appropriate application framework.  Some customers have specific requirements, and some don’t.  We have a standard app stack that we use when there are no compelling factors specifying otherwise.  But it seems like more often than not, we end up deviating from the standard stack because some other framework is a better fit for the application.  We have to consider server architecture, preferred programming language, tools and libraries included in the framework that will speed development time.  The right choice can make a big difference in the outcome of a project.

Avoid Tangles

Tangles are the worst.  There’s nothing more frustrating than driving a couple hours to the river, getting all geared up, casting a couple times, only to spend the next hour untangling a giant rat’s nest of line.  For beginning fisherman, this can be a particular problem as their casting technique hasn’t been refined enough to consistently avoid knots.  Knots are a lot easier to create than you think, and even a slight misstep in your cast can lead to a huge mess.  The best thing you can do to avoid tangles is to immediately stop casting the minute you notice anything funny, and reset your line.  A lot of us have the tendency to keep casting through it and hope the knots magically disappear, but they never do.  They only get worse.

Sometimes programming goes the same way.  When I set out to solve a problem in code, I’ll come up with a proposed solution, taking into account all the data I have at the time.  The excitement builds as I get to the point of being able to test my implementation for the first time, only to find that it’s a huge fail.  I’ve either forgotten a critical piece of data or just didn’t think of a certain use case than needs to be handled.  If I’m not careful, I’ll continue morphing my original solution and bolting new things onto it to try and fix the shortcomings.  This cycle iterates a couple more times, and I eventually end up with a tangled mess of code that makes no sense to me or anyone else who looks at it.  The best thing in situations like this is to stop at the first sign of trouble and take another look at the solution as a whole.  With the new knowledge gained from the first try, a completely different approach may be warranted.  Don’t be afraid to consider something different altogether if the outcome will be a more solid solution in the end.  Of course, there is rarely unlimited budget to continually go back to the drawing board, but often times a better solution also results in less code and less time to implement.  Once the maintenance and bug fixing time is factored in, you’ll come out way ahead in the end.

Presentation is Key

I don’t consider myself to be a great fly fisherman, as I lack the appropriate touch during the presentation of the fly to the fish.  It’s mostly a matter of practicing, but I have a tendency to thump the fly down on the water, scaring off any living thing within a 10′ radius.  This is really where the beauty of fly fishing comes in, and it’s not a skill that is easily mastered.  I do consider my brother to be a great fly fisherman.  He’s been doing it a lot longer than me, and certainly has it down.  He’ll lay the fly down on the water as gently as a feather.  And as a result, he catches about 4 or 5 times more fish than I do.  We can be fishing the exact same spot, and he’ll be pulling fish out one after another while I’m not even getting a strike.  It’s a bit frustrating for me, but he’s definitely put a lot more effort into learning than I have.

I’ve observed a similar effect in programming.  An elegant and beautiful UI goes a long way in covering the most egregious backend coding.  It’s the first thing a client sees, and judgements happen quickly.  I’m certainly not advocating a pretty UI at the expense of the backend.  Rather, leave time and budget for an appropriate amount of UI polishing once the functional requirements have been met.  In a lot of cases, engineers are purely practical, and a purely functional UI is where we stop.  Not only that, but budget shortcomings usually end up nixing non-essentials, under which UI polishing usually falls.  It certainly takes extra time and effort to create a polished and streamlined UI, but it’s worth it.  It’s the face of the app, and you’ll end up catching a lot more clients if your portfolio is striking.

Creative Commons License

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.