I would spend all my time wanting things
I’ve spoken to a lot of developers over my time, and by far the most common grievance I hear is that they feel like feature factories — churning out code as fast as humanly possible with no end in sight.
It can all feel rather overwhelming1.
So where does this pressure to deliver quickly come from?
It helps to understand why deadlines are set in the first place. Ultimately, those you produce software for are trying to do one thing: make money for the company. Often, this is incentivised annually through bonuses and salary increases, meaning short-term gains or cost-cutting are favored over longer-term investments.
The impact of these rewards is that those you give your estimates to are, whether directly or indirectly, incentivised to keep your delivery timelines as short as possible.
This is why the pressure to deliver exists, and this is why it will always exist.
By imposing too great a responsibility, or rather, all responsibility, on yourself, you crush yourself
There will always be more work than you can do. There will always be people pushing you to deliver faster. There will never be time to come back and clean things up.
In a way, I find this strangely stress-relieving.
There is only so much we can do with our time. With this in mind, it becomes clear that we should strive to make the best use of that limited time. And the best use of our time is to produce code in such a way that we can produce it faster (or the very least not slower) in the future.
It can be tempting to point the finger at the project manager, your team lead, or “the business”. But if you’re truly honest with yourself, it’s highly likely you’ll realise that you’re the one setting the deadlines — even if you’re setting them whilst feeling pushed into making them as short as possible.
Evil is whatever distracts
When you’re stuck feeling like a feature factory it’s all too common to fall into the rut of feeling resentful and blaming “the business”2. I can hear you crying, “they don’t understand what it takes to make good software!”
You’re right. They don’t.
That’s why you need to give estimates that don’t force you to rush things out the door. That’s why you need to make time for things like unit tests, refactoring, and fixing security vulnerabilities.
If you think a project will take six months and that’s the timeline you suggest, you’ll find you get push back — they’ll ask if you can do it in four. You debate things, and maybe you end up agreeing to five. Things are tight. If you’d said twelve months instead, you’d still get push back — they’d probably have asked if you could do it in ten. Maybe you would’ve ended up on eleven.
The point is, those you’re agreeing on deadlines with are more or less wholly dependent on you when it comes to deciding how long something reasonably takes. The onus is on you to make sure that you factor in what it takes to do the job properly3.
-
It’s a bit cheesy, but all of these section titles are quotes from Kafka. Given the sense of powerlessness that some developers can feel and the bureaucratic nightmare that they occasionally find themselves in, it felt pretty appropriate. ↩︎
-
I chose the title to be deliberately inflammatory and to play into the “us and them” atmosphere that some developers feel. In truth, you’re one team, working towards the same goals. It’s better to view “the business” as colleagues rather than adversaries. ↩︎
-
Sometimes you’ll legitimately want to take the tactical choice. Maybe you have to meet a regulatory deadline, or maybe the business will miss a really important opportunity. But if you do cut corners to get something over the line, know that when you come back to fix it, you’ll have to work twice as hard to make the space — another project is always just around the corner. ↩︎