Here's what I've noticed: most people who stop coding outside of work don't stop because they hate it or don't have time.

They stop because the gap between having an idea and executing on the idea feels impossibly wide.

Let me explain.

How We All Started

Remember how you got better at coding when you first started?

You simply wrote more code.

You built projects.

A to-do list app here, a weather dashboard there, and maybe a portfolio site to showcase all the projects.

Every new project exposed you to new problems, new patterns, different implementation styles, and new ways of thinking.

You gradually built confidence because your code was actually doing things.

Then You Got the Job

And somewhere along the way, that spark started to fade until you stopped building entirely.

I’ve thought a lot about why this happens to a lot of us, and I have some theories:

Theory one: If you were coding solely to land a job, mission accomplished. The external motivation disappeared once you got the offer.

Theory two: Maybe you want to continue building, but you’re mentally exhausted. You spend 7+ hours a day writing code at work. Coming home to do more of the same feels like the last thing you want to do.

Theory three: Money changed the relationship. Daniel Pink talks about this in his book Drive – how artists and creative people can develop complicated feelings about their craft once it becomes their livelihood. What we used to enjoy doing now becomes work we dread.

Theory four: Life got busier, and you legitimately don’t have time anymore. You have competing priorities.

These are all valid reasons. Maybe one of them is true for you.

But let me offer what I think is the most common culprit, one that’s less obvious.

The Real Culprit: It Feels Overwhelming

Here's what I've noticed: most people who stop coding outside of work don't stop because they hate it or don't have time.

They stop because the gap between having an idea and actually building it feels impossibly wide.

Think about the projects you built when you were learning.

They were small, achievable, and clearly scoped.

You knew exactly what you were building and what the end product would look like.

You might have also been following tutorials, making it even easier.

But now? Those projects feel too basic.

You've outgrown them.

So you aim higher, which makes sense.

You're a better developer now.

You should be building full-stack applications that use WebSockets and provide real-time updates.

Mobile applications with social login and cloud sync.

Developer tools that solve the annoying problems you keep running into at work.

These are genuinely good ideas.

The problem isn't the ideas themselves; it's that they exist as big, shapeless things in your head.

You have a vague notion of building something cool, maybe learning a new framework along the way, but no clear starting point, no sense of when you'd actually be done.

So you never start.

Or you start and abandon it two weeks in because it gets hard, and you have no sense of direction.

Sounds familiar, doesn't it?

Trust me, I've been there more times than I'd like to admit.

But here's what changed things for me.

The Solution: Always Start By Developing the Idea

Take that idea and break it down until it becomes clear, simple, actionable steps you can take.

When you spend time thinking through what you want to build, a few things happen:

First, you generate more specific ideas. That general “I want to build a productivity app” becomes “I want to build a Pomodoro timer that integrates with my calendar and sends me daily summary emails.”

Second, you can assess feasibility. Is this something you can actually build with your current skills? What would you need to learn? How much time would this realistically take? This prevents you from investing weeks into something that was never realistic to begin with.

Third – and this is the key part – you scope the project. Most personal projects feel weird because they’re never properly scoped. They exist as this endless, ever-expanding vision with no clear finish line. That’s why you feel overwhelmed at some point.

Here is what the process of developing your idea should look like.

Grab a document. I like to use Notion, but you can use Google Docs or a plain text file.

Write these things down:

1. A description of what you are building. Explain it in clear, simple terms.
2. Your specific goal: Why are you building this project? Pick one:
   • Learning a new technology – e.g., “I want to understand how WebSockets work by building a real-time chat app.”
   • Shipping something end-to-end – e.g., “I want to experience the full deployment process from local development to production.”
   • Building something useful – e.g., “I want to build a tool that solves this specific problem I have.”
   • Experimenting with an idea – e.g., “I want to see if this approach to state management actually works better.”
   • Building your portfolio – e.g., “I want something polished I can show potential employers.”
3. The MVP scope: What’s the absolute minimum version that achieves your goal? List only the essential features, not everything you could add.
4. What’s out of scope? What are you not building? Write it down to prevent feature creep.
5. A rough estimate of your timeline: e.g., “I will commit two hours twice a week for a month” is realistic. “Until it’s done” is unrealistic.
6. Your success criteria: At what point will you be satisfied with the work you've done on this? This can tie back to your goal.

One Step At A Time

The point of developing your idea isn't to create the perfect project plan or build the next unicorn startup.

It's to make your next step crystal clear.

It's to give you a sense of direction, with a clear starting and an ending point.

As our ideas get more complex, this planning becomes essential.

It's just the nature of software development.

The bigger the problem, the more you need to break it down.

At work, someone usually does this for you – a PM scopes the project, breaks down the tickets, and defines the acceptance criteria.

But with personal projects, we have to do that ourselves.

Pick something you've been wanting to build.

Grab a document and work through those six questions.

Give yourself an hour to actually think it through.

I guarantee you'll come out of that session with clear next steps that will get you excited about building again.

I'd love to hear how it goes. Reply to this email and let me know what you're building.

Talk soon.

— Uma

PS: My Sunday basketball league wrapped up this past weekend. We lost in the semi-finals, but I was named a league all-star for the second year in a row, and I had a lot of fun competing.