I think that your profession can affect the way that you think and interact with people in your every day life.
For example, my mother was trained in analytical chemistry and did a fair amount of work for her doctorate as a C++ coder. Conversing with her was (and still is) always fun. But there was one pattern kept popping up in our conversation that took me some time to adapt to: if I ever asked my mother to guess at something, she would refuse to do it. Why guess at a quantity? The appropriate response to an empirical question is to make a measurement or look up a previous measurement.
Of course, I then went into physics where the art of guessing is honed and celebrated. I learned to use dimensional analysis and to do back-of-the-envelope calculations. I learned to calculate lower bounds and upper bounds. I learned to estimate my probable error in terms of factors of 2 or 10. This training made the difference between my mother's refusal to estimate and my love of estimating stronger.
But while I was completing my doctorate and then during my post doctorate and as a full scientist, two things happened. First, I started to move from theoretical physics to applied physics. I started working on material science problems. Just as importantly, I began to spend more and more time coding.
In our material science applications, guessing was worth while. But it was always based on simplifying assumptions. So guessing was just a first stab. Truth would reveal itself as we actually performed experiments.
If you were guessing, you might guess that programming would be one place where theory and practice are the same. The computer does what you tell it to do, no?
In practice, programming is an experimental science. You write code and then you check to make sure that it does what you hoped it would. You make a guess, and then you check that guess. If it was wrong, you tweak things and try again.
In other words, a programmer is constantly applying the scientific method. They form a hypothesis. Then they check that hypothesis. They form a new hypothesis and test that one.
So both scientists and coders are professional practitioners of the scientific method. The difference is that coders perform many iterations of the method per hour. Scientists, because they're interacting more closely with nature, are often forced to iterate much, much more slowly.
But the power of both science and programming is that they tell you when you're wrong. And you find out that you're wrong, or at least missing part of the picture, often. In programming it might be 100 times a day or more. If learning that you're wrong 100 times a day and then going back to fix the issue doesn't teach you mental humility, what does?
I actually still believe in guessing, but not as the right way to answer questions. Guessing is powerful as a way to measure your current state of knowledge. If you make a measurement without a guess, then you can't be wrong. And being wrong helps you learn. So oddly I believe in guessing as a way to find out if you're wrong.
Fine. But what does being wrong all the time have to do with BrightHike?
BrightHike is built upon the assumption that we can and will be wrong. It's built on the idea that assumptions need to be checked.In other words, rather than assume that a person is at a certain point in their understanding, test that. Rather than assume that a video helps someone understand a particular concept, test its effectiveness. Every interaction gives us information about our system and about where the user is. Every interaction can be used to check our assumptions and improve our process. Rather than assume that a best practice is a best practice, find out.
