Reversibility
This site utilizes Google Analytics, Google AdSense, as well as participates in affiliate partnerships with various companies including Amazon. Please view the privacy policy for more details.
Sometimes, you want to try something. But you’re not sure it’s going to work. You’re afraid that if you try the thing, the effects will be permanent.
Maybe the thing is a new route to work. Or maybe a new food. Or perhaps it’s not a new thing per se, but rather something you’re not sure how to do. Like change the brakes on a car. Or write a story. Or something much smaller - spell a word. Use a new API in your favorite programming language.
Should you do the thing?
I often will do the thing. And there’s a concept I call reversibility that gives me the confidence to at least try it.
Reversibility is how undoable the thing is once you do it.
For instance - if you spell a word wrong, how easy is it to go back and try again? If you spell something wrong in Microsoft Word, can you change it?
But reversibility expands to much bigger things than merely spelling a word. Say you’re tasked with a new, well, task at work. You have an idea how to do it, but you’re not sure if that idea will work.
Should you seek validation from someone - ask someone - if that idea will work? Or should you just try it?
If the idea is 100% reversible - then you should do it. The only thing about the idea that’s not reversible is the time spent - but you’re going to spend that time anyway. And if you’re waiting for input from another person, chances are the time spent implementing the idea and then undoing it will be quicker than it takes the person to respond.
I’m a software engineer by trade. A computer programmer. A lot of the work I do is reversible. For example, say I need to display some data - say, the weather over the past month - in a nice little table. The business folks, for whatever reason, want me to submit a “solution design” and get it approved before I begin any work.
I’ll make that solution design, but I’m not waiting to get it approved before I begin working on the solution itself. Why? Two reasons: One, I’ve never had a solution design denied, so the odds are pretty good the next one will be approved. And two, if it gets denied so far as that my work is “wasted” - well, I would have been sitting around doing nothing anyway, except now I have a better understanding of the code base, and none of my work ends up anywhere near any deployments anyway, so it’s 100% reversible.
I can see instances where things aren’t completely reversible. Say you’re a machinist making widgets. You submit your solution design and begin working. For whatever reason, your solution is denied. Now you have a bunch of scrap that you can’t use - you can’t unmake the widgets.
As a machinist, you could figure out what parts of the solution design are reversible. Perhaps you could set up the machine to make the widgets, but don’t actually make any widgets. Or make sure you know how to use the machine, and refresh you skills a bit if it’s been awhile for that particular machine.
So next time you want to - or need to - try something, keep this idea of reversibility in your mind as a tool to help you on your way.