Finding the Spark: From Breaking PCs to Building Developer Experience

Share X LinkedIn Facebook WhatsApp
Back to Life in ProductionFinding the Spark: From Breaking PCs to Building Developer Experience
TL;DR

An origin story told in broken hardware, a malware-loaded .exe, and a game store clerk who laughed at the wrong kid. From dismantling PCs at twelve to teaching myself Java under the bed covers at sixteen, to discovering that management slowly kills the spark, and finally landing in the one role where reverse-engineering other engineers' friction is literally the job. Underneath all of it, the father who saw the spark before I did.

To my Pap.

Floppies, Graphics Cards, and Broken Metal

My introduction to tech was a family accident. I was eight when the Super Nintendo first arrived in Lebanon. My dad took me on a visit, and his friend's thirty-year-old son was stuck on a level in Super Mario. I watched for a minute, took the controller, and beat it. The guy was so impressed he gave me the Nintendo on the spot. Or that's how my dad told it for the rest of his life, to anyone who would listen. My dad, a communication engineer, saw the spark. From that day on, he steered me toward technology.

A few years later, my uncle got a PC. I walked into his room and saw DOOM running on floppy disks. In my young mind, it looked like a mountain of a hundred disks, though my engineering brain now knows it was probably closer to thirteen or fourteen. Seeing how fascinated I was, my dad scraped the money together through overtime and on-call weeks to buy us an entry-level PC when I was around twelve. That was the point of no return.

After playing through Need for Speed 2, I saved every coin of pocket money I could find to buy the newly released Need for Speed 3. When I went to the local game shop to pick it up, the clerk behind the counter asked me a simple question: "Do you have 3dfx?" I didn't even know what that was. "No," I replied, "can you just put it on the CD for me?"

The guy laughed in my face. He laughed and laughed at my ignorance.

I left that shop so pissed off that I made a vow right then and there: I was going to learn exactly how a computer functions from the ground up. I saved up, bought my first 3dfx Voodoo card to get the game running, and immediately began dismantling the PC and the graphics card whenever I got bored, just to figure out how the components talked to each other.

When I finally got that card seated into the motherboard and launched Need for Speed 3 for the very first time with actual 3dfx acceleration, that metallic Voodoo intro sound blasted through the shitty, white $5 computer speakers that squeaked more than made music. Those were the classic speakers that would erupt into a frantic, buzzing static whenever a nearby Nokia 3210 was about to receive a call or a text message, predicting the incoming transmission seconds before the brick phone even lit up. Between that rhythmic, predictive speaker buzz and the screeching, static symphony of the dial-up modem handshaking with the internet (sounds I will dear God never forget), my childhood bedroom felt like a data center.

That same obsession didn't stay contained to my bedroom. I got deep into LAN gaming, and internet cafes were too expensive. My friends and I would organize sessions at each other's places, taking turns hosting, which meant one thing: disassembling the entire PC, packing the tower, monitor, keyboard, and cables into cardboard boxes, loading the whole twenty-kilogram operation into my dad's trunk, and hauling it across town. Some weekends they came to me, some weekends I went to them. Most sessions were Red Alert 2, Counter-Strike, or FIFA, and getting those games to actually run on our hardware was half the challenge. We became experts at hunting down patches, no-CD cracks, and every workaround the internet had to offer, just to squeeze another hour of multiplayer out of machines that had no business running those games. Looking back, the fact that I was willing to do that most weekends says everything about where my priorities were.

All that constant disassembly had a cost. My dad was impressed by the curiosity but less so by the execution. I had, I am ashamed to admit, broken the family PC trying to put it back together one too many times.


The Limewire Rite of Passage

Shortly after the hardware phase came another rite of passage for every young engineer trying to be a digital smart-ass: Limewire.

My parents had banned me from listening to alternative rock music, which naturally meant the only thing I wanted to do was find a way to listen to it. I fired up the peer-to-peer network to secretly hunt down Linkin Park's "Numb". Oblivious to basic cybersecurity, I found a link, clicked download, and double-clicked a file named linkin_park_numb_mp3.exe.

My teenage brain saw "mp3" and ignored the massive red flag of the .exe extension. It wasn't the song. It was malware masquerading as an executable. Within seconds, Windows XP was bricked, frozen over with cascading error pop-ups before collapsing into a terminal blue screen.

When my dad saw the digital wreckage I had caused, he looked at the dead operating system, turned to me, and set a legendary, hard boundary:

"I am not fixing this. You broke it, you fix it."

It took a frantic sprint of troubleshooting, reading manuals under pressure, and figuring out how to repair an OS from scratch, but I revived the machine. When the desktop finally booted back up, the teenage arrogance radiating off me was so intense that my dad just stood there staring at me. He looked at the working PC, then at my smug face, visibly caught in a deep paternal dilemma: he couldn't decide whether he should be proud of my engineering resourcefulness or slap me right across the face for being an insufferable little prick.

The funny thing about that moment is how code propagates over time. Today, in my role in Developer Experience, we build the automated guardrails and safety nets for our engineering team. But occasionally, a developer will bypass a pipeline, ignore the telemetry, and deploy a rogue piece of breaking architecture that brings a staging environment to its knees.

Whenever they come to me asking for a quick infrastructure reset to sweep it under the rug, I channel my inner dad and repeat the exact same words that forced me to grow up: "I am not fixing this. You broke it, you fix it."


The School "Punishment" and the Bed-Cover Java Sessions

By the time I hit fifteen, high school computer classes were a nightmare of boredom. The classes were focused entirely on spreadsheets, sums, and averages. It felt like a waste of computing power and brain cells. Because of the knowledge I'd gained from breaking my own PC at home, I knew the school's locked-down machines had a vulnerability. I realized I could simply reboot them into Safe Mode, bypassing all the school's restrictions.

I discovered an old programming language called Logo (the one with the little turtle where you type commands like RT 90 to turn ninety degrees or FD 100 to draw a line). That turtle was my very first taste of writing code to command an environment.

Eventually, the school dean caught me messing around outside the curriculum and was furious. But my computer teacher saw something else entirely. He stepped in and told the dean not to punish me conventionally. Instead, his "punishment" was sending me to his private office to just sit and read on his computer.

It was a brilliant piece of mentorship, but there was a minor side effect: I immediately ended up "hacking" his computer. All I really did was click on the local network icon, but because the school's internal security architecture was practically nonexistent, the headmaster's PC appeared right on my screen. Within a few clicks, I was looking at a directory containing the grades of every student in the school.

It wasn't the hack of the century, but it was an epiphany: Wow, there is a whole world hidden beneath the surface of these interfaces. I went home, pulled the bed covers over my head with a flashlight, and begged my sisters not to snitch on me to our parents. I spent those long nights teaching myself Java from scratch. I wanted to understand the operating system, the networking, and what a sixteen-year-old's version of "ethical hacking" looked like.


Stepping Away From the Keyboard

Years later, I ran my own startup for five years. Partway through, my business partner wanted me off the keyboard and managing people full time, so I stepped away from it. There is no dramatic story in what followed, and that is the point. It was just slow, boring work that rotted me from the inside, dimming the spark that had kept me up under the bed covers at sixteen one standup and one spreadsheet at a time.

When I sold my shares and left, I went back to what I actually loved: operating systems, automation, and the simple joy of fixing a machine so someone else could do their job.

Then I joined Emma Sleep as a backend engineer.


Discovering Developer Experience

While working on our legacy e-commerce backend, a colleague and I were tasked with a massive headache: automating a painfully slow, manual deployment process and creating ephemeral environments for our developers to test their code without stepping on each other's toes.

I fell in love with the project. It wasn't about building a consumer feature. It was about fixing the broken factory floor.

When our engineering department decided to ditch the monolithic system and migrate to a custom, self-built microservices architecture, the Head of Engineering approached me with a proposal: "Do you want to try stepping into Developer Experience (DevEx)?"

I said yes immediately.

The moment I stepped into DevEx, my whole trajectory made sense, even though I couldn't have put the job itself into words yet. It was the bridge between my passion for helping people and my love for raw software infrastructure. In DevEx, your users aren't random customers on the internet. Your users are your fellow engineers. Your job is to look at their workflows, find every piece of annoying corporate friction, every slow build time, every broken deployment script, and automate it out of existence.


The Architecture of the Spark

Looking back, the path is only obvious in hindsight. Nobody sits down at a pristine, perfectly planned desk at eight years old and decides they want to be a Staff Developer Experience Engineer. The career doesn't exist in a textbook. The spark is forged in the friction: a condescending game store clerk, a Safe Mode hack in a boring computer class, a fake linkin_park_numb_mp3.exe file detonating Windows XP under the watchful eye of a strict father who somehow knew I had it in me.

If my childhood had been full of perfectly optimized, unbreakable systems, I probably never would have become an engineer. I learned how things worked because I broke them. I learned how to fix them because nobody else was going to do it for me.

That is the architecture of the spark.


Legacy Code

My dad's name is Hikmat. The thick village accent in our family flattened it to "Hakmat", and I used to tease him with it, dragging the wrong vowel out just to get a rise out of him. He pretended to hate it. He didn't.

He saw me join Emma. He saw me start picking at deployment pipelines and broken developer workflows, back when I was still finding myself in DevEx and couldn't have told you what the job even was.

He didn't fully get DevEx either. But he was curious about it the way he stayed curious about everything. On every video call he'd ask me about what I was building. And every time I flew back from Germany to Lebanon, his old programming books came out the moment I walked through the door.

"Charbal, put your bags down and come look at these books I saved from my day." Charbal, not Charbel. The same village accent that flattened Hikmat into Hakmat did the same to my name. So we'd sit over volumes so obsolete they were practically archaeology, and he'd walk me through how it all used to work. It didn't matter that they were ancient, not to him and not to me. He just loved that we still spoke the same language.

He never saw me become a Staff Engineer. He left before the spark he'd ignited in me, the one I'd chased my whole life, finally got a name.

That one stings, and no amount of clever phrasing is going to fix it. He's still "Hakmat" in my phone, and I still pay the bill on his number. I would rather die than let someone else have it.

But he would have understood it in a heartbeat. He was a communication engineer. He spent decades diagnosing systems, recovering from failures, and breaking problems down until they were small enough to solve. He had a line he repeated so often it was just background noise when I was a kid, and only turned into signal after he was gone. It loses something on the way from Arabic into English, but it came out close to: "What makes a person successful is their ability to adapt and navigate their way out of any problem."

So every time I tear apart a broken pipeline, stare down a developer's impossible environment, or look an engineer dead in the eye and say "you broke it, you fix it," I'm just running the operating system he installed in me at eight years old, in front of a Super Nintendo, in a family friend's living room in war-stricken Lebanon.

He never got to read this one. Learning to adapt to that is the last problem he left me.

The last thing I ever said to him was over WhatsApp. I'd asked him to send photos of some papers. He did, the way he always did. I wrote back, "sallemon Hakmat." He replied, "ahlen."

Sallemon, Pap.


Back to Life in Production