As a writer, architect, and manager, I am always looking to improve my communication because I sometimes experience that what I say and how people respond are out of synch and I firmly believe in the presupposition that “The meaning of any communication is the response it elicits, regardless of the intent of the communicator.” (Robert B. Dilts, et al.), which is why I was watching How to Be More Articulate (Structure Your Thoughts With 1 Framework), where Vicky Zhao mentioned “…Jeff Bezos’ famous Reversibility Decision Making Framework, is asking if I choose to do this. Is the result reversible? If yes, we should do it. If no, then let’s think about it deeply.”
This was the first time I heard of the “Reversibility Decision Making Framework”, though it perfectly describes the approach that I started following on my own at around the same time Bezos was running Amazon from his home. It is how I learned to manage computers, then networks, then scripting, then programming, then team leadership, and (eventually) architecture. I had no formal education in these areas, and at the time of learning them I had insufficient funds for books, let alone trainings.
I did have a computer (that took two years to pay off), an internet connection (at 14400 baud), and curiosity. After a couple of painful (and unplanned) lessons on how to re-install Windows and restoring a network from back up tapes, I began looking for ways to back out mistakes before I made them. After adding that small step to my process learning moved forward much more rapidly.
We all know that it is much faster to learn by doing. What many people I know fear (all of whom have extensive formal education in IT and related topics) is learning by what is often referred to as a “trial and error”, or what I prefer to call “trial and success”. If you have a safe sandbox to work in, doing something is much more efficient and effective than doing nothing until you are certain of the outcome.
The other habit that helps with trail and success is small increments. Sure, in the bad old days of punch cards or paper tapes it was necessary to write the entire program before running it. But modern IDEs make it trivial to run small pieces of code, and some simple discipline in planning your work can make it easy to test your code a line or a method at a time. Essentially, when not certain how a particular approach will work, rather than spending hours looking for “proven” solutions (that still might not work in the specific context), take your best guess and see how it works.
If the “proven” approach fails, it is likely one of many and finding which failed where can be a daunting task, where figuring out a better solution to the one you wrote 2 minutes ago is generally much easier and less stressful. Sure, there are few feelings better than writing dozens of lines of code in one session and having it run perfectly, but it feels so good because it happens so rarely. Writing two lines of code and getting a result is motivating, because even if it fails you have an idea of where to go next, and when it succeeds there is still a good feeling. Those little successes will easily total up to a higher overall sense of satisfaction than the one big one.
Pro tip: VirtualBox is a free virtual machine platform with lots of pre-built machines available at no cost. It is easy to learn the basics of how to use one and once you can, you have endless environments that you can completely destroy and start over again in the manner many games let you re-spawn where you left off instead of having to start over.
Humble PS: As illustrated by the feature image for this post, I am still trying to get the hang of prompting for image generation 😛
© Scott S. Nelson
