The Delusion of Perfection
The Delusion of Perfection
Zone Leader Matthew Casperson continues his series on developer work in the enterprise, and why working late nights may not be the best move.
Join the DZone community and get the full member experience.Join For Free
10 Road Signs to watch out for in your Agile journey. Download the whitepaper. Brought to you in partnership with Jile.
Casper’s eighth rule of enterprise is:
The only reward for solving a problem on time is a harder problem and less time.
It’s 5 PM Friday afternoon, and I’m still at my desk coding away. I just need to get this last problem solved before I can go home. The light at the end of the tunnel seems so close, and yet I just can’t quite seem to reach it.
In my mind I have this notion that all I need to do is solve this problem and then... and then what? Until now I have never asked that question.
I suppose I think that once I have solved this problem I’ll earn some much overdue external praise, internal gratification or maybe just a reprieve. Yet as I list these perceived rewards for my hard work and overtime, I realize just how ludicrous they are.
I don’t get external praise and internal gratification, because the only person to take my hard work for granted more than those paying me to do it is myself. And a reprieve? Forget about it. Anyone who can deliver a successful result in a reasonable timeframe is immediately tasked with an even more complicated project and less time to do it in.
I’ve come to accept that the notion that somehow things will be better, or even different, "if I can just solve this one problem..." is a delusion that I have allowed myself to believe for many years. It has led to many late nights and weekends spent hunched over a keyboard, and all because I have this laser-like focus on the problem in front of me to the exclusion of, well, reality itself.
Not that losing yourself in the moment is actually such a bad thing. Getting into the flow is one of the more enjoyable aspects of being a developer, and is widely recognized as being an essential part of building effective software teams:
The people that work for you need to get into flow. Anything that keeps them from it will reduce their effectiveness.
But getting into the flow is one thing. Burning the candle at both ends is another. This distinction has been a lesson I have learned (and am still learning) the hard way.
Ultimately it is a realization that there is never any end to number of problems you could be solving, or the scope of those problems. Software development is one of those professions that demands a level of expertise that is impossible to attain, so it's easy to lose yourself in the infinite road ahead, if only because the road behind will always seem so short in comparison.
All I need to do is solve this problem and then... I’ll move on to the next problem from an endless to-do list without so much as a pat on the back or a second to catch my breath.
And I’m OK with that. As long as the problems are interesting, I’m learning something new, and the end result of my work has some kind of value once I’m done, then this treadmill is not a bad one to be running on. The realization that nothing actually changes when I solve this problem simply means that I can’t justify staying at my desk after 5 PM quite so much.
Opinions expressed by DZone contributors are their own.