Three months ago, facing a paid summer off, I asked myself what seemed like a simple question: do I want to focus on software development or product management?

The answer wasn’t in choosing one or the other. It was in understanding why I was asking the question at all.

Sometimes you need to go deeper into something to realize you’re meant to work above it.

The Setup

June rolled around with an opportunity I hadn’t expected: a paid summer off. Not a layoff, not a sabbatical, but a genuine chance to step back and think. Most developers would kill for this kind of time.

My initial plan was ambitious and focused: a “Summer of Code.” I’d dive deep into development, learn LLM tooling properly (not just surface-level prompting), and explore the kind of projects that get pushed aside when you’re shipping features on deadline. It felt like the perfect chance to answer that nagging question about my career direction.

Here’s the thing: I was burnt out and didn’t fully realize it.

We’re terrible at recognizing burnout when we’re in it. It’s like trying to see your own nose; it’s right there, affecting everything you see, but you’ve learned to ignore it. You adapt. You compensate. You tell yourself you’re just having an off week. Then an off month. Then you realize you’ve been having an off year.

The Journey

Writing as Unexpected Medicine

The first surprise came quickly. When sitting down to code felt like pushing water uphill, I started writing instead. Not documentation, not technical specs, but actual essays. Three to four a week poured out, like pressure finally finding release.

I discovered new workflows combining LLMs, markdown, and Hugo. Not the “hey ChatGPT, write me a blog post” kind of workflow, but something more nuanced. Using AI as a thought partner, an editor, a challenger of assumptions. The tools became extensions of thinking, not replacements for it.

The irony wasn’t lost on me: I’d planned a summer of code and ended up writing about coding instead. But that writing was doing something the code couldn’t. It was helping me think.

Projects as Exploration Vehicles

Of course I still coded. Several projects emerged, each serving a different purpose:

A family tree visualization tool started as scratching a personal itch. My family’s history is complicated (whose isn’t?), and I wanted to see the connections, not just list them. Building it taught me something: I enjoyed the system design more than the implementation details.

Interactive fiction systems came next. Not because I wanted to write games, but because they’re perfect learning laboratories. State management, narrative flow, user agency; it’s all there in miniature. Plus, debugging a broken story is more fun than debugging a broken form submission.

Text-based simulations followed. Games that teach, tools that play. Each one revealed the same pattern: I loved figuring out what to build and why, but the actual building? That was just the proof that the idea worked.

Product Briefs as Compass

Every two weeks, I forced myself to write a product brief. Not for anyone else, just for me. This wasn’t about features and user stories. It was about articulating value.

Why does this thing need to exist? Who suffers if it doesn’t? What changes if it does?

The discipline was revealing. Writing code, you can hide behind “it works.” Writing product briefs, you have to defend “why it matters.”

The LLM Laboratory

Part of my summer plan involved diving deep into LLM tooling. Not just using Claude or GPT-4, but understanding how to build with them, their limitations, their sweet spots.

I sampled various approaches, wrote a lab report, discussed findings with developer groups. The key insight wasn’t technical; it was human. LLMs are capable assistants, but they require clarity and review. They amplify your thinking but don’t replace it.

Teaching others about these tools clarified my own understanding. There’s a massive gap between tool capability and tool understanding in the market. Most people are either terrified of AI replacing them or convinced it can do everything. Both are wrong.

The meta-lesson: explaining technology’s impact matters as much as building it.

The Revelations

Burnout Recognition

The clearest sign of my burnout wasn’t fatigue or frustration. It was the loss of desire to read and write, replaced by endless doom scrolling. When your brain would rather consume garbage than create anything, that’s your canary in the coal mine.

Finding my rhythm again through daily practice wasn’t instant. It was gradual, like warming up after being out in the cold too long. First, you just stop being numb. Then you start to feel again. Then, finally, you remember what normal felt like.

Sometimes you need to stop to realize how tired you were. It’s only when you’re not carrying the weight that you understand how heavy it was.

The Altitude Metaphor

Here’s how I’ve come to think about it:

Software development is like working in the engine room. You’re making things go, keeping systems running, solving immediate problems. It’s essential work. It’s interesting work. The ship doesn’t move without you.

Product management is being on the bridge. You’re navigating, choosing direction, coordinating between all the parts. You need to understand the engine room, but your value isn’t in turning wrenches.

Both are essential. But I’m better at connecting business needs, human needs, and engineering and possibilities. I’m more valuable on the bridge, with regular trips to the engine room to stay grounded in reality and data.

Technical product management isn’t about choosing between code and strategy. It’s about speaking both languages fluently.

What Product Work Actually Means

Product work, for me, isn’t just about managing backlogs and writing user stories. That’s project management wearing a product hat. For product, we find and uncover user stories, looking for needs, and we map that to priorities and business needs.

Real product work is strategy: finding the intersection of possibility and necessity. It’s asking harder questions: Which metrics actually matter? What are the canaries that warn before crisis? Which problems are worth solving?

It’s about finding meaningful metrics and goals. Not vanity metrics that make dashboards look good, but the ones that predict success or failure three months out. The canaries in your particular coal mine.

A good example of a canary can be found in figuring out where and why people leave your product. Apathy is often a sign of low perceived value, which can be caused any gap between a customer’s world and your product. Frustration is an even harsher meteric, and you want to prevent it. Once you identify a real metric, the differnce will be immediately obvious.

The Synthesis

Why Product Feels More Compelling Now

After thirty years bouncing between startups, agencies, and enterprises, between coding and consulting, between building and teaching, product work makes better use of my accumulated experience.

The impact multiplies rather than adds. As a developer, I can build one thing well. As a product person, I can enable ten developers to build the right things. That’s not ego; it’s math.

There’s also a satisfaction in orchestrating rather than just implementing. It’s the difference between playing an instrument and conducting the orchestra. Both require skill, but they’re fundamentally different acts of creation.

The False Dichotomy

Here’s what took me too long to realize: it’s not software OR product. It’s software THROUGH product.

Technical credibility enables product leadership. If you can’t read code, you can’t really understand constraints. If you’ve never dealt with technical debt, you can’t make informed trade-offs. If you haven’t felt the pain of bad architecture decisions, you won’t prevent them.

But staying in the code all the time means you’re optimizing locally instead of globally. You’re solving the problem in front of you, not asking if it’s the right problem.

The Practical Philosophy

The recurring lesson from this summer: figure out what you want to do, as often as you can. Not what you should do, not what pays best, but what you actually want to do.

Then practice. Code, write, design, repeat. Not because practice makes perfect, but because practice makes for better clarity. You learn what you love by doing it, not by thinking about it.

The question that matters: do you love the things you’re doing?

The harder question: are you doing the things that use your best self?

Most of us can do many things competently. The trap is doing things you’re good at but don’t love. That’s the slow road to burnout, doing good work that slowly kills your spirit.

Finding the Way Back

I went looking for an answer about career direction. I found something more valuable: clarity about contribution.

The Summer of Code became a summer of rediscovery. Not discovering something new, but remembering something forgotten. I love building things, but I love building the right things more. I love solving problems, but I love finding the right problems more.

Sometimes the best way forward is to first go deep, then zoom out. You need the depth to have credibility, but you need the altitude to have impact.

Here’s the thing: I can still write code. I do it regularly, to stay sharp, to stay grounded, to remember what it feels like. But directing products? That’s where I can write the future.

The answer to my question wasn’t choosing between software development and product management. It was understanding that I’d already chosen, years ago, every time I got more excited about why we were building something than how.

This summer just helped me finally admit it.

And that’s okay. Better than okay, actually. It’s exactly where I should be.