There is a kind of tiredness I used to mistake for laziness.
I could sit in front of a laptop with enough energy to scroll, reply to messages, or reorganize files, but the moment I needed to make a real technical decision, everything felt heavy. Which approach should I use? Should this logic live in the component or somewhere else? Do I fix the old code first or finish the feature? Should I change the database structure now or work around it?
None of those questions is impossible. The problem is what happens when they arrive after fifty smaller decisions have already been made.
That is when development starts feeling harder than the code itself.
A developer can spend the day without producing anything
Software work contains more decisions than it looks like from the outside.
You choose names. You choose file locations. You decide what belongs in state. You decide how to handle an error. You decide whether to reuse a component. You decide whether the bug is important enough to interrupt the current task. You decide whether the quick fix is acceptable or whether the system needs a deeper change.
Then there are all the non-code decisions around the work: messages, emails, priorities, meetings, what to learn, what not to learn, whether to switch projects, and what to do when a dependency changes.
A day can contain hundreds of small choices before the hardest one arrives.
When that happens, “I do not feel like coding” may be a bad diagnosis.
You may simply have spent too much attention deciding things that did not deserve it.
I used to make the same decisions every morning
One of my worst habits was starting each day from zero.
Which project should I work on?
Which feature matters most?
Should I answer messages first?
Should I check analytics?
Should I fix the bug I noticed yesterday or continue the planned feature?
Every one of those questions looked reasonable. Together, they created friction before I had even opened the editor.
Now I try to push some decisions backward in time. Before I finish a work session, I leave the next technical action written down. I keep a small priority list instead of choosing from the entire project every morning. I use repeatable checklists for things like deployment and testing so I do not rebuild the process from memory.
The goal is not to remove judgment from development. It is to save judgment for the places where it actually matters.
Defaults are underrated engineering tools
Developers use defaults in software constantly because defaults reduce unnecessary configuration. I started applying the same idea to my work.
If I am debugging, my default is to reproduce before changing code.
If I am starting a feature, my default is to define the smallest useful version before adding extras.
If I am about to deploy, my default is to run through the same checklist.
If a task can wait, my default is not to interrupt the current focus block for it.
If I am uncertain whether to add another dependency, my default is to first ask whether the current stack can solve the problem cleanly.
Defaults are not rules that can never change. They are starting points that stop every familiar situation from becoming a fresh debate.
That saves more mental energy than it sounds like.
Too many options make simple tasks feel complicated
I have also learned to be suspicious of unnecessary choice inside the stack itself.
It is easy to spend an hour comparing libraries for something that could be solved in twenty lines of code. It is easy to explore three database approaches before proving the feature even needs one. It is easy to redesign an architecture because another architecture looks cleaner in a tutorial.
Options feel like freedom, but they also create decision cost.
When a project is young, I now prefer boring choices I understand over clever choices that create more questions. A familiar tool with a few limitations often produces more progress than an exciting tool that makes every next step a research project.
The hardest technical work should not be saved for the end of the day
Another change that helped me was noticing when I was scheduling work badly.
I would spend the morning on small admin tasks because they were easy to clear. By afternoon, I had a clean inbox and almost no patience left for the architecture problem that actually mattered.
That is backwards.
When possible, I now try to use the freshest part of my attention on work that requires judgment: designing a flow, tracing a difficult bug, reviewing sensitive logic, or making a decision that will affect the rest of the codebase.
Low-stakes tasks can survive lower energy. Important technical decisions deserve the better part of the day.
“Lazy” can become a useless insult
Calling yourself lazy feels like an explanation, but it does not tell you what to change.
If the problem is decision fatigue, there are concrete things you can do:
- decide tomorrow's first task before ending today;
- use checklists for repeated technical processes;
- reduce the number of active projects competing for attention;
- stop reopening solved decisions without new evidence;
- move hard work earlier when possible;
- keep a short backlog instead of carrying every idea in your head;
- define sensible defaults for recurring situations.
Those changes are more useful than telling yourself to “want it more.”
Sometimes the right move is actually to stop
There is another side to this. Not every tired coding session should be forced into productivity.
If I have made important decisions for hours and notice that I am now changing code without a clear reason, it can be better to stop. A tired developer can create tomorrow's bug while trying to finish today's feature.
The skill is learning the difference between ordinary resistance and degraded judgment.
Ordinary resistance often disappears once I begin a clear, small task.
Degraded judgment usually looks different: rereading the same line, forgetting what I just tested, changing multiple things at once, getting irritated by basic problems, or making decisions just to make the decision disappear.
That is usually a sign to leave notes and return with a better brain.
Protect the decisions that deserve you
Development is not only a measure of how many hours you can sit at a computer. A large part of the job is making good decisions under uncertainty.
That means attention is not a side issue. It is part of the technical resource you are managing.
I still have days where I feel slow. I still procrastinate. I still sometimes choose the easy task because the important one feels uncomfortable.
But I am much less interested in calling that laziness now.
I would rather inspect the system.
How many decisions did I make before I reached the important one? Which choices could have been defaults? Which projects are competing for the same attention? What can I decide once instead of deciding every day?
Those questions usually lead somewhere useful.
The goal is not to become a developer who never gets mentally tired. The goal is to stop wasting the best part of your thinking on decisions that never deserved it in the first place.