In Principle Ubiquity, I discussed how I try to find the most commonly held underlying beliefs. The principles that everyone holds true tend to be the most helpful principles to understand and apply in daily life. Some of them are common and obvious, like generosity and compassion. Some are more difficult to ascertain, but produce very positive results.
While cleaning my house on Saturday, I realized that there is a fundamental principle that ties together my blog on Three Stages of an Argument and Code Optimization. I knew instantly that the underlying principle must be great because it ties together interpersonal communication and coding, two completely discrete areas. Principles that I can use in many different aspects of life are the kinds of principles that I strive to find and apply.
The principle that brings the two together is something we all learn in elementary school: the Scientific Method. I have very clear memories of laminated posters up on the walls of my elementary school classroom with the seven steps of the method. We did about a dozen different experiments to reinforce the method deeply into our heads. It was buried so deep in fact that I didn’t realize I was using it when writing those two other blogs.
The Scientific Method is a structured approach that can fit many different scenarios. It’s flexible enough to be widely applicable, but concrete enough to always focus on achieving results. I’ll go through the steps to show how they correlated to two seemingly unrelated areas.
The first principle is the theory. The theory is the arrow that starts the process rolling. In the case of code optimization, the theory is that there is an area of a program that is not optimal. For arguments, it’s that there’s an area of conflict or inefficiency.
It’s important to note that the Scientific Method forces the very first step to be an observation, not a conclusion. If the first step includes anything related to a conclusion, it will be a conclusion reached before any research or observations are done. This poisons the well, and will cause everything after that point to be flawed.
This is what commonly happens in both scenarios. When you prematurely optimize, you skip ahead of the first step by assuming your section is not optimized before running any tests. In arguments, jumping straight to the conclusion will leave people feeling like their opinions weren’t heard. It’s important to clearly state what the issue is before diving into the rest of the process.
The next relevant step is testing for results. In code optimization, this is where tests are ran to determine how much time is being spent in a given area. In argument resolution, this is where the discussion phase takes place. Only objective observations should be done at this point. If a conclusion is discussed before all data is known, then the conclusion will not fit with the data and be incomplete.
Retesting the hypothesis is the next step. This happens all the time in code optimization. Initial guesses may be wrong, and further tests are needed to refine the location of the under-performing code. This step also happens naturally during the conversation process in argument resolution. This step should also focus on gathering more and more data.
Finally, a conclusion should be reached. The last step of the process needs to taken in all the data and discussions to reach a mutually agreed upon resolution. The measure for this in code optimization is objective and clear because the program will run better. This is slightly harder in argument resolution as the problem and solution are often abstract. In either case, the conclusion has been reached through logical means.
The post Principle Ubiquity: The Scientific Method appeared first on Zach Gardner's Blog.
