The driest year at Otowi since 1964. Code: https://github.com/johnrfleck/water-tools

Otowi

Total flow to date on the Rio Grande at Otowi is the lowest since 1964.

Otowi is the place where the river leaves the upper valleys and enters the canyons that lie at the head of the valley of Albuquerque, what we in New Mexico call the “Middle Rio Grande.”

The graph shows total flow to date this year, with previous drier years called out in red. You can see that the “drought of the ’50s,” (which really extended well into the 1960s) was the big impact decadal-scale event here, not the ’30s, Dust Bowl.

If you squint, you also can see the subtle impact of the San Juan-Chama Project, which beginning in the 1970s began importing Colorado River water. I’m measuring total flow with this calculation, not what is formally called the “Otowi Index Flow,” the official measure of native water used for Rio Grande Compact accounting. This is the number that matters the most to me – it’s the total amount of water we have to work with here in the Middle Rio Grande, the actual flow of water into the valley each year. You can see a subtle impact of that SJC water, raising up the floor in dry years. At least I think I can see that.

A Note on Method

I am not a computer programmer, or software engineer, or whatever you call that thing. But I’ve been writing computer code since I was a teenager in Upland, California, writing Fortran on punch cards that we would send to the guy who ran the school district mainframe to run in the middle of the night. (Southern California’s Mediterranean climate meant we did not have to trudge miles to school barefoot in the snow, but we did write code on punch cards.)

I’ve done it because it’s fun (I did a stint as a free software volunteer on the GNOME project 20-plus years ago), as a toolkit for analyzing data in my haphazard career as a “data journalist,” and in early days of newspaper Internet work, when we rolled our own web site code in Perl. I am a terrible coder, but with some help (site:stackexchange.com “cryptic error message”) I know enough to make my way around the data I have questions about. I was the guy at the newspaper who “borrowed” Lotus 1-2-3 from a friend to analyze city budgets, and persuaded the IT folks to put “R” on my desktop computer against their better judgment. But it’s laborious stuff because of the gap between my subject matter expertise and my coding skills. As a result, there were things I didn’t bother with.

Luis Villa, a friend from my GNOME days who went on to become a lawyer and big think person about “open” and the commons, posed a question on his blog last month about the gateway language model coding tools provide into open data. The provocative header to the section of the post was “Accessibility & Democratization”:

Open data enabler? We’ve been talking about open data for a long time, but since using data is hard to consume and manipulate, open data has never been as big as open code. But if open data + vibecoding = powerful, does that make open data way more relevant?

“Vibecoding” is a technique by which you tell a language model in plain language what you want your code to  do. It writes it. You run it. It chokes, you paste in the error message and say “Fix this.” After a couple of iterations, it works. This is both dangerous and liberating. For me, it opens up vast areas of open data for analysis that I never would have bothered with because of the agony of pasting error messages into a search engine trying to find someone on Stackexchange who had the same problem, running their code, getting a new error message, turtles all the way down. I know the questions and the analytical structures I need, but turning those ideas into code was a pain in the ass!

In the case of the graph above, I had some old code I had written that downloaded USGS streamflow data, converted cubic feet per second (a rate) to acre feet over a specified time period (a volume), compared flow to date this year to flow to the same date in previous years, and made a graph.

This year has been super dry. I was curious about previous years that had been this dry. Updating the code to color those with lower flow than this year’s red was conceptually trivial, but would have been tedious and time consuming. Also, the old code’s visualization was ugly. Vibecoding the changes took an order of magnitude less time than writing all of that code by hand. I’m pretty sure it took longer to make the locator map in Datawrapper (which is fast!) than it did to update the code.

This would be a terrible idea, as Simon Willison argues, if my goal was to become a better programmer, or a software engineer writing production code. This is the same reason using language models to do your writing for you – if your goal is to come to understanding – is a terrible idea. The act of writing is an act of coming to understanding. For me, the knowledge work here is staring at the graph, incorporating what it is telling me into my knowledge framework, and doing the work of writing this blog post. I need to know enough to look at the code and the data it spits out to be confident that it’s sane. But I don’t care about the finicky syntax of R’s “mutate” and “ifelse.”

Code here, part of a set of water data analysis scripts I’ve used for years, updated this week with Anthropic’s codebase management tools to fix a bunch of messes I knew needed fixing, freely licensed under the MIT license so you can do with them what you will.