Decades inside the tech industry

I joined IBM’s recently acquired XIV group to write Python, on the team building the test platform for their high-end storage system. Soon after I joined, the team’s manager left and I was offered the seat. I had come there to build, and it took me a while to say yes. I stayed in the code the whole time I held the position.

The platform drove the storage system along both its control path and its data path, hard enough to surface the kind of bug that off-the-shelf tools never reach. Engineers on other teams began writing their own tests on top of it, helping speed up development as well as finding bugs. The platform’s interfaces were now holding up work by people who did not report to me and could not be broken on my schedule, so I began designing it that way: we moved the layer that ran work across the lab machines from implicit RPC to explicit message passing, so each host’s side of it could be tested standing on its own.

Python at the time was treated across the company as a scripting language, held to a looser standard than the C sitting next to it. I built a course that worked out what the tighter standard looks like in a dynamically typed language, taught it to colleagues at the office, and was later asked to teach it at IBM’s other sites in Israel. It ran for years, and was something people kept remembering me for long after I left IBM.

I worked across many of the layers of Redis Enterprise, a mature product written mostly in C and Python, from cluster internals to the build system that everyone shipped through.

One central contribution I made was introducing Rust into the codebase, for all the usual reasons: Improved safety, robustness, and developer experience.

Some of that work is public: RedisJSON, the JSON data type for Redis, moved from C to Rust, and I wrote its first Rust commit and, later, the cut-over that replaced the C module in the shipping product. It sits on redismodule-rs, the open-source Rust framework for Redis modules, where I was one of the first contributors.

Inside the cluster software, the same approach landed on the daemon that tracks which nodes are alive and which one holds the cluster’s configuration. Failover was based on it, so a wrong answer there would cause an outage on somebody’s production database. Rust’s async support was unfinished when I began. I built on the nightly toolchain, moved the whole thing onto Tokio from a different async runtime partway through when the ecosystem shifted under it, and the pieces I needed reached a stable release months after I had committed to them. But it proved its case in production: when the company later set out to rebuild its cluster management from scratch and asked me which language to build it in, that daemon made most of my case for Rust.

I started a Life Sciences degree while I was still at Redis, out of my own interest. A year later I moved to Ultima Genomics, a DNA sequencing company, because I wanted to work where software meets biology.

Much of my work there was on the layer where separately owned tools meet. The experiment platform was one of them: you edited a parameter file on a pull request and drove a cloud run by commenting on it, without the tooling installed on your own machine. Most of that repository’s history now belongs to other people’s experiments.

Another came out of a migration. A model was moving from TensorFlow to PyTorch, and the training data behind it sat in TensorFlow’s own record format, which PyTorch had no way to open. I wrote rustfrecord, a Rust library with Python bindings that reads those files straight into PyTorch tensors, and published it to PyPI. That let the model move without waiting for the data to move with it.

What made Ultima interesting was that the software engineers and the scientists were effectively speaking different languages, with the ML and data people somewhere in between. Being one of the few people deliberately focusing on both the engineering and the biology is what let me translate between them, and it is why so much of what I built ended up sitting at the seams.

Sunbit brought me in to help their data science team get better at software engineering practice, and to get that team and the backend team working together more smoothly. The architecture work came later, out of what I found once I started working with the backend: business state living in a relational schema with versioning hand-applied to some of the tables, on a stack that was getting hard to scale.

What I proposed to the CTO, as a pilot, was to move the authoritative record of a purchase out of the SQL database and into an immutable log, and to let each consumer derive the view it needed from that log instead of everyone negotiating one schema. Kotlin and Kafka Streams came with the proposal. The choice underneath it was which system would be the source of truth, and every consumer written afterwards would be built on that answer.

Kafka the log was mature. Kafka Streams was not, and getting it to behave the way we needed took months of pushing. It worked in the end. The data science team and I built a live map of purchases arriving, binned by area and updating as they happened, and it landed. That team backed me because I had spent the first phase of the engagement helping them raise their own engineering game, so the trust was already there to spend. Then I took it to the backend team.

Line5 builds physical AI: robots running computer vision in the field. I joined the early team as an architect and helped set the technical foundation, including the GPU vision pipeline that reads the world in front of the robot. I also worked on defining the communications layer and choosing how tools such as ROS 2 and Zenoh can work well together, each doing the part it is good at.

A significant part of the work was the human factor: backend, robotics, and ML engineers were each used to working to their own standards and each team had their own idea of what code should look like.

I helped build shared ground: common libraries and data types moved into one place that every service imports, and new services started from one template instead of from whichever service happened to be nearest. Ad-hoc structures gave way to typed ones, down to physical quantity types for the navigation math, so a distance in metres could not be quietly added to one in feet. And I pointed the coding agents we had on the team at the same rules and the same lint that gate a person’s branch.

Band builds infrastructure for AI agents to talk to each other. I worked with them twice: once from inside the team, and later from outside it, on a specific architecture decision.

An early-stage biotech startup was using machine learning to read mass-spectrometry data and predict antibiotic resistance from it. I built the pipeline, from the raw spectra through to the error rates a clinical lab judges a test by, and wrapped it in a command-line tool that someone who has never set up a Python environment could run.

I also built the demo we took into hospital and HMO labs. A clinician could move a slider to their own rate of resistance and watch what that did to the numbers, alongside the system they already use. The feedback out of those demos shaped what came next.

The decision I am proudest of there is that I opened the codebase to people who do not write code. I encoded the domain workflow as skills an AI agent applies, and committed the agent’s configuration to the repository so it behaved the same way for everyone working in it. Then I sat with a biochemist who had never used version control, and with a data scientist new to this kind of tooling, until each of them was putting work of their own into the project.