If You Can't Tie A Knot, Tie A Lot
As we drift North, away from the channel and out to the depths of Lake Michigan, the helmsman begins to prepare for a day of sailing. Only, on this hot summer afternoon, the wind is nowhere to be found. Plan B… after motoring for a few miles we anchor and inflate the inner tubes. The helmsman strings a few together on a rope and tosses them overboard. A passenger casually remarks, “I can’t tie a knot!”, as she loosely wraps a rope around a dock cleat. The helmsman responds, “If you can’t tie a knot, tie a lot.”
Back in July, the Ruby Rogues podcast used knots as a metaphor for beautiful code. Lets discuss this metaphor a little further.
What kind of results do you get when you don’t know how to tie knots? You end up with something more complicated, convoluted, and confusing than you need. But hey, if you can’t tie a knot, tie a lot, right? Hopefully, no one other than yourself has to deal with that knot after you…
I think we’ve all run into a situation like this before. It’s the cycle of learning. We’re taught to keep trudging away at a problem until we solve it. If you have time, come back and clean it up. Red, green, refactor. Tests make this process straightforward. Sometimes fun! But too often, developers don’t come back and re-tie the knot leaving an over-programmed, over-abstracted, overly-complex codebase.
If you can’t tie a knot, sometimes the best thing to do is ask for help.
I really connected with this post - great metaphor. I started employing TDD practices regularly about 6 months ago, and it’s really changed my perspective on what good code should look/act like. I hate looking at stuff I wrote prior - and don’t get me started on looking at other dev’s code :) All I see are refactoring opportunities now..