Post provided by Gergana Daskalova

Brainstorming ideas at the Ecology Hackathon in Ghent.
Brainstorming ideas at the Hackathon.

Imagine an ecologist. Now imagine a programmer. Did you imagine the same person? If you were at the Ecology Hackathon on the day before the Ecology Across Borders (#EAB2017) conference in Ghent, Belgium (a joint conference between the BES, GFÖ, NecoV and EEF), you probably did (or at least we hope you did!).

Ecology is becoming increasingly quantitative and, as a result, we can add one more item on our daily to do lists as scientists:

  • Think of questions
  • Go on fieldwork / run simulations
  • Supervise students
  • Meet with our own supervisors
  • Teach
  • Write articles and review manuscripts
  • Answer emails
  • And now code as well

A Coding Community

Coding doesn’t need to be a lonely activity – one of the areas where it truly shines is collaborative coding. This can take us across borders and bring us together to figure out the best way to answer our research questions. That is exactly what the EAB Ecology Hackathon set out to do.

I started my PhD in autumn 2017 and I am now part of a very quantitative group: Team Shrub at the University of Edinburgh. We often take on coding challenges or little hackathons (that sometimes grow into big ones). My own love for coding has inspired me to coordinate Coding Club – a peer to peer initiative aiming to help people get over anxiety about statistics and fear of code through workshops and online tutorials. When I saw that there was going to be an Ecology hackathon at the conference, I immediately knew I wanted to be a part of it. So through snow and some travel delays (nothing compared to other people’s!), I made it! A room full of ecologists keen to take on a coding challenge.

The Ecology Hackathon

The hackathon began with a talk by Maëlle Salmon about how to develop good R packages for open science. You can find Maëlle’s workshop materials on her website. I enjoyed learning about the R packages that can make making your own packages a smoother process and, as someone who is about to set out to making an R package, I found all the links and information Maëlle provided very useful.

Team grabr
Team grabr

Next, we split into groups based on the challenges we wanted to tackle – they all involved making a package of some sorts. The challenges were suggested by people in the ecology/evolution community who knew about the hackathon in advance (although not all of them were able to attend), so they stem from our needs for certain tools that would facilitate our research.

‘Downloading’ was a common theme. With the growing support for open science and freely available data, we need to have an easy and convenient way to make use of all the data out there. What do ecologists want to download? CITES data, Flickr images, plant functional trait data, and much more. The group I was a part of worked on a challenge based around downloading data from multiple different gridded datasets (more on that below).

Towards the end of our Hackathon day, we all gathered to briefly present our work. It was inspiring to see how much progress people managed to make with their Hackathon challenges in just a day – some of the groups were close to finishing their R packages!

Grabr: How to Harmonise Gridded Datasets

One of my favourite things about coding is how it can simultaneously be very intense and great fun! As a group, we started by talking about our background and previous experience with coding, GitHub and package making, and then we brainstormed ideas about our package.

grabr stands for GRids Across Borders + r at the end because it’s in R and it sounds cooler that way.
grabr stands for GRids Across Borders + r at the end because it’s in R and it sounds cooler that way.

Our goal was to create a package through which we could download gridded datasets from different sources – the user could specify the data source, the variables of interest, and then our grab() function would download them for the specified spatial and temporal extent. It would then have a harmonize() function through which you could arrange all the raster tiles into a brick. Often people need more than one dataset or more than one variable, so it would be great to have a convenient way to download and harmonize all of those data. Inspired by the conference theme, we thought of our package as a way to bring together GRids Across Borders, which was the inspiration behind our package name, grabr.

We filled up our board with names for functions, how they could work, and the many datasets they could access.
We filled up our board with names for functions, how they could work, and datasets to access.

When people who have never met before come together to code, one of the potential challenges is balancing different experience levels and expertise in different areas. In the grabr team, not all of us had worked with gridded datasets (but we know we will be working with them in the future). Some of us were just keen to find out what making an R package is like and some of us, including me, chose this challenge because it is indeed a challenge. The mix of expertise and experience in different areas turned out to be a real asset to the team. Coding for the first time can be scary and intimidating, but the EAB Hackathon did a great job at keeping a friendly atmosphere, where we all had the chance to contribute.

Our grabr group is keen to continue working on our package. There’s more code for us to figure out, but we’ve talked through the main functions we want and how they will be documented, we’ve written some of those functions, and hopefully, one day, grabr will be real! We also reached out to the Twitter community to ask what gridded datasets people would like to have easy access to. We were thrilled to receive tens of responses (thanks to everyone who responded, by the way) – sounds like grabr would be a useful tool for many of us!

Figuring out how to download data from the CHELSA climate database (
Figuring out how to download data from the CHELSA climate database (

Final Thoughts on Collaborative Coding and the Hackathon

Making the most of a Hackathon experience, in my mind, relies on a mix of:

  • Bravery (to actually show up and engage, regardless of your current coding level)
  • Creativity (to find efficient ways to tackle problems or to even imagine what problems the future package users might encounter)
  • Skills (to actually do the coding and write the package)
  • And finally, Initiative (to foster and maintain bravery, creativity and skills in the team)

Not every member of a Hackathon team needs to be equally proficient in all of those areas, but through our collaborative work, we can all improve where we feel we need to. Imagine all the R packages we could make, and the questions we could answer, if we were all working together on the code!

Follow Gergana on Twitter at @gndaskalova and Team Shrub at @TeamShrub