There is a strange state you can reach as a developer.
You still know how to code.
You still understand the logic. You can still look at a problem and roughly see how you would solve it.
But opening the editor feels difficult.
Not writing the code.
Just starting.
And I think that's an interesting distinction.
Maybe sometimes we say:
"I'm tired of coding."
when the real problem is:
"I don't know what I want to build anymore."
Those are not the same problem.
I can build it. But what is "it"?
Give me a real problem and things become easier.
An API needs to receive orders.
A database needs to store them.
A service needs to process them.
A UI needs to expose the result.
Now there is something to push against.
Architecture starts appearing. Trade-offs become visible. You can make decisions.
But give a developer an empty repository and say:
"Build something."
That's different.
Suddenly, knowing five languages doesn't tell you what the first commit should be.
You don't have a programming problem anymore.
You have a direction problem.
And I don't think we talk about that enough.
The first step can be the real problem
One of the interesting things in the discussion around burnout is that people don't always describe the same obstacle.
For some, the answer is rest.
For others, it is finding something interesting again.
Someone even described opening a project, changing one variable, closing it, and repeating that for a few days. The important part wasn't the variable. It was getting past the first few seconds of opening the editor.
That made me think.
What if "starting" is its own problem?
You can have the skill.
You can have the time.
You can even have a project.
And still not cross that tiny gap between:
I should code
and
I'm actually coding.
Maybe the project is the missing piece
There is another possibility.
Maybe the solution isn't another productivity trick.
Maybe there simply isn't a problem worth solving right now.
A developer can be perfectly capable of building something and still have no reason to build it.
And "just make a side project" doesn't really solve that.
What kind of project?
A game?
A SaaS?
A CLI tool?
A portfolio project?
Something useful?
Something technically impressive?
Something completely stupid but fun?
The moment you ask those questions, you realize that "build something" isn't actually a small instruction.
It's a huge one.
Skills can survive when motivation doesn't
This is probably the part I find most interesting.
You don't necessarily forget programming because you stop coding for a while.
You may still remember the syntax.
You may still understand the architecture.
You may still be able to solve the problem once somebody gives you one.
But the connection between "I can build this" and "I want to build this" can disappear.
And maybe that's why some developers don't need another tutorial.
They need something that makes them curious again.
A problem.
An idea.
A person asking for something.
An open-source issue.
An old project that suddenly looks interesting again.
Anything that gives the technical ability somewhere to go.
So how do you start again?
Honestly, I don't think there is one universal answer.
Sometimes the answer might be rest.
Sometimes it might be stepping away from the editor.
Sometimes it might be writing an idea on paper before writing code.
Sometimes it might simply be finding a problem that makes you think:
"Wait... I could actually build that."
And maybe that's the more useful question than:
"How do I become productive again?"
Maybe it's:
"What would make me want to build something again?"
Have you ever reached a point where you still had the skills, but couldn't bring yourself to start?
Was the problem the coding itself, the lack of ideas, or simply having nothing that felt worth building?
Top comments (2)
Really appreciate the structured breakdown here. Especially with workflow optimization, focusing on low-friction daily habits compounds significantly more than constantly swapping tooling.
Exactly. I think the biggest trap is treating friction as a tooling problem. Sometimes the better optimization is simply making the first step easier, so the workflow can actually start. Once you're moving, the tools usually matter a lot less.