Your code is being sent to the dump.

Don’t take it personally. Your code isn’t bad. It’s just garbage.

Maybe your code wasn’t written the way they wanted you to write it. Or maybe they realized that they had already written this code three months ago. Or maybe the customer suddenly decided that they don’t need their smartphone to emit fragrances based on the text message they just received.

The “why” doesn’t matter. Plans changed. Your unused code isn’t aging well and it’s starting to stink up the place, so just do us all a favor and get it outta here!

As developers, we always take this kind of thing personally. Our code is an extension of ourselves. When we feel good, we write code that’s clean and concise. When we feel meh, our code is unimaginative and takes longer to write. When we feel bad, we litter the code with variables that don’t do anything and then name them after our managers.

But it’s not personal, is it? Management doesn’t sit in their mansion each evening, sipping a gin martini while adjusting their toupee, thinking about how worthless you are and how to properly punish you while continuing to pay you. Management has better things to think about, like ditching the toupee in favor of hair plugs or Rogaine or whatever hair fad is popular that day.

Plans change. You can lament your loss of three days of “ingenious” code that will never see the light of day, but management will be equally depressed about the hundreds (thousands?) of dollars lost paying you to work on something that’s not production-worthy. You may feel cheated in the short-term, but hopefully you can get something positive out of this change of plan. Maybe your second attempt at the code will jive better with the base architecture, or maybe you’ll be able to extract the functionality you need out of another component and limit code duplication, or maybe you’ll be able to deliver a different feature that the customer can actually use.

Sure, there may be an occasional senior engineer who thinks that the program should be implemented his or her way, and will make you throw out anything you write that has any deviation from The Plan (which never quite made it out of their heads and into any documentation). Usually you can satiate that senior engineer by listening to them and nodding your head for a few minutes. There’s a reason that engineer carries so much weight on the project, so they’ll probably be making a valid point while you nod your head and they’ll respect you for agreeing with them, even though you secretly wish you could just keep doing it the way you originally planned.

Don’t cry over spilled milk. No one’s actually questioning your coding competency when they change the plan. The odds are in your favor that the plan changed in the best interest of the project, and whatever code is being thrown out is likely a necessary casualty to benefit the system as a whole. Remember that most of the code you write is used, at least for a little while, so try not to dwell on the code that isn’t.