Know two ways

MP 142: Advice from a climbing guide that's quite relevant to programming.

Note: The debugging series will continue shortly. I'm busy getting ready for PyCon, and haven't had time to finish the next post in that series yet.

Since moving to North Carolina last fall, I've been getting back into climbing. Among other things, that means listening to a bunch of climbing podcasts. I'm currently listening to episode 91 of The Climbing Majority. This episode features an interview with Silas Rossi, an experienced climbing guide, with a focus on safety and risk management. One piece of advice he shared struck me as quite simple and relevant to most programmers: "Know two ways of solving common problems."

Improving as a climber

At one point in the conversation, Silas and the host discuss whether it's better to know one way to do something and keep using that approach, or if you should constantly try to learn new systems.

Silas' initial response to that question is really grounding:

I think a good place to start is that you should be able to solve a particular problem in two ways. Like to start, let’s just start by solving any problem with two different ways. And if you can do that, you’re off to a good start. (paraphrased)

A good example of a problem you have to solve in climbing is how to get back down once you've reached your high point. Often times that means rappelling, which is typically done with a rappel device such as an ATC. (A rappel device adds controlled amounts of friction between you and the rope, letting you descend at an appropriate speed.)

One scenario you really have to plan for, though, is what you'll do if you drop your main rappel device. If you only know how to rappel with that one device, you'll be stuck. If you know a second way to rappel, however, there's a good chance you'll still be able to get yourself down. There are many ways to get down a rope safely; you don't need to know all these approaches. But becoming comfortable with two different approaches will make you much safer.

There's an interesting side benefit that if you make yourself safer, you actually increase your risk tolerance, and your ability to perform at a higher level overall. If you're a climber, I can't recommend this episode enough.

Improving as programmers

So what does this mean for programmers? In Python, we're often reminded to use the simplest approach that works. But in order to choose the simplest approach to any given task, you need to know what your options are.

Consider a situation where you want to keep track of several pieces of information: wins, losses, and ties. You can do that with a dictionary:

results = {
    "wins": 0,
    "losses": 0,
    "ties": 0,
}

Each piece of information we're tracking corresponds to one key in the dictionary. Dictionaries are everywhere in Python, and you can go a long ways using a dictionary every time you need to keep track of information like this.

But there are lots of other options. Here's a dataclass that tracks the same information:

@dataclass
class Results:
    wins: int = 0
    losses: int = 0
    ties: int = 0

I like dataclasses because you can use dot notation to access attribute values, and you can add validation methods. But dataclasses aren't always better than dictionaries. For example it's sometimes better to write standalone validation functions, rather than tying validation to the data structure itself.

A longer discussion of the comparison between dictionaries and dataclasses is beside the point. There are many other ways to store this kind of information. The bigger point is, if you know two ways of storing information like this, you're going to think more critically about which approach you choose. You'll consider what you need to do with the data, and choose the approach that lets you accomplish your goals most effectively.

Conclusions

I've always been grateful to have a number of non-technical hobbies and passions as a programmer. They provide clean breaks from programming, and they also help me look at programming from a different perspective on a regular basis. If you have non-technical interests, keep an eye out for ideas from those areas that are relevant to your programming work.

When you need to solve a problem, use the first approach that comes to mind if you know it will work well. But if you're not quite sure your go-to approach is going to work well this time, consider doing a bit of research to find out if there's another approach. Over time, the habit of learning two ways to solve your most common problems will pay rich dividends.