I was recently reflecting on my neuroimaging learning trajectory, and how I would approach it if I had to completely start over. There’s pretty absurd learning curve for fMRI if you’re doing an end-to-end project: you have to learn how to collect the data, organize it, preprocess it, postprocess it for different analyses, and then finally, learn how to implement and interpret all of the analyses that you wish to run. Knowing how to program is basically required (i.e. learn Python), and knowing how to program well will make your life significantly easier. It’s a daunting task.
So, what advice would I give?
Three technical aspects:
- Analyze an open dataset on OpenNeuro before one of your own. Use this dataset as an opportunity to learn how to code your own preprocessing pipeline and analyses. And, because it’s OpenNeuro, you’ll also get a chance to familiarize yourself with BIDS, which will make organizing your own data a bit easier in the future. But most importantly, this exercise takes away the pressure of trying to get things right because it’s not your own project and you can move on at anytime. If anything, failure is welcome here (more on this later).
- Related to the previous point, try and roll out your own preprocessing pipeline before moving onto something like fMRIprep. It’s worth the painstaking labour of chaining together preprocessing steps; you’ll end up with a much better intuition for preprocessing, as well as a familiarity with some of the fMRI packages available (e.g., FSL, SPM, Freesurfer). I would try to do this with the packages directly rather than using Nipype, mainly just to avoid an overwhelming learning curve. Which fMRI package should you use? It depends, but a good rule of thumb is to use the one in which your direct colleagues are using.
- Do your best to follow good software development principles (for resources, see here, here, and several of the materials from here). In my experience, the amount of code you write for a project can completely explode on you if you aren’t organized, which can lead to ugly technical debt. And, you’ll more than likely be stuck on the same codebase for much longer than you anticipated; well-organized and documented code is a blessing for your future self.
Three broader aspects:
- Patience is the most valuable tool for a fMRI practitioner. It can take a long while to learn preprocessing steps or to identify how you should go about an analysis, let alone implement one. If you collect your own data, you’ll likely spend long hours running subjects. Sometimes you’ll run an analysis that takes days to run, only to discover that an error occurred 43 hours in; time to fix it and restart it all over again. Or, a pandemic completely disrupts your research program and you have to pivot. The list goes on. It’s all worth it, but a little bit of patience goes a long way.
- Failure is good. As frustrating as they can get, every error or bug in your code, or setback in your project, is an opportunity to learn. Check out this excellent #FailureFriday thread for some ways in which people have failed and lived to tell the tale (FYI my biggest fail was collecting two costly days of data only to realize after that our in-scanner mirror setup for the subjects had flipped the visual scene upside down. Always check your experimental setup on yourself first).
- Surround yourself with fMRI friends–they are absolutely invaluable to your growth and experience in grad school. They are there to help, share ideas, make the hard parts easier, and celebrate the accomplishments. I’ve lost track of how many times I’ve fixed a problem in a project after a quick conversation. If you’re wanting to grow your network, opportunities like Neurohackademy, hackathons, and simply reaching out on Twitter, are excellent ways to meet new people.