Mindset for research, A.K.A How to fail beautifully at your research

Accept that failure is the default outcome

The smartphone above is a Motorola Droid 1, the first generation, also known as A855. This was one of the first things I bought, when I started my postdoc in New York in 2010.

My work involved doing computations on large-memory servers or the compute cluster. So, I just needed a unix terminal to edit code, check results and jobs to see if/how they are running. I didn’t need a powerful machine - this is the same paradigm our lab operates with now. You can just use a laptop and still be productive, and process large amounts of data. With the smartphone as well, I could connect to the server via ssh and work on it if I needed to. To be able to do that efficiently with the phone, I needed a full physical keyboard so that all of the screen would be free, pretty much like a pocket sized laptop. If there was no physical keyboard, the keyboard on the screen blocks all or at least some of the terminal window.

Soon enough I was able to realize the idea of working using the smartphone. My supervisor brought in a new project. He said company X (name removed) produced some cool data, we are the only ones who have access to it, and we can do something interesting with it. The thing we decided to do required a lot of memory and relied on a research software that was not properly developed. This software was developed by another institute, not that we developed amazing software all the time. Since this was a fairly new approach other similar software had same or different problems. The one we picked in the end was the one with the least amount of problems in my opinion. When I tried to process that whole data set with dozens of samples, I realized that my jobs were sporadically getting killed or exiting without any explanation. Although we were trying to figure it out with some IT people, I thought I didn’t have time to wait around for this problem to be resolved by IT. I will just check the jobs every hour and restart them if they are dead. Since the errors are random (not the same data set creates the problem in different runs), things will run to completion in the end. And my new Motorola will be very useful for this task. In hindsight, there could be more efficient solutions to this problem, but they didn’t involve the motorola so I probably didn’t bother with them :)

Now, you have to imagine, there are a lot of things to do in NYC. Much more than you have time or the money for, from restaurants, cafes, broadway shows, bars, parks, shopping to sipping cocktails in a bank vault or experiencing paranormal activities. And I wasn’t alone there, I had a girlfriend, who also found a job in NYC and came with me from Norway. We were doing some of those things that the city had to offer, but there was one problem. My head buried mostly in the phone, checking jobs on the compute cluster and restarting, if needed. You also have to imagine, this is 2010–2011, only 25–30 % of population had smartphones, data plans were not cheap, there weren’t many great apps that are specifically designed to grab your attention and it wasn’t normal to see a bunch people in a restaurant sitting at the same table, all lost in their phones.

To say the least, this was “harshly protested” by my girlfriend. But I had this mad obsession to get this done in this particular way. And, she had to put up with a lot of work-related bullshit like this over the years. But despite that, she got married to me. So at least I had one successful outcome out of this phase of my life.

Anyway, I kept pushing this project, started a draft and was optimistic about finishing it in reasonable time frame. But then, a lab from Boston published a paper seemed to be doing exactly what we were trying to do. I started reading the paper in depth ,and surprise! surprise!! They used THE SAME DATA, THE… SAME… DATA. Apparently, we weren’t the only ones who had access to that :/ Bummer!! For a moment, it seemed like all that work, time, personal and relationship stress was for nothing. We either had to divert into the areas the competing paper didn’t cover and possibly compare our results to theirs, or let this go.

But this kind of thing happened before, I have written full drafts that were never published. In the end, I don’t remember being very worried, I also had other projects, but we will come to that later. In research, things often do not work out at different scales, either small sub-projects fail or the whole project fails. Well, let’s write it down if you didn’t get the idea yet. Failures are the default outcomes of the research projects. But before we move on, let’s change the “failure” with something little more positive. Setbacks are the default outcomes of research projects or sub-projects.

Why we have setbacks ?

Even the most straightforward projects can have setbacks due to circumstances that are out of your control. You can have the perfect code, data and the third-party software but just when you were about to run your analysis, cluster might be down for two weeks or a month or even more.

The setbacks can be in different scales. Like the example I gave above, sometimes you do all the work and the whole project fails, sometimes one part of your experiment or code doesn’t work and you need to fix many of those small setbacks along the course of your project. Smaller setbacks such as experiments not working , mistakes in code are obviously easier to come back from, compared to getting scooped. In general one or combination of the following things can cause a set back a) the idea/hypothesis was wrong, b) implementation is hard and/or you don’t have skills to implement, c) circumstances out of your control.

Reappraise and move on

If the idea was bad, having setbacks can lead to better ideas. The cycle of hypothesis generation and testing is at the core of science anyway. If you have implementation problems, this is an opportunity to get those skill-sets needed for the project, getting new skills should be part of any technical or research based job. The circumstances out of your control teach you to improvise and overcome. If we go back to the example above, the cluster being down for more than a month (this is a real-life example by the way), you can do so many different things to move your project forward in the meantime. You can focus on smaller datasets and improve your code base, you can move to the cloud. AWS, Google and many other companies are providing this service, and your research institute should pay for this, if they keep their cluster down for prolonged periods of time. In addition, you might find compute resources in neighboring institutes or even your previous institute might be generous to give you access. If circumstances are out of your control, you need to improvise, adapt and overcome.

In any case, the general strategy to deal with setbacks is to reappraise the situation and move on. There will be emotions and negative thoughts but you have to let them pass and move on to the next stage of your project or a new project. You can’t prevent negative thoughts/emotions so it is better to stop trying. Wrestling with them only makes them worse. The real problem is when you treat your negative thoughts as indisputable facts and not just ideas produced by your brain. There are two steps you can try to deal with negative emotions and thoughts.

  1. Observe and acknowledge the thoughts, and put some distance to them: Instead of saying “I suck at this, last time it was the same, will never get it right”. Say “My brain is telling me that I suck at this”
  2. Ask “Is it useful?”. Is the thought “I suck at this” useful ? Doesn’t matter if the thoughts are true. It matters only if the thoughts help you get where you want to go.

Repeat steps 1 and 2 whenever you encounter negative thoughts, same thoughts might come back over and over, then you simply repeat step 1) and 2) over and over.

In the “smartphone project” I described above, while doing that project I developed a code base that I knew I could use over and over again in later projects — that was my reappraisal. In fact, some parts of it even ended up in R packages I later wrote. No effort that leads to new skills or knowledge is a wasted effort. I don’t remember having excessive negative emotions, maybe I had some of the appropriate mindset back then or I completely blocked bad parts of this memory :)

Have a plan B

As I wrote earlier, after another lab publishing the same story we had two choices . We either move on to another project or try to differentiate our direction. I had time and motivation to take on other projects. On the contrary to the common belief, bioinformaticians do not sit back and sip their coffee when something is running on the cluster. They have other projects to move on to. So, when the “smartphone project” was running on the cluster, I was doing other projects. This other project was even more motivating for me because it was directly related to a disease and we had patient samples. We decided to fully pursue this instead of trying to push the “failed” paper. This project also had data generated by our close collaborator. This time I knew that it would be harder to scoop this. This project lead to some important biological insights that relate to patient stratification and a software to analyze a specific type of genomic data. This further lead to more applications of the computational methods we developed and additional software and publications for genomic data analysis.

I believe, it is important to think about what you will do, if something goes wrong with your project. Changing direction of a project or business is called “pivoting”. You change your focus or strategy keeping the core of your business or technology. For example, let’s take a fictional company and call it “pied piper”. Now, let’s say this company developed a more efficient compression algorithm. They can use this technology in an online file storage storage business, but if that doesn’t work, they can use it on a video streaming business— both of those things can benefit from fast compression as the data transfer over the network will be faster. Similar things can be done in research projects too. It might be useful to think about how the project can pivot when we experience a setback such as getting scooped or the general strategy is not working as expected. There might be other avenues to explore with the same technology or idea. There could be change in direction in analysis keeping the same data generated.

Talk with your supervisor/PI/manager, what is the plan if things go sideways? Are there other similar or related projects you can work on as back up? Is one of those projects, whatever the outcome, interesting? Can you pivot easily and move the project to another direction?

Don’t spread yourself too thin

During my PhD, I got into many projects. I don’t exactly know how this happened but my supervisor got me into multiple projects that I could help. Some of the projects were just using the methods I developed on different problems, some required a completely new approach. In the end, I think I had about 8–10 publications by the time I graduated and couple more came after I finished my PhD and moved on to other positions. But don’t worry, very few of those papers were first author papers — I’m not that productive. However, this became a problem in the end. To be able to write a thesis, you need a coherent story that is spread over at least 3 scientific articles. At least two first author and at least two of them must be published. I might be wrong about those regulations but it was something similar to this. Of the papers that I published, very few made a coherent story. Therefore, I couldn’t use all the papers and it was a challenge to come up with that coherent story. If I hadn’t spread too thin, I could have avoided some additional stress.

Having a plan B shouldn’t mean you have 10 other projects running at the same time where you do hands-on work. A healthy amount would suffice, and I think that magic number is 2 (without further explanation or reasoning :)

Deal with your procrastination

Dealing with multiple complex projects often results in procrastination, at least for me. There are so many things that can go wrong, thinking about the complexity and the amount of things to do might motivate you to play games on your phone instead of doing the things that needs to be done.

One way to deal with this is to plan and come up with a concrete to-do-list. If your daily to-do-list says, “write the paper” you will never finish that paper. This is too unspecific. You should find smaller sub-tasks that are part of “write the paper” task. What is the first thing you need to do? For me, it would be to decide where I’m going to write the paper: MS Word, Google docs, Overleaf (LaTex). This depends on who I am writing the paper with. Once that is decided, I open the document and give a reasonable name. Now, the next task would be to find a working title. Then, I would put the results in bullet points. I would always organize my to-do-list to small, actionable tasks, and not vague phrases.

In general this strategy is called chunking, where you chunk the work to smaller manageable pieces and prioritize, start with the absolute first thing to do. It takes some practice to figure out what is the smallest chunk that needs to be done first. Books such as “Getting Things Done” and “Kaizen Way” introduce ideas around chunking, in addition to other ways and thinking patterns for organization of your life. Read them if you need ideas about organizing your work.

Have a purpose beyond your personal benefit

Well, facing setbacks repeatedly will drain you at some point. If the default outcome is a setback/failure, that means you will have many of them throughout your career. How you push yourself to do more when every setback will create some level of frustration? And apart from setbacks, you might have family or relationship problems — life is not monotonic or predictable. Circumstances outside work will affect your work.

When failures occur, you can reappraise and move on, but you must have some underlying reason to keep trying. That underlying reason will give you the motivation. That underlying reason is your purpose. This purpose must be beyond personal benefit. Things such as money and fame do not help you achieve outstanding results or help you push yourself when things are tough. The best way to increase motivation is to link your work to this greater purpose. This purpose must be aligned with your core values and must come from within. Core values are the beliefs and principles that matter to you most. When one thinks that their work has a positive impact on others or helps others in some way, this kind of thinking improves their performance. Desire to help others, desire to inspire others, being creative, these are all examples of core values.

In one study from New York University and University of Michigan, researchers realized the hospital janitors who framed their work as minimizing the chance of infection therefore preventing further harm to already vulnerable patients had improved performance and job satisfaction They saw their as an integral part of healing others. The other janitor group did not have such a mind-frame and had lower job satisfaction and performance. In another study, meta-analyses of ~200,000 workers across different industries revealed that a belief that one’s job has positive impact on others is associated with better performance. There are other numerous examples from sports people, pushing themselves in the last minutes of the race or game through pain. Not thinking about the fame and the money they will earn, but thinking about things beyond themselves, such as their family, friends or kids who might be watching this and be inspired to pick up sports.

So I suggest you find whatever core values you have, find out your greater purpose and connect it to your work. That should not be so hard for a scientist. When things are tough, thinking about that purpose will give you the motivation boost you need.

Importance of rest

As a scientist running from failure to failure, you will also need to think about rest. Resting is more important than people think. Phrases like “I will rest when I die” are ubiquitous among workaholics. The general idea about rest after a strenuous mental task is similar to resting after strenuous physical activity such as muscle building. If you want to build muscle, you can’t workout 24/7. You need to workout and let the muscle rest to recover and rebuild itself stronger. So, stress+rest = growth. For your mind as well, the equation seems valid. Small and large scale setbacks you encounter day to day as a scientist as well as the effort you need to put to overcome those setbacks will cause mental stress and depletion. You need to rest to recover. I would suggest even taking a couple off days of after paper or grant submissions as the last phase of those things requires increased effort and causes mental stress. The general idea is that the rest should be proportional to the stress you endured. But also a daily rest routine could be incorporated to your life. Here are some ideas for resting after demanding mental tasks along with their supporting scientific articles.

Reading suggestions:

Most if the ideas here come from personal experience mixed with the ideas in these books. I suggest you give them a chance.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Altuna Akalin

Altuna Akalin

Bioinformatics Scientist, writing about data analysis, genomics, bioinformatics, and science. https://al2na.co