In 2007, I built my first real piece of QA automation in Java. My manager looked at it and asked one question that has stayed with me ever since. The answer to that question is the closest thing I have to a career heuristic, and the question has only gotten more useful as the industry keeps reinventing the same hype cycle.
The company was Accept Software, a 12-person company building a framework for tracking product lifecycle. The product supported SDKs in Java and C#, against Oracle, MySQL, and Postgres. There were four of us in QA, including myself. The math of testing six SDK and database combinations every release with four people did not work.
The Math Did Not Work
Two languages times three databases is six combinations. Each combination meant exercising the SDK against the database, comparing API behaviour, and verifying that the product lifecycle data ended up where it was supposed to. Doing that by hand, in a tight release cycle, with four people, was simply not possible. We were not cutting corners. We were doing the only work the schedule allowed.
I had been brought in to focus on automation rather than manual testing, so the matrix was the obvious place to start. I started.
My First Pitch Was Wrong
I spent a few days building mockups. I built them in Java and C#, the languages I already knew well from previous projects. The mockups looked good. They handled the cross-language input. They could in principle run the matrix. I walked the management team through what I had.
They listened. Then one of them asked the question.
“Who’s Going to Maintain This?”
“Who is going to maintain this? It is 2007. No one builds web products in Java or C# anymore. Go learn Python. There is a framework called Django. We will pair you with a developer who will get you up to speed fast.”
That was the whole conversation. It was not delivered as a rejection or a reprimand. It was delivered as a more experienced person pointing out something that I, four days into a personal infatuation with my own mockups, could not see. The Java mockups were not bad code. They were code that nobody in the company would want to inherit. The right question was not whether I could ship it. It was whether anyone else could keep it alive.
That single moment is one of the most useful course corrections I have received in my career.
What Got Built
The developer they paired me with was Udi Bauman. We sat together, and in a few weeks I went from never having written Python to having a Django web tool that took SDK code as input, converted it into a unified internal representation, ran it against any of the supported databases, and verified the API behaviour. The tool ran the full six-combination matrix end to end, and the QA team could finally cover ground they could not previously reach.
It became the team’s main validation surface. It was still in use at Accept after I left.
The 2026 Version of the Same Question
In 2007 the temptation was to build the tool in whatever language the engineer was personally comfortable with, even when that language was on the way out for the kind of work being done. In 2026 the temptation is exactly the same, in a new costume.
Today it is “build it in Rust” when the rest of the team writes TypeScript. “Use this new agent framework” when nobody on the team has shipped an agent before. “Switch to the LLM SDK that came out last month” when last month’s SDK already works. Every era has its hot tool. Most engineers, given an automation problem, will reach for the tool that excites them most rather than the tool the team can keep running after they leave.
The right question is still the boring one. Who is going to maintain this in six months? Who is going to maintain it in two years, when you have moved on and the next engineer has to extend it? If the answer is “I do not know” or “anyone who learns Rust,” that is the same answer my Java mockups had in 2007. It is still the wrong answer.
What Udi Taught Me About Mentorship
The tool was useful. Udi was the prize.
Sitting next to one person who already knows the thing you are trying to learn compresses what would otherwise be months of fumbling into a few weeks of focused work. Udi did not just teach me Python and Django. He brought me into the Python and open-source community. He showed me what serious open-source projects looked like from the inside. We started a company together a few years after Accept, and we are still in touch 20 years on.
If I could give one piece of career advice to a junior engineer in 2026, it would not be about Rust, or LLMs, or any specific tool. It would be: find the Udi in your own life, and pay attention. The compounding return on one good mentor is more than any framework you will ever learn.
Let’s Talk
If you are running an early-stage engineering team and trying to figure out which automation work is worth building in-house, what to deprecate, or which “exciting new tool” is actually going to make your life worse in eighteen months, that is the kind of call I help with. I take on senior async architecture and automation work for teams making exactly these decisions. If that sounds like your situation, reach out.
