If I had to give you one skill that separates an experienced developer from a junior it’s this...
Realising you’ve gone in the wrong direction and knowing when to backtrack.
When I look back at my early years I can think of many times where I fell foul of this. Maybe I was writing an old webform page or whatever and for whatever reason, the code became complex and before long was infested with local variables with names like isInEditMode, hasPopulatedGrid, needToRefreshGrid etc. Then comes that moment of realisation - this isn’t the best way to code this. That at some earlier point I made the wrong coding decision and now I’m in a right mess.
We’ve all been there. Many times. Don’t trust a developer who denies it. The question is rather, did we learn from it? Sometimes I’ve doubled down and ploughed on. Perhaps setting the needToRereshGrid in the onItemDataBound event will fix it? But, Sometimes I’ve backtracked right out and refactored the whole thing despite the sunk cost. And you know what I’ve learned after all these years? It overwhelmingly likely that backtracking is the best option. A better way to think of it is you’ve actually spent time working out the best way to do it.
The sunk cost fallacy is a powerful adversary with many allies. It can be embarrassing to tell you coworkers that that form you’ve been working on is going to take a couple more days - that you’ve wasted time. Perhaps a deadline means you can’t spend the time to refactor. Or the code really is short term and will never need maintaining. I'm certainly not saying that you should always refactor. We must be pragmatic and serve the greater goals of the project.
But, if you can take the time to refactor, you’ll likely find that you’ll finish the task sooner anyway. There are times where, after ploughing on and finally getting it working where I’ve thought ‘that codes a pile of technical debt and I’d have done it quicker if I’d refactored it two days ago’.
The counter to the sunk cost fallacy is surely the maxim 'Always leave code in a better state than when you found it". I hope you work in an environment that understands that sometimes we need a refactor to fix the smallest of bugs.
Top comments (0)