HomeNews and blogs hub

The Coding Scientist I Never Thought I Would Be

Bookmark this page Bookmarked

The Coding Scientist I Never Thought I Would Be

Allen Pope

Allen Pope

SSI fellow

Posted on 5 May 2016

Estimated read time: 6 min
Sections in this article
Share on blog/article:
Twitter LinkedIn

The Coding Scientist I Never Thought I Would Be

Posted by r.silva on 5 May 2016 - 2:23pm

perito moreno by marc cornelis.By Allen Pope, a research associate at the National Snow and Ice Data Center and the Polar Science Center. He studies the Earth's frozen regions with satellite and airborne data, does fieldwork to make sure the satellites have it right, and shares his science with other people. He tweets @PopePolar.

This is the fourth in a series of articles by the Institute's Fellows, each covering an area of interest that relates directly both to their own work and the wider issue of software's role in research.

I love being outdoors. There is just something so viscerally engaging about exploring and studying the environment you’re standing in – all the better if it is a remote, snowy, beautiful location. But I spend significantly more time working at a computer than in the field, and I’m pretty happy about it, too. Why, though, if it was fieldwork which started me out?

I’m a glaciologist and I use satellite data (mostly Landsat 8) to understand how ice around the world is changing. Software is central to my research. My research would be impossible without the computational tools that I use and develop every day.

Why Software?

Ultimately, I’m motivated by particular scientific questions. For example, I want to quantify the volume of meltwater stored on the surface of the Greenland Ice Sheet. To be able to study remote, rugged glacial systems at the regional and continental scales, I need to use satellites, and the the images I use are inherently digital data.

Catching film canisters dropped from satellites using planes was pretty awesome in the 60s, but it’s neither efficient nor practical, and it’s hard to get quantitative data. Because I am working with inherently digital data, that means that I am “forced” to interact with it via software. And just as I chose remote sensing to address particular scientific questions, I also needed to choose (or create) software to be able to find the answers I am interested in.

Choosing Software

There is a LOT of software, so where did I start? When I began  my Master’s, I learned quickly that the software tools I picked up needed to either be available in my academic department or be freely available. Licenses, platforms, documentation, GUI vs. command-line: these all played into the decisions.

What’s more important than just having the software? Being able to learn it! Although potential power is great, do not discount the potential of an intuitive interface, available training courses, and having practitioners readily available. Adequate training and a built-in support system are absolutely necessary for getting the most out of your scientific software tools!

For my work, I picked up MATLAB in little bits and pieces and made a big leap forwards by taking a training course available from the university. Without that I would have been totally lost. But it wasn’t until the middle of my Ph.D. that I realised just exactly how much I was missing out on. Why? Because I started collaborating on code with another, more experienced, colleague. Share your code – even informally! Ask questions! Explore and play around to learn! Suddenly I was discovered new functions, subtleties in memory management, and little tricks that would have been so good to know about a year earlier.

I was lucky in having a Ph.D. advisor who often used quirky software – he found tools that let him compute, plot data, or teach skills in exactly the way he wanted to (like Multispec and ImageJ). So, I was exposed to that as well as the dominant software in the discipline. But research (especially on developing new applications of data!) needs to go beyond the available packages and meant coding and scripting myself. Suddenly I went from being a software user to a (very small time) software developer.

My Own Software

I write very simple code to test out new ideas and assess how well they work, so I have a hard time of thinking of myself as a developer. Nevertheless, through my graduate studies, I ended up writing and contributing to a wide range of scientific code. My results would not have been reproducible or easily scaled up to large data sets without customized code.

Sure – but ‘I’m not a coder’ you might say. Neither was I. Before I started graduate school, I had never coded anything in my life. And it wasn’t even science that introduced me to coding. More than experience, it’s all about being willing to explore, test things, and learn.

Big science means big questions, and big questions require customisation and reproducibility. Now, it seems obvious that I needed to, and still need to, foster a whole new software skill set to succeed as a researcher.

Building A Software Community

Since I’m “just” a postdoc, I am free to admit that I often feel out of my depth on the software developing front. And yet, I’m still writing this essay. Why? Because the solution isn’t to hide away. The opportunity to continue to learn and push the boundaries of what I can discover with my scientific software is something that research institutions, professional bodies, and funding agencies need to acknowledge. They should be working to foster such training programmes and workshops, doing their part to help us researchers push knowledge forwards. However, we researchers must also push ourselves to develop new skills and new opportunities.

There is no reason that researchers should work in isolation. I might be an expert on satellite imaging of glaciers (or at least working towards it), so expertise in computing is a lot to add on top of that. There are so many ways that you can create your own learning and collaborative community:

  • Look out for opportunities from organisations like the Software Sustainability Institute, Software Carpentry, and the Geoscience Paper of the Future initiative as early on in your career as possible.

  • Encourage and advocate for the resources you think you need to be a better software-using and developing researcher.

  • Seek out computing-related sessions and discussion at major conferences.

  • This one might sound silly – but use Twitter! It’s a low-barrier way to get connected to people all over the world. It’s a way to build a community, ask questions, and engage in pith discussion.

Don’t be limited by what you know already. Explore, collaborate, share, build your community, and take advantage of opportunities to let software bring your research to the next level.

Share on blog/article:
Twitter LinkedIn