Mar 31st, 2022
Spoiled for Choice, or Not
Written by: Max Hoaglund, Senior Technology Lead
For many of us, the prototypical problem-solving activities presented to us in educational contexts early in life carried a few alarming qualities. Problems designed to teach processes to people in the world are, absurdly, both depersonalized and not concrete: a physics problem might be designed to help you learn about static friction but is set in a universe with idealized laws for that particular phenomenon. That problem might go on to generically concern a fantasy automobile and its fantasy tires as they slip or grip nonexistent asphalt. It’s not your car, you don’t know what state or country the car is in, and you can proceed with your problem-solving activity without being concerned about the reality of the car. Not to mention – you didn’t choose this problem and taking notice of any particular quality that you or your surroundings have isn’t going to help you.
It’s easy to compare this to nearly any problem-solving scenario from your technology project, my technology project, or literally any human context with any stakes. That examination first highlights some frustrating, reductive qualities carried by problem solving education traditions – constructing an idealized problem in the first place has some embarrassing, absurd qualities to it. On the other hand, contending with every day’s non-idealized, thorny, frustratingly real problems is rich, dramatic, and not trivial. There’s no contest there, it’s easy to form a preference. But what other qualities can we tease out of this comparison?
What about choice?
A reflective point of gratitude that floats through the mind of many an exhausted middle manager or developer is “I chose this. This is what I chose, even if it sucks right now.” I hope this postulate is concretely true for you, and I don’t take issue with the sentiment! But how true is it? I’d say it’s a bit shy of half the story. The path a problem takes to get to the person who eventually solves it is not wholly shaped by the choice of the solver or the solver’s manager. Further, it can be hard to sense any nuance in the stream of problems you might solve as a technology worker every day/week/year – and imposter syndrome can make your defining existence as an expert problem-solver seem nonsensical in times of stress.
I’d like to claim that the nuance is there, and it isn’t mystical, just hard to parse (trying to parse difficult, nuanced things is probably part of your job if you’re reading this, incidentally). We can start to find that nuance by inverting the earlier reductio ad absurdum tendency of educational problems and positing that the problems you solve in your work are probably hyper-concrete and, bafflingly, hyper-personalized to you. This stack of expensive words could use some decomposition. Technology problems are hyper-concrete in the sense that when they are solved with care, they often fundamentally maximize the capacity of a group of things or people, and thus address one or more elemental existential problems. Slightly harder to explain is that technology problems are hyper-personalized to the solver – that may mean you’re a DB Admin on a data team and you’re solving a data problem, but that’s a boring example. It may mean you’re joining a team that works with a system and a technology that you’ve never seen or heard of before, and what nobody has told you is that they’ve observed grace and flexibility in your demeanor, and they know this project really needs that. These personalizations are the byproduct of the professional fabric you’re woven into, and that fabric includes your colleagues and company and stretches outside it. Your colleagues are somewhat-democratically choosing which problems you personally get to solve, and your clients are somewhat-democratically choosing what problems your organizations gets to solve, and so on.
If you’ve just been handed a challenging problem, a good antidote to intimidation, cynicism, and fear can be found in locating these personalizations. On some level, it is about you, and the problem chose you because of something you chose. That might be as straightforward as attitude, competence, or domain knowledge – but it’s definitely more than one of those and goes way, way beyond them. Why are you really working on what you’re working on, and how did you get here? I think keeping that in mind is a better tool than a Gantt chart or a calendar.