Photo by Hannah Gibbs on Unsplash
When I walked into Synaptic Pharmaceuticals for my first official software developer job interview, I had never written a line of professional code. I had no GitHub profile (it didn’t even exist yet), no computer science degree, and just a vague idea of what a design pattern was.
But I had something far more dangerous: momentum and an unlimited supply of hubris.
A few weeks earlier, I had built a working software system from scratch in a pharmaceutical lab despite having zero formal training. If I could do that, what couldn’t I do?
Spoiler: a lot. There was a lot I couldn’t do.
But back then? I didn’t know what I didn’t know—and I think that turned out to be my greatest asset.
Synaptic Pharmaceuticals was working on targeted drug discovery using cell receptor research. Brilliant scientists everywhere, PhDs arguing casually in hallways about molecular models, chemistry labs full of equipment that looked like props from a sci-fi movie. It felt like I was walking into a cross between The Matrix and Good Will Hunting—and I was definitely not one of the geniuses. I was the janitor who wandered in looking for a quiet place to eat my sandwich.
I guess I must have said all the right words, because by the end of the interview, they had offered me a temporary position as a consultant. The job: rewrite a legacy Microsoft Access “application” used by research teams to capture and analyze receptor binding experiments to use a third-party reporting component.
My first thought:
“Rewrite? Rewrite sounds easy.”
My second thought, 48 hours later, staring at the spaghetti code nightmare I had inherited:
“Dear God. What have I done?”
This wasn’t scripting a few buttons in Visual Basic. This was a living system—used daily by scientists who powered million-dollar research programs. If I broke it, they didn’t get their data. If they didn’t get their data, experiments stalled. If experiments stalled—time was lost. Money was lost.
Careers were on the line.
No pressure.
That first month felt like being dropped into the middle of a foreign country without a map, language, or survival guide—wait, this is exactly what happened to me when I moved to the United States at 16-years-old!!! On day 3, I heard words like:
- ODBC connections
- Oracle Schemas
- PL/SQL triggers
- Stored procedures
- Transaction rollback
- Version control (this one hit me like a brick—people worked on code together?)
I nodded along like I knew exactly what was going on.
“Oh yeah, sure. Absolutely. Yep. PL/SQL? Love it. I can’t imagine a day without a good dose of PL/SQL.”
Inside?
“What the hell is PL/SQL?”
I printed the Oracle documentation—all of it—one section at a time during lunch breaks, stuffing binders full of paper like a madman building a survival bunker. I spent late nights reverse engineering SQL queries I barely understood. I debugged by printing things to log files and reading them like ancient cave inscriptions. One day I even printed the entire database schema and taped it on the wall of our office just so I could visualize how the different tables and procedures related to one another. It also made our office look that much nerdier—cooler, if I may say so.
But slowly—very slowly—pieces started making sense.
- I learned what a foreign key really was.
- I learned why database indexes matter.
- I learned how to optimize a query so it doesn’t run for seven minutes.
- I learned why you never, ever touch production without testing—the hard way.
Three months in, something changed.
I stopped being afraid of the system.
I started pulling it apart just to see how I could improve it.
I didn’t want to just “rewrite” the software—I wanted to make it better.
So I did something risky: I proposed a complete rewrite of the entire application, switching from Microsoft Access to Visual Basic 6, while retaining the original architecture. Nobody had asked me to. Nobody expected me to. But something inside me said:
“If you’re going to build something—build it right.”
Instead of laughing me out of the room, my manager pulled out a chair next to me and pointed to the screen.
“Show me.”
That was the first time I had ever diagrammed software in front of an audience. My heart was pounding, my hand was shaking, and I fumbled half my explanation—but by the end, he just looked at me and said:
“Do it.”
And he let me.
That moment unlocked something in me: the belief that I wasn’t just allowed to build—I was allowed to lead.
That job would go on to teach me more than any school ever could:
- How to learn under pressure
- How to reverse engineer legacy systems without documentation
- How to work with scientists, not programmers—and translate needs into code
- How to solve problems no one had names for yet
- How to earn trust through delivery, not titles
This was no longer an experiment. This was my career now. And I was all in.
Synaptic had one Solaris Unix box that hosted our Oracle database. That’s where I ran my queries. And that’s where I met Linux—for real.
I was already running Linux installed on an old PC at home just to explore. Then a young sysadmin joined the company—a brilliant guy who quietly broke corporate policy just enough to help people do better work. When he saw me doing SQL through a remote terminal, he asked why I wasn’t using Linux at work.
“We’re a Microsoft shop,” I said.
“So?” he shrugged.
Within a day, he had set me up with a Linux desktop on the network and a remote RDP window so I could access Windows applications when needed. I’d launch that remote window full screen every morning so it looked like I was using Windows 2000—but behind it, I was running Gentoo Linux like a hacker in training.
That small rebellion lit something in me. Windows was comfortable—but Linux was freedom. It was the first time technology made me feel powerful.
I didn’t know it yet, but this was the beginning of my open source story.
Around this time, I also got married. My wife and I moved into a tiny one-bedroom apartment in New Milford, New Jersey. Everything we owned was a hand-me-down. So when, nine months into the job, Synaptic offered to buy out my contract and hire me full-time—with benefits and stability—suddenly, life felt possible. We could breathe. We could even start talking about having a child.
I loved my job. I loved the challenge. I loved becoming someone new—someone who could build things that mattered.
But then something else happened.
I got good at it.
And that almost ruined me.
I went from being a junior developer to being the developer. I rewrote the entire internal scientific data platform in Visual Basic 6. I owned the roadmaps, the database, the entire codebase.
Every single data point produced by research scientists passed through my system.
Success didn’t go to my head.
It detonated there.
I became territorial. Then defensive. Then arrogant. If someone suggested a change to my application, I treated it as a personal attack. If someone questioned my design, I shut them down. Hard.
I stopped listening. I stopped learning.
Worst of all—I started believing I was irreplaceable.
I became the problem.
I didn’t realize it then, but I was writing the most dangerous line of technical debt in my career: “Only I can do this.”
I wish I could blame someone else. But the truth is simpler: I outgrew the job. And my ego outgrew me.
I stopped enjoying the work. I stopped enjoying myself. And my teammates—good people—stopped enjoying working with me.
I made the place toxic without even seeing it happen.
And one day, without a plan, without savings, without any job lined up—I resigned. I walked away from everything I had built.
I told myself I left because I needed a new challenge.
The truth?
I left because I didn’t like who I was becoming.
Synaptic was the best thing that ever happened to my career…
…and one of the hardest things that ever happened to my character.
But the universe has a wicked sense of timing—because what came next would humble me in a way I didn’t see coming.
It was the job that broke me.
To be continued…