The Anxiety of Having Nothing to Do
I’m going to come out and say it. I dislike those *quiet* days in software development. Those eerie quiet days when tickets are finished and all you can hear is the silent cry of your fingers tapping on a mechanical keyboard.
I’m going to be clear. This isn’t the good kind of quiet where everything’s in flow and systems are stable. This is quiet (possibly) before the storm where you know it’s going to come, but you know you need to justify your time not spent solving tickets.
I know the Slack won’t always ping. I know that work isn’t always fireworks and bright lights. Yet it is a problem where there is constant pressure to add outsized value and impact. You should always be doing more, and you should always get more done even if there is nothing more to do.
That Eerie Quiet
When you’ve finished the tickets for this sprint, and there’s no immediate fire to put out you should be making some plans for the future. The Slack channels are silent, nobody is looking for a status update on something which takes a few days to finish.
If you’re anything like me you look around. You read every Slack channel possible. You poke at old tickets. You rename a function that’s been bugging you. You alphabetize imports, like a digital Marie Kondo. Maybe you even start reviewing a PR you know damn well someone else should be looking at. You try to stay useful. But deep down, you’re not fooled. You’re just trying not to look idle.
That’s when the anxiety creeps in.
When this happens to me I start to worry. Is everyone else working on a big future project? At least are they developing something which matters? They’re probably making huge strides in their understanding of programming while I’m stuck refactoring for the sake of mental action (and getting a good number of PRs each week, because they check that).
It’s like burnout, but in reverse. It’s en emptiness masquerading as productivity. It’s doing everything for show while not actually getting the things done that need to be completed.
For me there is the worst part. It makes it hard to get the energy to go into work at all. Just looking at the laptop gives a sinking feeling. Working feels empty and pointless. When there is work to do it feels like there is no rhythm and it can’t be done.
The Myth of “Busy”
We’ve been taught that “real” developers are always in the thick of some grand architecture redesign, some algorithmic masterpiece, or some heroic debugging session.
If you’re not in that state you’re probably not doing enough, you’re probably not good enough. You need to always be doing more, you need to always perform better.
Which is one thing. The problem is that is a complete lie.
Software development, at scale, involves as much waiting as it does working. Waiting on design. Waiting on reviews. Waiting on the product team to decide what they actually want. It’s a system optimized to make you feel bad for not being overwhelmed.
At the same time workplaces treat idleness as personal failure and something you need to fix. Companies expect you to invent work to fill in those natural gaps in work. So we’re back to refactoring code that isn’t broken and pretending it’s urgent.
Meaningful work
This is about empowerment. Software developers are not always able to do meaningful work as they aren’t in the right meetings or have the right friends to be able to bite off those large pieces of work that really make a difference.
Sometimes you’re kept in the dark, told to wait, or only given leftovers. Sometimes the systems are so broken it takes days just to get your questions answered, never mind make real progress.
It’s no surprise many of us develop a kind of productivity imposter syndrome. You start to feel like you’re faking it even when you’re not because the deck is stacked completely against you, irrevocably and forever.
The result
The silence gets normalized. Nobody talks about this stuff, as everyone needs to appear to be busy and show the work they’re doing and the achievements that they are making.
You document your work, because if it didn’t yield a pull request you need to account for your time. You track what isn’t working, slow decision-making, poor communication, lack of visibility. Then you advocate for change, carefully. Nobody wants to hear the full rant in a retro, so you let things go and try to behave normally.
This isn’t what we should be doing. We should be doing better, everyday in every way.
An Alternative
We should take a break.
We shouldn’t pretend we’re busy when we aren’t. Refactoring a refactor isn’t going to impress anyone.
Just don’t do it.
Because if your company has nothing meaningful for you to do, that’s not a reflection on you. That’s a leadership problem. And you’re allowed to be disappointed by that.
About The Author
Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper.
The Secret Developer once created a pull request that fixed a typo in a README just to feel useful. It worked. Briefly.