The Ghosts of Software Projects Past, Present, and Future (Again)
Charles Dickens had it easy.
Scrooge was shown the error of his ways, promised to change, and then apparently lived happily ever after.
We all now that Software development doesn’t work like that.
So while Christmas does offer opportunity for reflection as Slack goes weirdly quiet, software devs often use this as a time to brush up on LeetCode or learn a new API.
So let me step in, and again break the pace to visit the ghosts of software projects past, present, and future.
Not for redemption.
Just for honesty.
Projects Past
A few years ago, I genuinely believed that being right was enough.
If the code was good, you’d done enough. Use architecture that makes sense, understand the trade-offs and your team will support you.
Looking back, this was naïve.
Being technically correct doesn’t grant you influence, and seldom even helps the team. It’s influence that actually changes what is important within a team.
Projects Present
The present version of me doesn’t believe effort fixes broken systems anymore.
That’s not cynicism, it’s pattern recognition. You’d think AI would be able to spot this too.
I’ve seen environments where:
deadlines are disconnected from reality
quality is praised but never rewarded
initiative is encouraged right up until it causes inconvenience
In those systems, disengagement isn’t a personal failing. It’s actually a rational response to the situation.
It’s a rational response.
There is lots of chatter and talk about “quiet quitting” and “giving up”, but these are actually self-preservation when viewed from the inside.
The thing is I still care about good software. But I no longer pretend that caring more will somehow overcome the structural issues that exist within software development.
This is selective engagement. I want to make it clear that this isn’t laziness, it’s boundary-setting. We should all think about this going forward.
Projects Future
The future used to feel like something you could engineer if you just tried hard enough. Worked harder. Did better.
We have been told (endlessly) that this is through the following.
better habits
more discipline
cleaner attitude
Now it feels less certain.
I don’t know what the future version of me looks like.
I just know it won’t be the one pretending that burnout is a motivation problem or that resilience is an individual responsibility.
The future probably involves fewer heroic efforts, fewer unpaid fixes, and fewer attempts to save systems that don’t want to be saved.
Not because I care less. But because I finally understand what care costs.
No Redemption Arc
This isn’t a story about becoming a better person.
It’s a story about becoming a more realistic one.
I still want to work with people who care.
I still value good code.
I still notice bad decisions.
What’s changed is the belief that personal transformation fixes structural dysfunction.
It doesn’t.
Conclusion
Dickens gave Scrooge a clean ending.
Software development doesn’t offer that luxury.
There’s no final lesson, no overnight change, no guarantee that next year will be different. Just a slow accumulation of experience, compromises, and boundaries.
If there’s any wisdom in this Christmas reflection, it’s this:
You can change how you show up.
You can’t single-handedly change the system you’re in.
Learning the difference might be the most valuable lesson of all.
About The Author
Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper.
The Secret Developer changed their thinking. It doesn’t often happen, but there it is.