Hacking Science has, after just two events, garnered a lot of attention on campus. In this post, I would like to describe what we are trying to do with Hacking Science, and outline some of the rules that I think should guide us.
In a nutshell, we want to create an ecosystem at Penn State for people to connect with each other and learn about the opportunities and challenges in the space where coding, big data, and scientific research come together. As a consequence, the success of this mission is completely dependent on our ability to build and maintain a community that is actively engaged in Hacking Science. We are planning on having regular events (meetups, unconferences, hackathons) to further our cause and grow this community.
Most people get Science, but what about the Hacking? Hacking Science can be interpreted in two ways: Hacking the Science, or the Science of Hacking. It really doesn’t matter that much. Hacking has often been associated with malicious intentions, but this type of definition for hacking is becoming increasingly outdated. Hacking has become a generic term to describe the process of finding creative ways, often involving coding, around an existing problem or roadblock. From hacker news to mind hacks to hackathons, the word hacking embodies the spirit that problems can be (and must be) solved with software and science. It is in this spirit that we use the term.
I’d like to outline a few basic premises of Hacking Science that I think we as a community must embrace (indeed not only embrace, but champion). In the first Hacking Science meeting a few weeks ago, I presented the following list of “rules”: 1. Forget that you are in academia, 2. Don’t wast time on definitions, 3. Welcome failure (and fail fast), 4. Change your mind often, 5. Ideas = 1%, Execution = 99%, 6. Share widely. To this list I would now like to add the 0th rule: talk about Hacking Science. None of these ideas are mine, let alone new, but let me still say a few word about how they relate to Hacking Science.
0) Talk about Hacking Science
In obvious reference to Fight Club, the 0th rule of Hacking Science is that you should talk about Hacking Science. Can you imagine what an amazing community this would be if everyone would know about this community? It’s probably a conservative estimate to assume that 1 out of 50 people on campus are interested in the themes of Hacking Science – that translates into 1000 people. Imagine we would get all of these people together, interacting with one another, sharing knowledge, and building great things. This can happen, but only if everyone knows about Hacking Science. So please tell your friends and colleagues about Hacking Science. A few tools:
1) Forget that you are in academia
Come as you are. Perhaps you are an undergraduate or graduate student. Perhaps you are a staff or faculty member. Perhaps you are a postdoc, or the president. Perhaps you are associated with departments, and perhaps your are majoring in some field of expertise. Great. Now, what can you bring to the table? What interesting problem, tool, solution, method, data set, skill set etc. do you have? What are you passionate about? At Hacking Science, we are all about solving problems. We are interested where you are going, not where you are coming from. What you should not forget about academia is that you are surrounded by an amazing group of very smart and interesting people.
There has been a lot of talk about the idea that going to college is somehow outdated. Take a look at a recent article in the NY Times, “Saying No to College”. The article starts by highlighting the case of a CS student who has had a frustrating college experience:
Two years ago, Mr. Goering was a sophomore at the University of Kansas, studying computer science and philosophy and feeling frustrated in crowded lecture halls where the professors did not even know his name.
“I wanted to make Web experiences,” said Mr. Goering, now 22, and create “tools that make the lives of others better.”
While most of us have experienced firsthand the frustration that large and crowded lecture halls can bring, this should not interfere with the motivation to make Web experiences and create tools that make the lives of others better. A research University like Penn State is full of people who want to make the lives of others better, and who have the projects to do just that. What many of them probably need – often desperately so – are motivated people with coding skills who can help them with these projects. Come to think of it, this would be a good measurement of success or failure for the Hacking Science community: if a motivated CS student with coding skills leaves the University because s/he thinks there are no opportunities to build tools that make the lives of others better, we will have failed. (If you are currently one of these students – please get in touch with me. I am working on many projects that are designed to help us reduce the burden of infectious diseases, and I very much need your help – your coding skills are a great asset.)
Even if your first priority is building a start-up, heed the advice of VC / startup Überlord Paul Graham expressed in a recent essay “How to get startup ideas”:
The clash of domains is a particularly fruitful source of ideas. If you know a lot about programming and you start learning about some other field, you’ll probably see problems that software could solve. In fact, you’re doubly likely to find good problems in another domain: (a) the inhabitants of that domain are not as likely as software people to have already solved their problems with software, and (b) since you come into the new domain totally ignorant, you don’t even know what the status quo is to take it for granted.
So if you’re a CS major and you want to start a startup, instead of taking a class on entrepreneurship you’re better off taking a class on, say, genetics. Or better still, go work for a biotech company. CS majors normally get summer jobs at computer hardware or software companies. But if you want to find startup ideas, you might do better to get a summer job in some unrelated field.
Or don’t take any extra classes, and just build things. It’s no coincidence that Microsoft and Facebook both got started in January. At Harvard that is (or was) Reading Period, when students have no classes to attend because they’re supposed to be studying for finals.
This is exactly what Hacking Science should be very good at – providing a forum for a clash of domains. Getting people exposed to new fields, getting them to work together. Build things.
2) Don’t waste time on definitions
In order to heed this advice, I’ll keep this section very short. It’s easy to get dragged into endless discussions on definitions. In the scientific world it is of course very important to specify exactly what you mean. But as a community, it should not be our first priority to spend too much time on thinking about clear definitions for terms like data science, big data, hacking, etc.
3. Welcome failure (and fail fast)
One of the most inhibiting features in the academic world is an excessive fear of failure. What’s wrong with being wrong? Not much, if you adapt quickly. In academia, people get easily attached to their ideas. This is probably true in general about humans, but it seems to be pervasive in academia because ideas are highly valued (see rule 5). If you have a great idea, you’ll be considered creative and smart – the idea might even be given your name. Many scientists will defend their idea to their deathbed (as Max Planck drily noted, science advances one funeral at a time). The reason for this is that the marketplace for ideas in the world of science has a very different time scale than the marketplace for ideas in business. If your scientific ideas are wrong, they will eventually be overturned, but this process might take decades (especially if they are hard to verify empirically). If your business ideas are wrong, you will go out of business in a matter of months or even weeks.
What’s more, science is a game of rejection. Reading the scientific literature – or worse, the scientific press – you would think that all these successful scientists out there have had brilliant ideas, executed them flawlessly, and the world came to cheer them on. If you think like that, you are falling victim to survivor bias – a distorted view of reality because you are only looking at a small, successful subset (akin to believing that dropping out of college is necessary for jobsian or gatesian success). Most papers get rejected. Most grant proposals get rejected. Indeed, there is even good evidence to suggest that most current research papers are wrong. And yet, scientists fear failure like almost nothing else. I suspect that the temporal dynamics play a huge role here. If you are working on a paper for two years, or if you grant proposal would fund your lab for another five years, people are understandably concerned if things don’t work out. The fact that their career is tied to these things doesn’t help.
In the Hacking Science community, we don’t have these issues, and we therefore should take advantage of that and embrace failure – and try to fail fast. If you build something in code, and it doesn’t work, fix it and move on. If it works but nobody wants to use it, move on. The faster you recognize this, the faster you will make progress.
It’s helpful to envision progress as moving along on a landscape, trying to find the highest peaks (where higher peaks mean more success, however you want to define success). In evolutionary theory, this concept is known as the fitness landscape on which populations of genotypes are pushed around by various forces, most famously by natural selection. If you are moving in a certain direction and you realize that you are actually moving away from a peak, you should change the direction. The faster you realize that you are going away from a peak, the better (this is not always true – sometimes you need to cross a valley to reach an even higher peak on the other side). Embracing failure simply means that you are not terrified of making the wrong move – you simply make the move, and then assess the situation objectively. If you realize you’ve made the wrong move, great – you now know more than you did before. Crucially though, you now need to act – and that often requires that you are willing to change your mind.
4. Change your mind often
Jeff Bezos has famously said that “people who were right a lot of the time were people who often changed their minds”. This makes complete sense if you think about moving along on the landscape envisioned in the previous paragraph. After you’ve made a move and realized that it was wrong, you just change your mind and move into a different direction. Simple, right?
Turns out that this is easier said than done. It’s hard to change your mind when your mind has already decided what’s right. It doesn’t always feel good either – if you change your mind often, doesn’t that mean you’re wrong often? If so, then what can you rely on, if you can’t even rely on what you think is right? What’s more, our culture doesn’t always value when people change their minds. We love people who stick to their guns. We love stories where people’s views were ridiculed at first, only to be vindicated after a long time. This is especially true in science – the real scientific hero in our culture is the one who is fighting an uphill battle his entire life, only to be vindicated in old age (being vindicated after your death makes for an even better story). But while these are great stories, they suffer from the same drawbacks as the stories of Jobs, Gates, et al. – survivor bias. We have yet to see the Hollywood movies of those guys who, in the face of increasingly contradictory evidence, never changed their minds, and in the end turned out to be… wrong.
Imagine you are at some random point in the landscape. Your goal is to get to the peak. You don’t know where the peak is, but you have the tools to measure your altitude. So here’s your strategy: measure your altitude, make a move, measure your altitude again. If it has increased, you keep moving in that direction; if it has decreased, you change direction. If you keep doing this, you will eventually get to the peak. The main insight here is that almost all moves will lead to an decrease in altitude – most of your moves will be wrong. And yet, if you keep measuring objectively, and instantly react based on these measurements, you will eventually get to the peak. You could argue that random movement is not an efficient strategy overall, and I would agree – on your way to the peak you would be overrun by people who have better intuitions for the next move pointing upwards, and by people who are smart to figure out patterns in the landscape. Nonetheless, even these people will make a lot of moves that are wrong. Eventually, the first person to reach the peak has perhaps a number of properties – smart, motivated, lucky, etc. – but the one property you are guaranteed to find is the ability to change mind often.
5. Ideas = 1%, Execution = 99%
This one is really simple. Having the idea of starting a Hacking Science community, or the idea to write this blog post, was easy. Getting things organized, spending hours and hours writing the damn thing, however, is painful. Nevertheless, you wouldn’t be reading this without me writing it (I told you it’s simple). You wouldn’t have attended a Hacking Science event without someone organizing it.
Despite the simplicity, it is astonishing how easily this is forgotten. In science, this is particularly true, presumably because the scientific idea is more glamourous – your name will be attached to an idea, not to the conclusive empirical evidence supporting the idea (see the example of Albert Einstein – but careful of survivor bias). Darwin is famously remembered for the best idea anyone’s ever had – when really it is the 20+ years of work it took him to collect some evidence to support the idea that did the trick. Don’t get me wrong – execution without an idea is bound to lead to failure. But idea without execution (or with bad execution) leads nowhere. Derek Sivers offers a great analogy:
It’s so funny when I hear people being so protective of ideas. (People who want me to sign an NDA to tell me the simplest idea.) To me, ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions.
6. Share widely
Share your data (e.g. on ScholarSphere). Share your code (e.g. on GitHub). Share your science (by publishing in open access journals). A Hacking Science community can only thrive as a sharing community. Almost all of the tools we are using are open source. It’s really a no brainer.
(written by Marcel Salathé)
Have you truly just read more than 2,500 words? If you are still here, you should probably follow HS on Twitter, and subscribe to the email list.