By the time I finished my fourth "Build a Full-Stack App" tutorial in a single week, I had three unfinished projects, zero original ideas, and a browser history that looked like someone was desperately trying to avoid writing original code.
Sound familiar?
There's a specific kind of plateau that developers hit — usually somewhere between "I've learned the basics" and "I actually feel competent." You're not a complete beginner anymore. You can read documentation without panicking. You've built a few things. But something still feels off. You open your editor and the blank file just stares back at you like it's personally insulted by your presence.
The common advice is to "build more projects." Great. Thanks. Very helpful.
What nobody tells you — what took me an embarrassingly long time to figure out — is that some of the most important growth I've had as a developer happened away from the keyboard. Not despite leaving coding behind for a while, but because of it.
The brain is weird. It doesn't grow linearly. You can push and grind and consume more tutorials, and sometimes you hit a ceiling that more coding simply won't break through. But go spend three months getting obsessed with chess, or woodworking, or improv comedy — and suddenly you come back to your codebase with a different kind of clarity. Problem-solving instincts you can't quite explain. Pattern recognition that feels sharpened. An ability to sit with ambiguity without spiraling.
This isn't a coincidence.
This post is about those hobbies. Not "read books" or "take walks." Real hobbies, with real explanations for why they work. If you're a developer who's burned out, bored, or just itching to grow in a direction you can't quite name — keep reading.
First, Why Non-Coding Hobbies Actually Make You Better at Coding
Before we get into the list, let's be honest about something: this isn't pseudoscience motivational content. There are real, concrete cognitive mechanisms at play here.
Transfer learning is the idea that skills and mental models developed in one domain can carry over to another. This is why chess players tend to be good at seeing complex systems. Why musicians often have a strong grasp of timing and structure. Why architects and programmers sometimes think in eerily similar ways. The brain doesn't draw the same boundaries between disciplines that we do on our resumes.
There's also the concept of diffuse thinking — the mental state where your brain is making connections in the background, often while you're doing something else entirely. You've experienced this. You couldn't solve a bug for three hours, went for a walk, and the answer surfaced on its own. That's not magic. That's your default mode network doing its job.
And then there's the simple reality that most experienced developers will tell you: the best programmers they've worked with have rich inner lives outside of code. They're curious about everything. They read weird stuff, make things with their hands, play obscure games. That breadth of experience gets compressed into how they think when they're writing software.
A developer who's only ever coded will, inevitably, think about problems in a very narrow way. One who's also spent years doing woodworking thinks in tolerances and sequences. One who's into music production thinks in modular, composable systems. One who does improv thinks in feedback loops and graceful failure.
You don't become a better programmer just by writing more code. You become a better programmer by becoming a more interesting, more experienced thinker. And that requires leaving the IDE sometimes.
Okay. Let's get into it.
1. Chess (But Not the "10,000 Hours to Master" Kind)
Let me be clear — you don't need to become a tournament player for chess to sharpen your mind. Even playing casually for a few months rewires something.
Chess teaches you to hold multiple variables in your head simultaneously. To think two, three, four moves ahead. To recognize patterns you've never consciously memorized but your brain has seen enough times to start anticipating. This is exactly the skill required when you're debugging a nontrivial piece of code, designing a data model, or refactoring something with deep dependencies.
There's also the emotional component. Chess is merciless. When you make a bad move, the board tells you immediately — not in a vague "something is wrong" way, but in a very specific "your queen is about to get eaten" way. Over time, this trains you to be less defensive about mistakes and more curious about them. That attitude is enormously useful when a junior dev on your team pushes buggy code, or when you realize your own architectural decision from six months ago was quietly wrong.
The opening theory is also quietly useful. Openings are essentially best-practice playbooks developed over centuries of trial and error. When you study why certain opening sequences are preferred, you're essentially studying why certain design patterns exist — because over thousands of games (iterations), certain approaches proved more resilient. Sounds a lot like software architecture, doesn't it?
Practically, even 15–20 minutes a day on chess.com or Lichess will do it. You're not trying to hit 2000 Elo. You're just trying to train the pattern-recognition and forward-planning circuits in your brain.
2. Music Production (DAWs Are Just Code With Better Marketing)
Open Ableton Live or FL Studio for the first time and you'll feel like you've opened a codebase you've never seen before. There are modules, signals, loops, conditional triggers, effects chains, buses. It's modular, it's composable, and it will absolutely break in ways you didn't expect.
Music production teaches you systems thinking in a way that's visceral and immediate. You're building something that exists in time. You have to think about how a kick drum on beat 1 interacts with a bassline pattern that runs for 8 bars and feeds into a chorus that doubles the tempo. If you change one element, something else shifts. Sound familiar?
The debugging skills are also surprisingly transferable. When a mix sounds wrong — when something's clashing, or muddying the low end, or making the whole track feel claustrophobic — you can't just Google the error. You have to listen. You have to isolate. You have to mute tracks one by one, adjust frequencies, test, listen again. This is the exact workflow of debugging: isolate the variable, test the hypothesis, iterate.
There's also something that production teaches about constraints. A blank canvas is paralytic. But give yourself a specific limitation — only 4 instruments, only 90 seconds, only minor keys — and creativity explodes. This maps directly to building software under real-world constraints: limited API rate limits, tight deadlines, a design spec that wasn't totally thought through. Constraints force solutions. Production teaches you to love them.
3. Woodworking or Any Physical Craft
You will measure wrong. You will cut wrong. You will glue something in the wrong orientation and then have to spend 20 minutes figuring out how to un-glue it without destroying the whole thing. This is basically just debugging, except the compiler is a saw and the errors are permanent.
Woodworking, and physical crafts in general, teach you something that almost no amount of coding will: the cost of irreversibility. In code, everything is undoable. Git exists. Ctrl+Z exists. You can refactor later. This is wonderful, but it also quietly trains a certain carelessness. Real-world crafts strip that away. When you make a cut, it's made. When you drill a hole, the hole exists. You start to plan more carefully. You start to think through the whole sequence before picking up the tool.
This maps directly to the habit of thinking before you type — a skill that more developers desperately need. The urge to just start coding something is strong. But experienced developers know that ten minutes of thinking before writing saves two hours of rewriting. Woodworking trains that instinct viscerally, because the cost of not thinking is made of actual wood and actual time.
There's also something deeply grounding about making something you can touch. Development is invisible work. You spend hours producing something that lives entirely in electrons. When you're burned out, this can feel hollow. Going home and building a shelf, a cutting board, a small cabinet — something you can actually hold — has a way of resetting your relationship with the act of creating things.
4. Dungeon Mastering (Running Tabletop RPGs Like D&D)
If you've never played D&D or any tabletop RPG, I understand if this sounds unhinged. Bear with me.
Running a game — being the Dungeon Master — is one of the most mentally demanding creative activities I've ever encountered. You're building a world with lore, rules, and internal logic. You're designing encounters that are challenging but not impossible. You're managing five players who will, without fail, ignore every plan you made and do something completely unexpected. And you have to improvise, in real time, in a way that feels coherent and satisfying.
This is API design thinking. This is edge case handling. This is graceful degradation.
When you build a dungeon crawl, you're essentially writing a system with a public interface (what the players can interact with) and internal logic (what happens behind the screen). You have to think about unintended use cases. What if they try to bribe the villain? What if they sneak in through the window you didn't plan? What if they somehow befriend the monster?
Good Dungeon Masters don't break the game when this happens. They improvise within the rules, extend the system logically, and make the player feel like their unexpected action was always possible. This is exactly what senior developers do when users do something in production that the product spec never accounted for.
Also: narrative structure. A well-run campaign has rising tension, satisfying resolution, and clear cause-and-effect. This translates directly into writing good documentation, structuring READMEs, explaining technical decisions — the ability to tell the story of your code in a way that makes sense to other humans.
5. Puzzle Design (Making Puzzles, Not Just Solving Them)
Most developers solve puzzles — Leetcode, Advent of Code, brain teasers. But very few design them. This is where the real skill development happens.
Designing a good puzzle requires you to think from the inside and the outside simultaneously. You have to understand the puzzle so completely that you can anticipate how a stranger will approach it. What will they assume? Where will they get stuck? Is there an unintended solution path that breaks the challenge? Is it too easy? Too obscure?
This is exactly the skill required for API design, code review, and system design. When you design an API, you have to think like the person who's going to use it — not the person who built it. Those are two very different mental stances. The designer has all the context. The user has none. Bridging that gap requires genuine empathy, and puzzle design is one of the best ways to train it.
Escape room design is a particularly great version of this, if you can get involved in it. The best escape rooms are systems — every puzzle feeds into every other, the difficulty scales, the theme is internally consistent. It's basically game design, which is itself basically software architecture.
6. Cooking (Specifically: Improvised Cooking Without Recipes)
Following a recipe is fine. Improvising without one is where things get interesting.
Good improvisational cooking requires you to understand why techniques work, not just what to do. You can't just swap butter for oil without knowing how that changes the texture. You can't double a spice without knowing how it interacts with the others. You need a mental model of the system, not just the instructions.
This is the difference between a developer who follows tutorials and one who understands the underlying principles. The tutorial-follower is lost the moment anything deviates from the script. The principle-understander can improvise, adapt, and solve problems that nobody has written a Stack Overflow answer for yet.
Cooking also teaches mise en place — the French culinary concept of preparing everything before you start cooking. Chop all your vegetables. Measure your spices. Have everything in position. Then cook. Developers who understand this prepare their environment, plan their approach, and set up their tooling before writing a single line. The ones who don't end up four hours in, mid-feature, realizing they need to refactor their whole state structure.
There's also iteration. Good cooks taste constantly. Adjust. Taste again. They don't wait until the whole dish is done to figure out if it needs salt. This maps perfectly to test-driven development, frequent commits, and the general practice of building incrementally rather than big-bang deploying something you haven't touched in three weeks.
7. Rock Climbing
I know. Bear with me again.
Rock climbing, especially bouldering, is a fundamentally computational activity disguised as a physical one. When you look at a climbing route — called a "problem" (already we're speaking the language) — you're looking at a sequence of moves that must be executed in order, with specific constraints on how your body can engage with the wall. You're essentially parsing an algorithm with your eyes before executing it with your body.
The problem-solving loop in climbing is tight and immediate. You fail a move. You reset. You try a different approach. You succeed. This fast failure-and-iteration cycle is exactly the mindset you want when you're working through a technical problem. Most developers are too slow to try things. They overthink. Climbing breaks you of this because the wall gives you feedback instantly and the cost of a failed attempt is just "try again."
There's also the concept of rest positions. Experienced climbers know how to find spots on the wall where they can rest and recover before the hardest moves. This maps to pacing in engineering: knowing when to push hard and when to consolidate, refactor, and recover. Developers who never rest their codebase accumulate technical debt the same way climbers who never rest blow out their forearms.
Beyond the cognitive stuff — climbing is just brutally good for your health. Developers are sedentary in ways that compound over time. Climbing gets you off the chair, builds grip strength (your hands will thank you), and dumps enough endorphins to make you feel human again.
8. Learning a Foreign Language
No, not a programming language. An actual human language. Portuguese. Mandarin. Arabic. Whatever.
Language learning is the cognitive equivalent of heavy lifting. You're building a new symbolic system in your brain — new syntax, new grammar, new ways of expressing concepts that might not have direct equivalents in your native tongue. This forces a kind of mental flexibility that pure coding absolutely does not.
The part that's most directly transferable to programming is grammar internalization. When you're learning a language, you start by consciously applying grammar rules. Subject-verb-object. Tense agreement. Gender inflection. At first, it's slow and effortful. Then, gradually, it becomes automatic. You stop "applying the rule" and start just... speaking correctly.
This is exactly what happens when you truly internalize a programming pattern or paradigm. Early on, you consciously apply it. Later, it just becomes how you think. Language learning trains this exact process — the path from conscious competence to unconscious competence — and makes you better at navigating it in technical domains.
Language learning also builds tolerance for ambiguity. You will not understand everything when you're learning. You'll catch 60% of a conversation and have to infer the rest from context. This is an underrated developer skill — the ability to work with incomplete information, make reasonable assumptions, and keep moving without needing everything explained perfectly first.
9. Photography (Technical Photography, Specifically)
Not just snapping photos on your phone. I'm talking about understanding exposure — the relationship between aperture, shutter speed, and ISO. The exposure triangle.
Here's why this matters: the exposure triangle is a constrained system. If you change one variable, the others must compensate. Open your aperture for a shallow depth of field? You let in more light, so you need a faster shutter or lower ISO to compensate. The system has a fixed "budget" and you're allocating it across parameters. Sound like anything? It should. It's the exact mental model for performance tradeoffs in software — CPU vs. memory, latency vs. throughput, consistency vs. availability.
Photography also trains compositional thinking — the ability to decide what belongs in frame and what doesn't. This is shockingly similar to API design and abstraction. A good API, like a good photograph, includes exactly what's needed and excludes everything else. The discipline of ruthless exclusion is hard to learn in code, but the camera makes it visual and immediate.
And the post-processing workflow in photography — RAW files, non-destructive editing, layer adjustments — is essentially a pipeline. You're passing a raw image through a series of transformations to produce a final output. If you've ever worked with data transformation pipelines or understood why functional programming loves pure functions, this workflow will feel deeply familiar.
10. Improv Comedy
This one probably sounds the wildest. A developer. Doing improv. On a stage.
But improv is secretly one of the best training grounds for collaborative development.
The foundational rule of improv is "yes, and" — you accept whatever your partner offers and build on it. You don't block, you don't contradict, you don't seize control. You receive, you extend, you contribute. This is the exact posture that makes collaborative coding sessions, pair programming, and code reviews actually productive. Developers who "yes, and" in technical discussions build better things together than developers who treat every conversation as a debate to win.
Improv also trains you to be comfortable not knowing where something is going. You start a scene with no idea how it ends. You have to trust the process, trust your partner, and let the story emerge. This tolerance for process-without-outcome is critical in long engineering projects where the destination shifts, requirements change, and you have to keep moving without full clarity.
And failing gracefully. Improv scenes fail constantly — a joke lands wrong, a premise collapses, a bit goes nowhere. The mark of a good improviser is how quickly and smoothly they recover, often making the failure itself part of the scene. This is exactly what senior developers do in production incidents. The system fails. They don't panic, don't freeze, don't blame. They adapt, communicate, and keep moving.
11. Game Development as a Side Hobby (Not Your Day Job)
Wait, isn't this just more coding?
Technically yes. But game development, especially as a hobby with low stakes, exposes you to problem domains you'll almost never touch in typical web or backend work.
Physics simulations, collision detection, render loops, state machines, AI pathfinding, procedural generation, spatial data structures — these are things that sit in dusty corners of computer science that most developers never encounter. Playing with them, even roughly and amateurishly, stretches your mental model of what code can do.
More importantly, game development has an extremely unforgiving feedback loop. In web development, most bugs are invisible to end users or cause polite error states. In game development, a physics bug makes your character clip through the floor. A logic error makes your enemy AI run into walls forever. The bugs are immediate, visual, and funny. This keeps you engaged in the debugging process in a way that enterprise software rarely does.
The other thing game dev teaches is scope control. Game developers have a famous saying: "scope creep kills projects." Every indie game that never shipped started as a small idea that grew tentacles. The ones that shipped were ruthlessly scoped. This lesson — learn to cut, learn to ship small — is applicable everywhere in software development, but game dev makes you feel it acutely.
12. Journaling (Specifically Technical and Reflective Journaling)
This feels so mundane that most developers skip it entirely. That's a mistake.
Not just "dear diary" journaling. I mean the habit of writing about your own thinking. When you're stuck on a problem, write out what you know, what you've tried, and what you're confused about. When you finish a project, write a short retrospective: what went well, what didn't, what you'd do differently.
Writing is thinking. When you put something in words, you're forced to make vague intuitions explicit. This is why the rubber duck debugging technique works — the act of explaining the problem, even to an inanimate object, forces you to structure your thinking in ways that often reveal the answer. Journaling does this systematically.
Technical retrospectives, specifically, are where a lot of senior engineers quietly accelerate their growth. Most developers treat each project as an isolated event. Senior developers treat each project as a data point in an ongoing experiment about how they work. They track what decisions they made, which ones paid off, which ones didn't. Over time, this builds a personal mental library of patterns and anti-patterns that no tutorial can give you.
There's also the psychological benefit. Development is lonely work sometimes. Journaling externalizes the mental load — it gets the frustrations and the doubts out of your head and onto a page, where they're less overwhelming. You'll notice, over time, that the same fears and doubts recur. Seeing that pattern is freeing. The fear of "I'm not good enough" is a lot less scary when you can look back and see that you've written that same sentence a hundred times, and every time, you kept going.
13. Learning to Draw (Or Any Visual Art)
Not to become an artist. To learn how to see.
Drawing, especially observational drawing — drawing from life, from reference, from real objects — trains you to observe carefully. To notice what's actually there, not what you expect to be there. This is one of the most underrated skills in debugging: the ability to look at the actual behavior of a system, not the behavior you assumed it would have.
Most developers debug by assumption. They form a hypothesis immediately and then look for evidence that confirms it. This is backwards. Good debuggers describe what they actually observe — exactly what the output is, exactly what the error says, exactly what the network request returns — before they theorize. Drawing trains this discipline because art is unforgiving about assumption. If you draw what you think a hand looks like instead of what a hand actually looks like, the hand looks wrong. Every time. The only fix is to actually look.
Visual composition also transfers to UI work and technical writing. Where does the eye go first? What creates visual weight? How do you guide attention through a complex space? These questions are just as relevant to a dashboard design as they are to a painting.
14. Running or Long-Distance Hiking
Not for the fitness, though that's a welcome side effect. For the solo mental time.
Long-distance running and hiking — anything that occupies your body while leaving your mind free — creates the perfect conditions for diffuse thinking. Your subconscious works through problems while your conscious brain is tracking your pace or watching the trail.
Almost every developer I know who runs or hikes regularly has the same experience: ideas surface on runs that never come at the desk. Architecture decisions clarify themselves mid-trail. The connection you've been trying to draw between two systems suddenly appears somewhere around kilometer 7.
There's also something about sustained effort and patience. Running long distances teaches you that progress is nonlinear. There are good days and terrible days. Some days your body just doesn't have it, and you finish anyway. This is an almost perfect metaphor for long-term development work — especially on personal projects where there's no external deadline and the only accountability is internal.
Hiking, specifically, adds the element of navigation and orientation. Reading a topographic map, choosing a route, adjusting when the trail isn't where you expected — this is just problem-solving in physical space. And being wrong on a trail has immediate, physical consequences that sharpen your instinct for contingency planning.
How to Choose the Right Hobby for Your Personality
Not every hobby on this list will appeal to you, and that's fine. Forcing yourself into a hobby because it's "productive" is one of the fastest ways to make it feel like work.
Here's a rough framework for figuring out what might actually stick.
If you're someone who gets frustrated by ambiguity and wants immediate feedback, try something physical with tight loops — chess, climbing, or puzzle design. These give you clear, fast feedback on whether you're improving.
If you're someone who craves creative expression but feels boxed in by technical constraints, lean toward music production, visual art, or cooking. These let you make things that exist outside of logic, which can be deeply therapeutic.
If you're someone who's burned out by screen time specifically, the answer is almost certainly something with your hands — woodworking, drawing, cooking, climbing. Get offline. Touch real objects. Let your eyes focus on something that isn't a pixel grid.
If you're someone who feels isolated and wants to connect with other humans, improv and tabletop RPGs are the clear winners. They're inherently collaborative, inherently social, and will expose you to people who think completely differently from you. That exposure alone is worth the awkwardness of showing up the first time.
And if you're someone who processes externally — who needs to talk or write things out to understand them — journaling and language learning are your best bets. Both force you to articulate the inarticulate, and both reward consistency in ways that build confidence over time.
The key is to pick something and actually do it without tracking ROI. The benefits come passively. The moment you start treating a hobby like a productivity investment, you've killed it.
Mistakes Developers Make With This Whole "Productive Hobbies" Thing
Let's be honest about the dark side of this conversation, because we are, after all, developers — and we will find a way to optimize our way into misery if left unchecked.
Turning hobbies into side projects. You pick up drawing because you want something creative and offline. Three weeks later you're building a web app to track your sketch progress. Stop. This is a coping mechanism disguised as productivity. The point was to leave the keyboard.
Gamifying everything. Duolingo streaks are fine. Logging every chess game into a spreadsheet to analyze your win rates is probably too much. The moment a hobby starts generating anxiety about metrics, it's crossed a line.
Abandoning a hobby too early because you're bad at it. You're supposed to be bad at it. That's the point. Being a beginner at something teaches you what it feels like to be a beginner — the exact experience your users and junior teammates have with technology you consider obvious. This is deeply useful. Sit in the discomfort.
Only picking hobbies that feel "relevant." If you're drawn to birdwatching or pottery or learning about medieval history — do that. The brain makes unexpected connections. A developer who knows about bird migration patterns thinks about data flows differently than one who doesn't. Trust your curiosity.
Using the hobby as avoidance without doing any coding at all. There's a difference between healthy creative recovery and using hobbies as a way to indefinitely avoid the hard technical work you're scared of. Be honest with yourself about which one you're doing.
The goal is balance, not optimization. These hobbies should make your life richer and your mind more elastic — not become another line item on your self-improvement checklist.
The Part Where I Tell You to Actually Do Something
Here's the thing about all the advice in this post: it's completely useless until you actually pick something up.
You already know this. You've probably nodded at several sections thinking "yeah, that makes sense." And in two days you'll have forgotten this article entirely and gone back to the same loop — tutorial, small project, give up, tutorial.
So let me make a specific ask. Not "explore your creativity" or "find what makes you come alive." Something concrete.
Pick one thing from this list. Just one. And do the entry-level version of it tonight. Not as a commitment. Not as a habit you're building. Just to try it. Spend an hour on it. Don't track it. Don't tell anyone. Don't post about it.
Create a free account on Lichess and play three games of chess. Download a free trial of FL Studio and make 8 bars of something terrible. Open a journal and write three paragraphs about a problem you're stuck on at work.
Something will happen. It might not be profound. But something shifts in the brain when you stop doing the thing you're supposed to be doing and start doing something you actually want to do. The projects you come back to after that shift often surprise you with how much cleaner your thinking is.
The best developers I've met aren't the ones who coded the most. They're the ones who brought the richest inner lives to the keyboard. They cooked weird food and ran at odd hours and could talk for twenty minutes about a hobby you'd never heard of. And when they sat down to write code, they brought all of that with them — the patience, the creativity, the willingness to try things and be wrong and try again.
That's the kind of developer you become when you stop trying to optimize every hour and start actually living in them.
Now go do something. Anything. Just not another tutorial.
Written for developers who are more than their stack. If this resonated, share it with someone who's been staring at the same codebase for too long.
Top comments (0)