2026 Week 20

Timeseries Developer day

Something a little different for the weeknotes this week. The Timeseries product developer team had a get-together in Lancaster on Wednesday and Thursday and here are some of the things that we talked about.

Wednesday 13th May

Architecture Golf: The full pipeline

We started the day on Wednesday with a round of “Architecture Golf”. We took it in turns to draw on a whiteboard part of the system that we have been developing, explaining the concepts and design decisions, whilst also having the chance for a discussion along the way. This gave developers the chance to ask questions about parts of the system they weren’t as familiar with, and also gave us chance to work out what gaps there were in the system. Here is what we ended up with at the end:

September launch

We then had a discussion about what was needed for the FDRI data platform that will be launched in September. This is planned as an initial release to demonstrate to users the data and tools that will be produced by the project. The platform will provide access to hydrological data, and mechanisms to support researchers and others to access this data.

We discussed what actually was being planned for this first release phase, and the technical tasks that would be needed to get us there. This covered a lot of parts of the system, including: Data API, Metadata API, Timeseries UI, Geospatial UI, Timeseries processor, and AWS architecture.

How we present flags in the UI

After lunch, we had an open discussion and brainstorming session about how we should be presenting information about the various “flags” that are attached to each data point on the public UI and the field engineer dashboards. “Flags” are metadata saved alongside a given data point that provide information about something that has happened to that data point along the journey through the timeseries pipeline. This includes information about:

• Which Quality Control tests the raw data failed
• Which Infilling method was used to infill a missing data point
• Any correction methods that were applied to that data point

Jon and Evgeniya had already been thinking about this with respect to the field engineer dashboard, and had some mockups (created using the Figma AI tooling) that provided a really good basis for our discussion. We also talked a lot about the public UI and how different users have different requirements, and came up with some ideas that we will explore over the next few days/weeks.

Lightning talks

After a coffee break, we went into a round of lightning talks, where a few of the developers volunteered to present a quick 2-5 mins on a particular topic. This gave chance to explain some of the technical details behind some of the specifics of the timeseries system, with open discussion and questions afterwards. The topics presented were:

Jon Cooper: Recent improvments to how we handle state in React: what is state?

Leanne Durkan: How derviations work in FDRI: How the metadata and timeseries processor interact​

Leanne Durkan: How our ingesters work

Richard: How does the DAG work?

Dinner!

A lovely dinner at The Borough in Lancaster rounded of the day nicely.

Thursday 14th May

We only had Thursday morning as the Wallingford crew had to set off to get back at a reasonable time!

AI: How are we using it?

We had a great discussion about the hot-topic of AI and how we are using it as developers in the timeseries team. We have a mix of opinions in the team, with some a bit more sceptical than others, but that is a healthy dynamic and allows us to challenge each other and make sure that we stay grounded in what is actually useful for our development work.

Some of the team who work on the UI have been experimenting with Figma to generate mock-ups (and code) for our UI design. There was a discussion about effective use of credits for this, as Figma can tend to burn through them, so detailed initial prompting is crucial. The code that it generates alongside the mock-ups can be useful as a strating point for developers, but care must be taken as it can tend to be quite verbose and inefficient, so still needs that human touch to assess and refactor (and sometimes just as easy to start from scratch with the code - but with a handy design in mind). We also talked generally about the ues of AI for these kind of “creative” tasks:

• The AI only generate stuff it’s seen before so designs may feel generic and not domain-specific
• AI comes up with something very “polished” - can be difficult to then disentangle from that creatively as a human, and settle for that design.

Finally, we had a discussion around gen-AI, in particular the agentic AI and Claude Code. A few of the team are involved in a pilot where UKCEH are providing licenses to use Claude Code for everyday work. There were a mix of opinions, generally positive about how it can help do the more mundane tasks a lot quicker, how it can help with planning work with the full context of a codebase, and helping with things like documentation and unit testing. There were concerns raised about whether the reliance on this kind of agentic AI would reduce our technical skills in the long run (particularly for more junior developers who may not have experience of “no-AI” coding!). Having an experienced developer who understands the code to review what the AI is doing is still important. And finally, we all have a personal responsibility for how we use it, our own learning and training of our technical skills, and the will power to “fight the addiction” of using AI for everything!

The 42nd Annual FDRI Developer Day Awards Ceremony

And finally, to round off the 2 days, we of course had our awards ceremony! It was a star-studded event with all the glitz and glamour that the Kestrel-C meeting room could provide.

The winners list in full:

The “I can do that” award

Samantha Hewkin

Samantha will never say no to a tempting pull request, will always offer up a paired programming session to help someone out, and has fingers in most of our repositories with nearly 100 PRs merged in under a year.

The “AI can do that” award

Dom Ginger

While everyone else is worried about the robots coming, Dom has already made friends with them. He keeps us all focused and with his pragmatism, and always reminds us to celebrate the wins.

The Ticket Whisperer

Evgeniya Vetchinkina

Evgeniya helps keeps our JIRA board tidy - secretly going in and making sure every ticket has the right categories and components, so we can actually find what we’re doing - whilst also generating the Figma mockups that drives our UI development.

“Cold Fingers, Hot Code”

Jon Cooper

For delivering production-quality UI work from what we understand to be a shed. The most efficient developer per heated square foot on the team.

Jack of all trades, master of fun

Nathan Shaw

Nathan has fingers in all of the pies - Kubernetes one day, ingestors the next, becoming a cloud engineer the week after. Nobody quite knows where Nathan ends, and the infrastructure begins.

The Queen of Commits

Leanne Durkan

Leanne only joined in January, yet has made over 250 commits - more than everyone else combined in that time on the timeseries processor repo. Reminds us that no change is too small to deserve a commit!

Favourite commit message: “Fix typos in doumentation”.

The New Kid on the Block award

Ludwig Trotter

This award goes to the latest addition to the team - the person is going to fix everything that we’ve broken. Already getting stuck in and challenging “the man”.

The “Naughty Boy” award

Simon Stanley

Nobody knows more about metadata, vocabularies and sensor slots than Simon. So much so, Github decided this knowledge was too dangerous to be in the hands of one man. And banned him.

simonstanley is dead. Long live simsta87.