Because I’m a physicist by training, I sometimes get asked what I’m doing at a tech company. After all, I spent a huge chunk of my life learning how to be a physicist. Why aren’t I smashing atoms, or making cold things levitate, or finding new things to do with lasers?
First, my training isn’t completely orthogonal to what I do now. As a physicist, I was trained to program. Physicists often run into situations where we need to do a math problem that is way too specific to our situation (so no one has ever solved it before), and way too time consuming to do by hand. So, we program a computer to do our bidding and solve the math for us. Let’s be clear: I’m not a programming ninja like many of the other men and women here, but I do have experience telling computers to sort through large amounts of data looking for something I want to find out.
But we at Knewton aren’t just spending our time programming — we’re doing science! We’re measuring student behaviors, building hypotheses, and testing established theories. We are, in some very real ways, at the cutting edge of educational research, and that’s where my scientific training is useful.
My official job title is “Data Analyst.” I comb through data and try to figure out why it looks the way it does. Suppose we found that students who study in the morning perform better than those who study at night. Why might that be? Are early risers smarter? Or are people who study in the evening more likely to have jobs (and therefore be exhausted at the end of the day when they try to study)?
Could the results stem from a software bug that is erroneously adding questions missed to the time on the clock that we record? Or is there something special about morning study that actually makes it more effective? Should we advise people to try to study in the morning? Or should we use their tendency to study in the morning to infer things about the student and tailor the lessons differently to morning students and evening students?
Programming classes don’t prepare us for these sorts of questions. A social science background might be the most appropriate, but any scientific background helps a lot. A lot of people don’t realize the extent to which research involves asking, “How might I be fooling myself into thinking the data says one thing, when in fact it’s saying something else entirely?”
In my case, I spent my graduate years measuring gravity, which is a very weak force. I spent a lot of time trying to figure out if I thought I was measuring gravity, but was instead measuring static electricity, or magnetic fields, or ground tilt, or changes in temperature, or changes in ambient pressure, or small-scale ground vibrations, or delays in receiving GPS time data, or code bugs, or any of a number of effects that might arise from the particular setup that I was using. My thesis advisor once spent months trying to hunt down an effect that was caused by the university sprinkler system.
In theory, it’s the sort of thing that anyone can do, but in practice, most people just don’t spend much time practicing that sort of careful skepticism, where you look at something that seems to be working pretty well and ask how it might be fooling you, but in science, data that seems to work fine is dangerous. It makes you complacent, and that can make you waste years relying on a bad theory before things get sorted out, usually when your colleagues try to replicate your experiment and find that you’ve made a big mistake.
So, the programmers who come here learn some science, and the scientists learn some programming. All of us exercise our critical thinking skills. Ultimately, Knewton looks to hire smart people and set them on hard problems. We all take our own paths to get here.