Every team has a module nobody wants to touch and a handful of habits nobody remembers choosing. The tests pass, the deploys are boring, and the roadmap ships roughly on time, which feels like success right up until a new hire asks why the build takes eleven minutes and nobody has a good answer. In optimization terms, that team is parked on a local maximum: a hill that looks like the summit only because nobody has walked far enough to see the next one. A short essay on why exploring new ideas changes everything makes a point that sounds obvious until you try to live by it: curiosity pays off when trying new things is balanced by commitment to the ones worth keeping. For developers, that balance is more than a life lesson. It is a well-studied algorithmic problem, and treating it like one can change how you learn, debug, and lead.
Your Week Is a Multi-Armed Bandit
Picture a row of slot machines, each with an unknown payout. Every pull forces a choice: play the machine that has paid well so far, or gamble on one you barely know. Computer scientists call this the multi-armed bandit problem, and its core tension between exploring and exploiting turns up everywhere from clinical trial design to the recommendation engine picking your next video.
A developer's week works the same way. Exploiting means reaching for the stack, patterns, and shortcuts you already trust. Exploring means reading unfamiliar source code, trying a paradigm that feels clumsy at first, or chasing down why a system behaves the way it does. Pure exploitation is efficient and slowly fatal, because you get faster and faster at an approach whose ceiling you never get to see. Pure exploration fails differently, as anyone who has rewritten a side project in a fourth framework without ever shipping it can confirm.
One of the simplest bandit strategies, epsilon-greedy, splits the difference. Most of the time you pick the option that has performed best; with a small probability called epsilon, you try something else at random. The detail that matters for us hides in the theory: when payouts drift over time, a situation known as a non-stationary problem, exploration should never stop, because yesterday's best machine quietly stops being the best. Few environments drift faster than software. The tools that dominated ten years ago guarantee nothing about the next ten, and the only way to notice the drift is to keep pulling a few unfamiliar levers.
Bell Labs Ran This Experiment Decades Ago
Richard Hamming, the mathematician whose name lives on in Hamming codes, described his own version of this strategy in a 1986 talk called "You and Your Research." Nudged by colleagues, he reserved Friday afternoons for what he called Great Thoughts Time, setting routine work aside to ask questions like how computers would change science. Those afternoons led him to predict that most experiments would eventually run on computers instead of in laboratories, a forecast the company's vice presidents brushed off and one he lived to see vindicated. Half a day out of a five-day week is about ten percent, so Hamming was effectively running with an epsilon of 0.1.
He also noticed something about office doors. Colleagues who kept theirs shut got more done in the short run, yet years later many seemed unsure which problems deserved their effort. Those who left the door open put up with interruptions but kept picking up clues about what mattered. Swap the door for a Slack status and noise-canceling headphones, and the observation holds up uncomfortably well.
What Curiosity Does Inside Your Head
There is a biological reason these tangents tend to stick. In a 2014 study at UC Davis, volunteers rated how curious they were about the answers to more than a hundred trivia questions, then lay in an fMRI scanner while those questions reappeared. Before each answer was revealed, they briefly saw a photo of a stranger's face that had nothing to do with the question. As Scientific American's report on how curiosity prepares the brain for learning describes, people remembered the answers to intriguing questions better, and they also remembered the unrelated faces better, an effect that still held a day later. Anticipation switched on the brain's dopamine-linked reward circuitry, and the strength of its interaction with the hippocampus, a region central to forming memories, predicted who would recall those incidental faces. Charan Ranganath, the neuroscientist whose lab ran the study, likened curiosity to "an itch that you have to scratch."
The lesson for developers is that curiosity is more than a pleasant mood. It is a learning state you can switch on deliberately. Carnegie Mellon behavioral economist George Loewenstein proposed in 1994 that curiosity appears when we notice a gap between what we know and what we want to know, and you can manufacture that gap on demand. Before running a query, guess how many rows it will return. Before opening the profiler, predict which function will dominate the flame graph. Before reading the docs for a new API, sketch how you would have designed it. Being wrong is the whole point, because a failed prediction opens exactly the kind of gap your brain seems built to close and remember.
Curiosity Is a Debugging Tool, Not a Distraction
Debugging is where the explore-exploit trade-off gets personal. The moment you form a theory about a bug, every log line starts to look like evidence for it. That is confirmation bias, and it is how a two-hour fix becomes a two-day hunt. In Francesca Gino's research on the business case for curiosity, published in Harvard Business Review, the Harvard Business School professor explains that triggered curiosity makes people less prone to confirmation bias, more deliberate in their decisions, and more inventive in the solutions they reach. A curious debugger treats the first hypothesis as a guess to be broken, not a position to be defended.
Curiosity also changes what "fixed" means. Once the bug is gone, ask one more question: why did this ever work? Code that ran fine for months and then failed is pointing at an assumption, a dependency, or a boundary that nobody wrote down. Running git log -S with a suspicious string shows every commit that added or removed it, and git bisect binary-searches your history for the change that broke things. Use these tools to recover intent, not only to find culprits. Chesterton's old parable about the fence across a road applies neatly here: the strange check that looks pointless was usually added by someone with a reason, and learning that reason before you delete it is the cheapest humility lesson software offers.
How to Explore Without Wrecking Your Sprint
Curiosity needs structure, or it loses to the next deadline every single time. These habits keep your exploration rate above zero without turning the week into one long side quest:
- Pick an epsilon and put it on the calendar. Ten percent is a sane default: one protected afternoon a week or roughly forty-five minutes a day. Curiosity without a time slot usually gets spent on whatever is loudest.
- Keep a question backlog. When a "wait, why does that happen?" moment interrupts focused work, jot it in a running file and return to the task. Triage the list during your exploration block, so focus and curiosity stop fighting over the same hour.
- Read one layer down. When a library surprises you, step into its source with the debugger instead of searching for a workaround. Most framework magic turns out to be ordinary code with a good name.
-
Timebox the rabbit holes. Open a branch prefixed with
spike/, set a ninety-minute timer, and make the deliverable a short written note rather than mergeable code. The note is what turns an excursion into an asset. - Explore next door before you explore another planet. A 2012 study led by cognitive scientist Celeste Kidd found that infants pay the most attention to events that are neither too predictable nor too surprising, and research on adults points the same way. If you write TypeScript all day, a week with Rust's type system will stretch you in productive ways, while a language with nothing familiar may produce more frustration than insight.
- Ask "why does this work?" in code review. Questions about passing code surface hidden assumptions long before failing code does.
Make Questions Cheap for Your Team
Personal habits only go so far when asking questions feels risky. In a survey Gino conducted of more than 3,000 employees across many industries, only about a quarter said they regularly felt curious at work, and roughly 70 percent said they faced barriers to asking more questions. Engineering teams are not exempt. Anyone who has watched a junior developer stay silent through an entire design review has seen that tax being paid.
Leads and senior engineers set the exchange rate for questions. Say "I don't know, let's find out" in public, and say it often. In code review, turn uncertainty into a question instead of a verdict. In incident reviews, treat "why didn't we see this coming?" as a design problem rather than a search for someone to blame. Gino also recommends dedicating whole days to asking "Why?", "What if…?" and "How might we…?" On a dev team that might be a monthly hour where anyone can nominate a mystery in the codebase and the group digs in together. The product of that hour is shared understanding, which no amount of refactoring can generate on its own.
The Compound Interest of Small Detours
Curiosity rarely pays out on the day you spend it. The afternoon you spend learning to read EXPLAIN ANALYZE output feels unproductive until the night a slow endpoint stalls checkout and you are the only one who knows where to look. Hamming argued that knowledge compounds like interest, and exploration follows the same math, except the returns arrive as options. Each small detour adds another road to your mental map, and when requirements shift, the developer with the bigger map simply sees more exits.
So here is an experiment for this week. Find one question you skipped recently because you were busy, give it thirty uninterrupted minutes, and write down what you learned, even if the answer turns out to be dull. Then share it in the comments: which rabbit hole paid off the most for you?
Top comments (0)