
The PArting Gift
In 2014 JavaScript was still finding its feet as a backend technology. NodeJS existed. The npm ecosystem had roughly 300,000 packages. But production reliability was uneven, enterprise adoption was thin, and the honest assessment of most experienced architects was that JavaScript as an enterprise backend backbone was visionary — possibly correct — but not yet ready.
I was at Sunnybrook Health Sciences working on a hospital application when the team hit a wall. We needed a JavaScript library to connect to Sybase SQL — the database the application depended on. I tested every candidate I could find. Two or three libraries. None worked cleanly. Each required significant tuning, produced unreliable results under load, or failed in ways that would not be acceptable in a production clinical environment.
The architect’s proposed solution was to build our own.
I told him that was not possible. Not with this team. Not in this timeline. We were working with developers who had picked up JavaScript on the way to the interview. Building a custom database driver — a piece of infrastructure requiring deep expertise in both Sybase’s Tabular Data Stream protocol and the Node runtime — was not a sprint task or even a quarter task. It was months of specialized work that the most experienced JavaScript teams in the world would approach carefully. We were not that team.
He disagreed. The following week, when his favourite agency became available to deliver the news, I was let go.
I kept looking anyway.
Not out of spite. Not to prove a point. Because the problem was still unsolved and I had not finished looking for the solution. That is simply how I work — I do not stop at the boundary of my employment contract when the answer is still out there.
Within a week I found it. A TDS library — Tabular Data Stream, the open source implementation of the protocol Sybase and SQL Server use for client-server communication. I tested it against our requirements. It worked. Not with endless tuning. Not with significant compromise. It worked the way a production library is supposed to work — reliably, cleanly, without drama.
The solution the architect said required building from scratch already existed. It had been sitting in the ecosystem waiting to be found. I had just needed one more week to find it.
I documented the findings, wrote up the testing results, and sent everything back to the team. No invoice. No cover letter explaining what had happened. Just the answer, delivered to the people who had just fired me for looking for it.
I do not know if they used it. I suspect they did. I am equally certain nobody in that room connected the solution to the person they had removed for refusing to believe in the impossible alternative.
I have thought about that moment more than once over the years. Not with bitterness — the decision to keep looking after being let go was not heroic. It was just how I am built. You do not stop looking because the employment relationship ended. The problem does not care about the org chart.
But I think about what it means that the solution arrived one week after the search was interrupted.
The architect had the right destination. JavaScript as an enterprise backend was visionary and he was not wrong about that. He had the wrong route — building what already existed, with a team not equipped to build it, on a timeline that bore no relationship to the actual complexity. When I told him the route was wrong he heard that I did not believe in the destination.
That misreading cost the project a week it did not need to lose and a search it did not need to conduct alone.
The solution was always there. The organization removed the person looking for it one week before he found it.
I left it as a parting gift anyway. That is the only kind of gift worth giving.
Russ Profant is a solutions architect and independent consultant with 30 years of experience across financial services, healthcare, and government. He runs PC4IT, offering cloud cost diagnostics and architecture advisory to mid-market organizations. pc4it.com

