Summer Students at Sunnbrook Research Institute

I learned something valuable about failure this past summer. From May to August, I worked as a research assistant in the focused ultrasound group at the Sunnybrook Research Institute. The group’s aim is to develop devices capable of focusing ultrasound to specific locations inside of the body to treat diseases including essential tremor, uterine fibroids, and cancer. Some of these treatments are facilitated by microbubbles, tiny gas-filled bubbles injected into the patient’s bloodstream, that vibrate when exposed to ultrasound and enhance the ultrasound’s therapeutic effects. It is important to monitor these bubbles during treatment to ensure, among other things, that the bubbles are in the correct location within the patient. We can monitor the bubbles through the sound waves produced by their vibrations. Using a piece of computer code called a passive acoustic mapping algorithm, we can turn measurements of these sound waves into an image of the positions of the bubbles. It was my task this summer to implement several passive acoustic mapping algorithms on a graphics processing unit — a machine capable of rapid data processing — and compare the performance of these algorithms on experimental data.

This task came with failure. I had to learn the mathematics underlying passive acoustic mapping algorithms by reading academic papers. I would read a paper multiple times and still not grasp its contents. I had to learn how to program a graphics processing unit. I would write a block of code and test it on experimental data, only to watch an image of random black-and-white smears emerge. I had to learn how to compare the performance of different algorithms through quantitative measures of image quality. I would make a conclusion on the relative performance of two algorithms, only to realize later that the results were a fluke of the particular batch of data I had analyzed.

Encountering this repeated failure was demoralizing. I beat myself up over it. Why could I not learn the math more quickly? Why could I not write code that worked the first time around? Why could I not keep myself from rushing to conclusions?

I eventually realized that the problem was not the failure itself, but my interpretation of it. I was taking failure as an indication that there was something wrong with me, rather than seeing it as an inevitable part of learning and creating. Expecting myself to do something perfectly the first time around is as ridiculous as expecting a baby to know how to walk as soon it’s born. I began to take a different view of each of the struggles I encountered while implementing passive acoustic mapping algorithms. Math is not intuitive to human beings. That’s why it took me a long time to understand the papers I was reading. Everyone makes mistakes while writing code. That’s why debugging software exists. Analyzing experimental results with a sober mindset is not a natural skill. Drawing the proper conclusions is part of a scientist’s training.

I understand now that I cannot expect myself to avoid failure, nor is there a reason to beat myself up over making mistakes or falling short of an ideal. This past summer taught me that the correct response to failure is to learn what I can from the experience, and then try again.