Decades inside the tech industry

I came to IBM’s Tel Aviv site to write Python, on the team behind the test platform for XIV, IBM’s 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 it.

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, and that changed what it was. Its 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. The layer that ran work across the lab machines moved 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 wrote a course that worked out what the tighter standard looks like in a language with no compiler behind it, taught it at my site, and was asked to teach it at IBM’s other sites in Israel. It ran for years. The gap it was written to close was the one between my team’s Python and everyone else’s.

Redis Enterprise is a mature product written mostly in C and Python, and I worked across most of its layers, from cluster internals to the build everyone shipped through. Most of what I argued for there was Rust inside it.

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 bet landed on the daemon that tracks which nodes are alive and which one holds the cluster’s configuration. Failover runs off it, so a wrong answer there is an outage on somebody’s production database. Rust’s async support was unfinished when I began. I ran on the nightly toolchain, moved the whole thing onto 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. It held 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 was 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 sat in 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. That was the entire mandate. 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 got to be right about what a purchase was, 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.

That is the part I got wrong. The harder I pushed, the harder they pushed back, until one of their engineers said, in effect, that he was not willing to be left maintaining code he could not understand. I had proved the technology could be made to work and had never asked whether this team could carry it, which is the question he was answering. He was right. They could not have carried it then, and the effort I put into winning the technical argument went to the wrong question.

I left when the work I had come for was done. Years later I heard from someone that the backend team had come round to Kafka on their own, once it was something they could run themselves.

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. The comms layer runs ROS 2 and Zenoh together, each doing the part it is good at.

The engineers came from backend, ML and frontend work, and each of them arrived with a settled sense of how code should be written, formed somewhere else.

So I put the shared parts where a service has to meet them in order to build at all. The common library 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.

That’s what keeps a field robot debuggable when something breaks.

I have worked with Band twice: once from inside the team, and later from outside it, on a single decision. They build infrastructure that lets AI agents talk to each other.

An early-stage biotech was betting on 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 can 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 rooms 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.

The venture did not make it, and I had left before that was settled. I would build that on-ramp the same way again.