Data Analyst in Bioinformatics and Ecology at IGB

Theodore Hermann, Ph.D.

2025-08-21

Background

• 🏞️ Ph.D. in freshwater biology
• 💻 Biologist with a programmer’s mindset
• 🌐 Reproducibility & open practices
• 🤝 Service-focused

I’m a freshwater biologist by training with a Ph.D. from the State University of New York College of Environmental Science and Forestry. I also happen to code and love data analytics. Across research, consulting, and freelance roles, the throughline of my work has been building tools, workflows, and analyses that other people can use — scientists, engineers, and decision-makers.

That service focus has been consistent, so I’ll share three quick examples.

Experience

At UC Santa Cruz, I helped build FHAST, a simulation toolkit for river managers. My role was to make sure it wasn’t just research code, but usable software — delivered on time, tested with stakeholders, and documented so it could keep being used after our team moved on.

🐟 Postdoc: FHAST (UC Santa Cruz)

• Open-source agent-based modeling toolkit for fish habitat analysis → Allowed research groups and agencies to run habitat simulations reproducibly and without advanced coding expertise.

At the Electric Power Research Institute, I worked with engineers to turn their domain expertise into a clean, reproducible machine learning pipeline in Python for equipment-defect detection; we shipped a documented repo and retraining script so their team could maintain it independently.

🔌 Consultation: EPRI Heat Exchanger ML Pipeline

• Machine learning pipeline for heat exchanger fault detection → Helped engineers rapidly identify component failures, reducing downtime and maintenance costs.

I also spent years as a technical editor, helping scientists and companies get papers, grants, and books over the finish line — often with non-native English authors. Pure service work: success measured by clients’ success.

So whether it was software for river managers, a pipeline for engineers, or editing manuscripts for scientists, the common thread was service — making sure others had what they needed to succeed.

As a working biologist myself, I also saw how fragile research processes could be. That’s what first pushed me to dig deeper into reproducible science.

I kept running into problems that frustrated me, and I saw it happening to colleagues too:

📝 Freelance: Technical Editing & Writing Support

• Editor for scholars & companies → helped clients publish, secure grants, and communicate clearly

Science Gets Messy

Collaborative work can lead to chaos with file versions.

Code might run on one computer but fail on another.

Giant scripts that are failure-prone and impossible to debug months later.

And even when research makes it into a paper, the methods rarely spell out how raw data became results. Reproducibility often stops at the manuscript.

Instead of just accepting those frustrations as the cost of doing science, I started looking for ways to fix them. Over time, that search grew into the structured, reproducible workflow I use today.

Solutions that Work

library(targets)
library(tarchetypes)
library(here)

tar_option_set(
  packages = c("tidyverse")
)

tar_source()

list(
    tar_target(
        name = path,
        command = here("path/to/data.csv"),
        format = "file"
    ),
    tar_target(
        name = raw_data,
        command = read_data(path)
    ),
    tar_target(
        name = analyzed_data,
        command = analyze_data(raw_data)
    ),
    tar_render(
        name = manuscript,
        path = here("path/to/manuscript.qmd")
    )
)

• Pipelines → teammates can rerun analyses without guesswork

• Controlled environments → collaborators get the same results every time

• Version control → workflows open for team and community to reuse

• Documentation → future researchers can build on the work without me

The first thing I tackled was pipelines. Instead of fragile, thousand-line scripts, I use structured project layouts and a pipeline manager so analyses can be rerun without guesswork — not just by me, but by collaborators down the line.

My go-to is the targets package in R, which can reproduce an entire project, including manuscripts, with a single command.

Pipelines don’t fix everything, so I lock environments. Docker standardizes the system across machines, and renv freezes R package versions. That way others — even years later — can run the code exactly as I did.

For collaboration, I put code, data, and documentation on GitHub so nothing lives on one laptop or buried as 10 versions in email threads. It keeps the workflow transparent for the team and open to the wider community for audit and reuse.

Finally, documentation — clear READMEs, inline notes, and Quarto reports — means future researchers can understand and extend the work without me in the room.

These practices are deliberately general. The same pattern — modular steps, QC checkpoints, and versioned environments — extends across ecology, genomics (FASTQ/VCF), and even metadata/data management plans basics; while I haven’t authored formal data management plans yet, the workflow supports them out of the box.

Reality of Research

But even with great tools, adoption isn’t instant. Scientists are busy, projects are bespoke, and there’s rarely time to refactor workflows with deadlines looming.

That’s why I see reproducibility itself as a service. A dedicated person can package pipelines, environments, and templates to reduce the burden on scientists and ensure that best practices are easy to implement.

The payoff is twofold: researchers keep their focus on the science, and the institute gains robust, transparent, reusable workflows that speed up work instead of slowing it down.

So the question is: how do we turn these practices into shared infrastructure the whole institute can rely on? That’s exactly where I’d like to contribute.

How I Can Contribute

• 🏞️ Freshwater expertise
• 💻 Technical range (R/Python, pipelines)
• 🌐 Open, shareable workflows
• 🤝 Reproducibility as a service

What excites me here is building this as shared infrastructure—pipelines and environments that make projects easier to trust, reuse, and extend across teams.

IGB is a leading freshwater research centre in Europe, with real reach across science and policy. That makes it an ideal place to standardise robust, open workflows that others can learn from and adopt.

That’s the role I’m after: not just producing results myself, but helping the whole institute’s research be stronger, more reproducible, and more impactful because of the tools and practices we build together.

That’s the contribution I’d be excited to make with you.

Questions?

Just a final note: this talk was made using Quarto and all files are available on GitHub!