Dave’s favorite map hangs in the NatCap software offices at Stanford. It’s a map of Mount Everest from a 1988 National Geographic magazine. Click here to view it and other vintage maps from their archives.
Thanks for taking the time to talk with us, Dave. Tell us a little about your role at NatCap.
Dave Fisher: My current role is as a software engineer, and I’ve been doing that for little over a year now. Prior to that, I was a member of NatCap's team up in Seattle, where I was a research assistant and data analyst. My background is in geography, so I still identify as a geographer, but now I’m doing software engineering too.
What brought you into geography as a subject area?
Geography was a discipline that was not on my radar until applying to graduate schools. I had these general interests in earth sciences and the environment and biology. But I just started noticing that some of the grad schools I was interested in had geography departments that looked pretty interdisciplinary and featured a lot of things I was interested in, focusing on earth science curriculum but also cutting across other disciplines. You could study climate, you could study people, you could make maps. There’s a lot of room to explore within geography. So that’s what attracted me to a geography department for grad school. And it turned out to be a great fit. I started studying biogeography and paleoecology, so I was studying how forest composition changed in the Pacific Northwest since the last ice age. After the last deglaciation, how have forests changed? How have different tree species responded to climate? It was a chance to work with those long timescales, which interested and fascinated me. Similarly, large spatial scales—like regional or continental or global—have always captured my interest. Geography gives you the skills to work with those sorts of data sets and answer questions at that scale. So, I’ve learned a lot of really useful job skills studying geography, like Geographic Information Systems (GIS), coding in order to work with large data sets, and modeling. A lot of things that ended up being really useful for my first role at NatCap, and my current one.
It seems like a natural fit with the work we do. How did you end up at NatCap?
After grad school, I saw the posting for the research job in Seattle and it looked like a really good match. I remember writing in the cover letter that I felt I had been preparing for this job all through grad school, even though I didn’t know it existed. I felt I had a really good set of skills that were useful and applicable for working at NatCap.
You decided to transition from your work as a research analyst to being a software engineer. What made you want to make that change? What’s different about the work?
I’d been in Seattle for about four years, and I really liked the team and found the work we were doing to be satisfying and challenging. But, I saw the opportunity to join the software team as a way to throw myself into a position with so much more room for growth. In this new role, I would be learning so much new material about programming and software. I had been gradually learning some of those skills on my own, doing programming as a means to an end for whatever research problem we were working on. So, I had some baseline skills to work with, but I knew that joining the software team meant that I would get to be on a team with people who have been doing this much, much longer than I had been doing it. They had a lot more experience with programming and software engineering. I saw it as an opportunity to work with people who I had a lot to learn from and a chance for me to expand my skills in a different direction. Programming is also fun, so it was a chance to do more of that.
Tell us a little about your journey moving from Seattle to San Francisco. You chose a unique way to get here!
As soon as I got the offer for this position, I immediately started scheming about how I might take a month or two off. In-between the jobs was a great time to do that; wrap up all the responsibilities in one place and take some time off before I start the new job. The wonderful NatCap leadership also supported that idea, so I decided to spend the time riding my bike from Seattle down to Stanford. I left in early August and arrived down here in late September. I explored a lot of the Oregon-California coast on the way, riding my bike for a few hours every day, camping, eating lots of food, sleeping a lot, and meeting a lot of other people on bikes.
What’s one of your best moments from that trip?
There are a lot of best moments. One day of riding that stands out was the day where the route transitions from Highway 101 to Highway 1. That's after riding inland through the redwoods in Humboldt County, CA. So, to go back out to the coast, you turn off 101 onto Highway 1, and you have to go over the coast ranges, and I believe that’s the steepest climb and the most elevation on the whole coast bike route from Canada to Mexico. There are two big climbs. You go up and then down and then up and down again, and that was just a really fun day of riding. I liked doing the climbs, but it was also really rewarding because at the end of that day you’re coasting downhill and the ocean comes back into view and you spend the last couple hours riding south on Highway 1 again.
You spend a lot of your time working on InVEST. Do you have a favorite InVEST model?
It’s hard to just pick one, but if I had to it would be the Recreation model. It’s the first one that I familiarized myself with because we were using it up in Seattle. So first, I was a user of that model. It was my entry point into how InVEST works, because there were times when I was using it and felt I needed to understand what it was doing under the hood. To do that, I went into the source code, and that was the first time where I read some of the Python code that is InVEST and really started to understand how these are models made. Understanding what the building blocks are and how they really work. It gave me an example of what really good code looks like. I had started writing code to work on projects, and my code was a mess in comparison to this high production Python code. So, it was a chance to really understand what goes into writing quality software.
The Recreation model itself is fun because it is a “build your own model” model. The InVEST recreation model is really just a way to acquire data that you as the user then use to parameterize a regression model. It gives you a lot of flexibility. The novelty of it is that it provides this interface to a dataset of worldwide geotagged photos that we use as a proxy for where people visit across the landscape. You can use the model to acquire that data for your area of interest then build a statistical model that helps you understand what’s influencing those visitation patterns. Is it infrastructure? Is it protected areas or biodiversity? In that respect, you’re building your own model out of the data the InVEST recreation model is providing you. And that makes this model potentially applicable all over the world, in many different contexts.
Finally, what’s the thing you like most about working for NatCap?
It comes down to the people I work with, and there are two parts to this. One is that everybody has a good sense of humor and likes to make everyone else laugh, and that’s just fun to be a part of. But at the same time, everyone takes their work seriously. I like to make people laugh and have a good time, but I also like having serious conversations about science and software. I like that I work with people who are down for that conversation at pretty much any time. It’s a good balance of lightheartedness and people who take the work seriously and are here because they have a great deal of curiosity and an eagerness to learn and share ideas. And that’s a great place to be.
Interview with a NatCapper is published quarterly alongside our newsletter. If you have a NatCapper in mind you’d like us to interview next, please contact Sarah Cafasso at firstname.lastname@example.org.