What does fixing a child’s lamp have to do with repairing a slow CI/CD pipeline?
Sometimes, the most impactful changes come from simple, pragmatic fixes. This story highlights observation, practicality, and the power of being an expert fixer.
The Universal Agony of Waiting
There are few rituals in software development more universally agonizing than watching a CI/CD pipeline crawl. You push a one-line change, create a pull request, and then… You wait.
You stare at that small yellow spinning icon — a tiny, glowing symbol of existential despair.
You get coffee.
You check Slack.
You consider switching careers.
You wonder whether the heat death of the universe will arrive before your build turns green.
And in that frustration, that oddly familiar sense of helplessness, my mind slid back to something that happened a week earlier: my 9-year-old daughter trying to read in the dark after her bedside lamp died.
It’s funny how these things connect; a slow pipeline and a dark room share a higher relationship than they should.
This is a story about two fixes.
It’s about how being a sound engineer isn’t always about architectures, Kubernetes clusters, or rewriting entire systems. Often, the real value lies in noticing a small source of friction and removing it - a tiny fix with an oversized outcome.
Act I: The Bedtime Service Outage
The “Bedtime Lighting Service” was down.
No redundancy.
Zero graceful fallback.
The user had already tried the usual workaround - turning the light on and off, but observability metrics (i.e., facial expression) indicated a severe degradation in system reliability.
Around 9 PM, an urgent, high-priority crash came in from my daughter:
The System: The “Bedtime Lighting Service.
The User: My 9-year-old daughter
The Bug Report: The user reported a critical failure. The service was completely down
Incident: catastrophic hardware failure
Impact: full outage of the “Go to Sleep” workflow
A quick investigation revealed the issue: the socket was cracked, and the bulb dependency had been deprecated several days prior. If this were production, someone would’ve added a TODO to fix it two sprints ago - but here it was, a live Sev1.
I grabbed my standard issue tooling - my toolbox - and got to work. The repair was simple: replace the socket, update the bulb, redeploy the lamp.
Total time: under ten minutes.
Total impact: massive.
For me, it was trivial.
For her, it was everything.
The room lit up, she breathed out, and the evening routine finally resumed.
The night’s Sleep Level Objective (SLO) was back on track.
And that feeling of fixing something small that mattered enormously, stayed.
For me, the engineer, the task was trivial. It took less then ten minutes and required no complex skills. But for the end-user, the impact was immense. The service outage was a blocker for her entire evening routine. By restoring the service, the core SLO for the night was successfully met ❤️
Act II: When a Pipeline Leaves You in the Dark
A week later, I felt that same quiet frustration while waiting for a PR to pass.
That same sensation of watching someone try to navigate in the dark, but this time it was developers trying to ship code instead of a kid trying to fall asleep.
One of our critical services has an integration test step that took about 25 minutes.
Not 25 minutes of heavy computation, not 25 minutes of meaningful work., just 25 minutes of watching yellow bars move slowly across a screen.
A bottleneck so old and entrenched it felt like the software equivalent of a frayed wire no one wanted to touch.
Eventually curiosity — and accumulated annoyance — pushed me to investigate.
Buried inside the pipeline YAML was the truth:
all country-specific test suites (br, mx, co, us) were running in series.
And worse: a deprecated suite, integration-legacy, was also running sequentially per country.
It was the CI/CD equivalent of plugging every lamp in your house into the same flickering socket.
It was a classic case of legacy cruft left behind by some top-down decision that no one remembered or could justify - a bit like a mandatory return-to-office policy whose business justification was never clearly articulated. This was a clear example of how a minimal tech debt could grew from something seemingly “innocent” to friction for every developer (in this case, every pull request, in anothers, could be directy on production!).
Before: a monolithic test step nobody questioned
# Fictitious “Before” CI/CD configuration
jobs:
integration-tests:
steps:
- run: |
npm test -- --suite=br \
--suite=mx \
--suite=co \
--suite=us \
--suite=legacy-br \
--suite=legacy-mx \
--suite=legacy-coIt wasn’t malicious.
It wasn’t stupidity.
It was simply… inertia.
A small technical decision that quietly grew into a source of friction for every developer, every day.
Like a 💡 light that flickers for months because nobody bothers to check the socket.
From Serial to Parallel
The fix, again, was far simpler than the pain it caused.
All I did was:
break the aliases and the suites apart
isolate legacy tests
give each country its own job
run everything in parallel
In other words:
I stopped forcing every test to share the same faulty lamp.
After: each suite gets its own light source
# Fictitious “After” CI/CD configuration
jobs:
# Main integration tests, one job per country
test-br:
steps:
- run: npm test -- --suite=br
test-mx:
steps:
- run: npm test -- --suite=mx
test-co:
steps:
- run: npm test -- --suite=co
test-us:
steps:
- run: npm test -- --suite=us
# Legacy suites, also fully parallelized by country
test-legacy-br:
steps:
- run: npm test -- --suite=legacy-br
test-legacy-mx:
steps:
- run: npm test -- --suite=legacy-mx
test-legacy-co:
steps:
- run: npm test -- --suite=legacy-coRuntime went from 25 minutes to under 5.
An 80% improvement - unlocked by a few lines of configuration.
No application code changed.
No heroic refactor.
Just a clean, pragmatic fix.
And when the pipeline turned green in record time, it hit me again: This felt just like the lamp.
Small fix.
Huge emotional impact.
Huge productivity impact.
Different domain, same energy.
Why Fixing Lamps Matters
Neither repair required genius.
Neither required a re-architecture.
What made them powerful was the same thing:
👉 A tiny intervention that removed a massive source of friction.
Engineering loves glorifying the builder — the one who creates something new and shiny.
But the highest-leverage work often comes from the fixer — the person who notices the loose wire, the pointless delay, the old dependency, the tiny drag that everyone ignores because “it’s always been this way.”
Anyone can ship a feature.
Few people will fix the thing everyone silently suffers from.
Be a Fixer, Not Just a Builder
True engineering happens in these moments:
The query that no one optimized
The unstable test suite that no one investigates
The deployment script that everyone dreads touching
The documentation shaped like a maze
The flickering lightbulb in your daughter’s room
Fix what’s broken—not just what’s new and shiny.
Small tweaks build the kind of system people love to work on.
And the kind of home where children feel safe to sleep.
So let me ask you this:
What’s the “broken lamp” in your codebase today?
Not the giant redesign.
Not the perfect refactor you’ll do “someday.”
The small, annoying, friction-filled thing that everyone avoids.
Drop it in the comments, along with the first step you could take to fix it, even if it’s tiny.
Let’s build a culture of fixers together.
From design to deployment — My technical-digital diary is a reader-supported publication.
Consider subscribing to support more stories like this.