A while back, I stepped away from my IDE and onto a stage at Pint of Science Kisumu. If you aren’t familiar, Pint of Science is a global festival that brings researchers and techies out of their labs and into local spots to talk about their work over a drink. No jargon, no dense slide decks—just raw stories of discovery.
My talk was titled "Sticky Note."
Initially, the audience looked a bit confused. Why is a developer talking about stationery?
But as it turns out, the history of the humble sticky note is the ultimate metaphor for the chaotic, beautiful reality of building software.
The "Failed" Project
In 1968, a scientist named Spencer Silver was trying to develop a super-strong aerospace adhesive. Instead, he ended up with a weak, sensitive glue that could barely hold two pieces of paper together.
The project failed. It was discarded as a failure.
It sat on a shelf for years as a useless mistake. It wasn't until years later that his colleague, Art Fry, frustrated by his bookmarks constantly falling out of his hymnal during choir practice, remembered the "weak glue." He applied it to the paper, and the world’s first Sticky Note was born. Even its iconic canary yellow color was a complete accident—the lab next door just happened to have a stack of yellow scrap paper lying around.
The Illusion of "Seamless" Code
Lately, I’ve been diving deep into logic and system architecture. One major thing I’ve discovered is the massive amount of hidden detail that goes into building any functioning system.
From an outsider’s point of view, a finished application or an elegant script looks seamless. It feels automatic. But as anyone who writes code knows: everything you see is highly intentional.
Behind that smooth user experience is a chaotic trail of:
Fatal errors and broken loops
Hours spent staring at a terminal screen
"Weak glue" solutions that didn't work the way we expected
The real magic of engineering isn't about getting it right on the first try. If it were, none of us would have a job. The magic lies in having the patience to stare at a mistake, slap it on the wall like a sticky note, and look at it from a different angle until we find its true purpose.
Don't Delete the Broken Script
My main takeaway—and my encouragement to the crowd last night—was simple: Do not stop.
When you're working on a feature and the logic completely breaks, or when your data looks incredibly messy, don't just panic and scrap the code. Development is rarely a straight line. It is a process of accidental discoveries disguised as bugs. If we delete our work the moment it goes wrong, we might just be throwing away the foundation of our next big breakthrough.
I am incredibly humbled to say that the audience voted my talk the People’s Choice for the night! 🏆
It was an amazing reminder that whether you are in a high-tech research lab or debugging a local server in Kisumu, we are all just trying to navigate the chaos of creation.
The next time your code crashes or a project falls apart, embrace it. Trust your process, look at the error from a new perspective, and keep pushing forward. Your greatest bug might just be the feature that changes everything.
