The Scientific Mindset

I earned my PhD at the end of 2013 with a thesis topic on low-level vision science. Obtaining a PhD is a long and sometimes arduous task. One cannot be afraid of digging in and “doing it yourself” – it is that attitude along with a large dose of tenacity and caffeine that can get you to the finish line.

However, the main takeaway from the pursuit of a PhD is the training around how to be a scientist. It is surprising how many people I meet in my day to day who do not think as scientists, so much so I need to change the way I speak with them..

Since my PhD, I have found myself within the domain of software engineering. I originally had aspirations of “doing something” within the field of computational neuroscience, particularly with respect to the visual system. I wasn’t sure exactly what, but I allowed the cards to fall where they would, and eventually I found myself in a small consulting company that was interested in using AI and looking to expand into the tech industry.

A scientist goes about a problem by following the scientific method. First she gathers all known information and constraints — what do we already KNOW about the problem. Next she forms a hypothesis – or an educated guess as to what the problem could be. Next, each hypothesis is deconstructed in a very objective way with a series of what-ifs and expectation of results, without emotional attachment to any outcome. Every hypothesis is controlled very carefully, typically there is one independent and one dependent variable – and in terms of debugging a programmed function, it is a series of very pointed “if/else” questions. Finally, each hypothesis is tested with the utmost rigor. Are we still unable to disprove the null hypothesis?

Background knowledge is essential to being a good debugger. One must fully understand the context of the problem. But even if the entire context is unknown, one is able to find a “hook and line” and follow the problem “backwards” until reaching the point of failure.

Let’s take an example that I am often thrown in at work. As with many companies, we have quite a bit of legacy code we are forced to maintain, only because many vital business transactions and processes rely on this code. On occasion, an issue will popup that no one knows anything about.

In my tenure as a software engineer, I have worked with my fair share of non-scientist developers, with the difference being quite notable. These non-scientists typically are unable to formulate a hypothesis and instead opt to simply code around the issue. Many will offer to refactor huge swaths of code, regardless of the technical debt involved. Of course this is challenged by people like me, and when pressed for follow-up as to why a particular solution is chosen by the non-scientist developer, the answer usually falls flat with a weak “I don’t know” or I’ve even had the person become highly critical of past architectural decisions made by the company. Such non-scientists tend to be more defensive about their code-writing as they lack the ability to defend its architecture and motivation for certain decisions.

Personally, I want “the truth” and sometimes the truth hurts. I’m not the best developer nor the best manager, but I recognize this and strive always towards what is better. I live off of constructive feedback because that is the only surefire way to grow. I owe my scientific attitude to the notion of “the more I know the more I realize I don’t know”. I am never convinced that there is a RIGHT answer – I constantly speculate. Could there be a better solution? Maybe that person knows more than I do, let’s have a listen.

It is important to stay humble and to realize that you don’t have all the answers. Only then is there room for growth. Taking a scientific approach to debugging unleashes the power to debug ANYTHING, for you can simply follow the trail of facts until hypotheses and assumptions are no longer being met.

Surprisingly, I enjoy debugging. I like digging into the unknown and figuring out the puzzle. I like to tap into existing patterns and simply inject a solution into current frameworks (regardless of whether they are “right” or not). I pride myself on finding a bug and fixing it with minimal technical dept. Bug squashing can be a tedious job and its not always fun, like creating something from scratch with all the fancy bells and whistles, but it is inherently satisfying to crack open the code and track down an issue that has eluded others for so long. I can do this because I approach the problem like a scientist, and it is this same attitude that I am always on the lookout for when scoping out others to join the team.