The Underrated Skill in Environmental Science Right Now
There is a skill that I think is quietly becoming the most valuable one in environmental science, and it is not the one most early career people are being told to invest in. It is not coding, exactly, though coding is part of it. It is not field experience, though field experience is part of it too. It is the ability to sit comfortably in the space between the two, and to translate honestly in both directions.
I want to make the case for it, because I think the field is undervaluing it, and because I think the people who develop it are going to have unusually good careers.
The standard advice given to environmental science students right now is some version of "learn to code." It is good advice as far as it goes. Python and R and SQL are real tools, and the ability to use them is a real advantage over a scientist who cannot. But I want to push on it a little, because in my experience the bottleneck in most environmental data work is not coding ability. It is the gap in understanding between the people who collected the data and the people who analyze it. A pure coder who does not understand what a transect is, or why a particular site is hard to sample, or what the difference is between a colony and a fragment, will produce technically correct analyses that miss the point. A pure field scientist who cannot work with the data computationally will produce careful observations that get bottlenecked at the analysis stage and never reach their full potential. Both halves are necessary. Almost nobody has both.
The people I see thriving right now, in consulting, in agency work, in the better restoration programs, are the ones who can do both halves at a credible level. Not at a world-class level in either, necessarily. But credibly. Enough that when they sit in a meeting with field staff, they can ask the right questions about how the data was collected. And when they sit in a meeting with analysts, they can ask the right questions about how it is being modeled. That bridging role used to be a nice-to-have. It is becoming the actual job.
A few reasons for this, I think.
The first is that environmental datasets are getting more complex, faster than the institutions producing them are adapting. Remote sensing, sensor networks, genetic data, automated image classification, all of these are producing data volumes that the traditional spreadsheet-and-statistics pipeline cannot handle. Programs that used to be able to get by with a single analyst running R scripts now need actual data infrastructure. But the people who know how to build that infrastructure mostly come from outside the field, and they often do not understand the science well enough to build it right. The result is a lot of expensive, well-intentioned infrastructure that does not quite serve the work.
The second is that environmental decisions are getting more consequential, and the standards for defending them are rising. A monitoring report that goes to a regulator now is held to a higher analytical standard than it was ten years ago. A restoration program that wants to keep its funding has to make a more compelling, data-supported case than it used to. The work that holds up under that scrutiny is the work where the science and the analytics are tightly integrated. The work that does not, is not.
The third is that AI and automation are removing the low end of both jobs. Routine field data entry is being automated. Routine statistical analysis is being automated. What remains, on both sides, is the judgment-heavy work. And judgment-heavy work, in environmental science, almost always requires understanding both the system being measured and the analytical method being used. The pure technician, on either side, has a shrinking job. The translator has an expanding one.
The implication for early career scientists, if I am right about this, is worth thinking about. The advice to "learn to code" is good but incomplete. The fuller version is to learn to code while staying close to the work. Spend time on boats. Spend time in labs. Spend time on transects. Whatever your specific corner of the field is, do not abandon the field part of it just because the analytical part is where the perceived prestige is. The combination is what is rare. The combination is what is valuable. A marine biologist who can also build a clean data pipeline is more useful than two separate people, one of each. Not because they replace those people, but because they can integrate the two halves of the work in a way that pure specialists cannot.
The implication for programs hiring is also worth thinking about. If you are a research program or a consulting firm or an agency, the temptation is to hire on either side of the gap. Hire field staff for field work, hire data staff for data work, and hope that the two groups talk to each other. They mostly do not, in my experience, or they talk in ways that miss each other. The hire that has outsized impact is the one who can sit in both meetings. They are harder to find, and they are usually a little more expensive, and they are worth it.
I am not trying to argue that the specialists are obsolete. They are not, and the field needs them. The deep field ecologist and the deep computational biologist are both essential, and the work they do is irreplaceable. What I am arguing is that the connective tissue between them, the people who can hold both perspectives at once, is currently underbuilt relative to what the field actually needs. And the people who develop that connective ability are going to find that there is a lot more demand for them than supply.
That is the bet I made when I built this practice, and it is the bet I would make again. The work that is most interesting to me, and most useful to clients, is almost never on one side of the gap or the other. It is in the middle. Learning to be comfortable there, and to be honest about what each side knows and does not know, is the skill I would invest in if I were starting today.
