CI Is a Software Engineer’s Best Friend
- Published at
Do You Remember Your First Encounter with CI?#
Was it in the onboarding docs, where you learned your team used a CI/CD pipeline?
Did you notice it only when your local server wouldn’t start because of a pipeline error?
Or maybe your pull request got blocked by a ❌, and that’s when you realized—this is what a CI check looks like in action.
When CI works, it stays in the background—like a quiet member of the family.
When it breaks? It’s louder than a blender.
The Hidden Landmine#
When I joined this company, I found the main project’s formatter settings were inconsistent.
Running locally, each person’s machine produced different results.
You might say formatters don’t affect logic, so it’s no big deal.
But in practice, every PR became a mess—full of noisy diffs that made it hard to see the real changes.
Reviewing PRs became mentally exhausting.
Fast Agree on Our Disagreement#
I put up with it for a bit.
But after a few more messy reviews, I started asking around—turns out, everyone thought it was annoying.
Technically, unifying the formatter config wasn’t hard.
The real challenge was figuring out why we had differences:
- Machine settings?
- Personal style preferences?
That’s when I learned a useful collaboration move:
Fast agree on our disagreement.
Not everyone cares about the same formatting rules.
But small differences generate a lot of noise.
The Minimum Acceptable Baseline#
We didn’t have time for endless style debates.
So instead of waiting for consensus before acting, I flipped it: Act first, build consensus later.
I drafted a formatter config targeting the biggest sources of diff chaos—rules that could be auto-fixed.
I asked teammates to apply it locally and share screenshots to confirm alignment.
It wasn’t perfect consensus, but it was a concrete starting point.
I called it:
The Minimum Acceptable Formatter Baseline
This was my first real “cut” into CI.
From Formatter to Linter#
Next, I updated our coding guidelines.
Some rules had turned into implicit knowledge. Others were outdated.
Initially, I just wanted to let the machine catch small mistakes for me.
But reviewing our linter config, I saw checks that no longer matched our standards—and no one remembered why they existed.
That’s when it clicked:
CI tools need maintenance too.
If we agree on certain rules, we should automate them.
Don’t waste human review on what a linter can handle.
So I updated the linter config, handing enforcement to CI—where it belongs.
Back to the main principle:
Strategic laziness.
Expose problems earlier. Shift left.
CI isn’t just a checklist—it’s an early warning system.
Monorepo Brings New Complexity#
By now, CI was saving me a lot of mental overhead.
But complexity doesn’t stay quiet.
As we moved to a monorepo supporting multiple services, cross-module changes became harder to track.
I introduced:
- Commit linting for semantic commit messages
- semantic-release to parse commits
- Automatic version bumps and changelog generation
Versioning got cleaner, and manual release pain dropped.
It also helped leadership see the value of microservices and start thinking about platform engineering.
A small win with big ripples.
CI as Gatekeeper#
Then came the incidents:
Product team changes core logic.
Reviewer misses it.
Things break.
Leadership asks me for a fix.
I turned to CODEOWNERS—assigning specific reviewers to files or directories.
Now, when critical code changes, CI auto-assigns the right reviewer.
Coverage became predictable.
Share the Load#
To avoid overloading one person, I used group-level ownership like @platform-core or @design-system.
This allowed:
- Reviewer rotation
- Load balancing
- Easier onboarding
- Fewer single points of failure
With branch protection, merges required approval from a CODEOWNER.
Strict? Yes—but it set a clear baseline.
I made sure to add:
“If this causes friction, tell me. We’ll adjust.”
Reshaping the Workflow#
The big takeaway:
Process design isn’t just technical—it’s human.
Changing CI doesn’t need deep tech skills.
But it does change workflows, mindsets, and culture.
And change brings both praise and pushback.
Our job is to understand that resistance—and address it.
That’s when I really understood CI’s value:
It’s not just automation.
It’s making the invisible visible, and turning ambiguity into evolution.
Behind all the CI improvements, my goal was simple:
Protect our limited cognitive bandwidth.
Save human attention for where judgment matters—not for what machines can do better.
That mindset pushed me into the next phase of my career:
Thinking deliberately about how engineering culture is shaped.
Final Thoughts#
People ask:
“Isn’t CI work tedious?”
Of course it is.
But if we don’t clear noise at the foundation, we can’t focus on what matters.
That’s what CI gives us:
The space to pay attention to what’s worth it.
I don’t know if this mindset will take me to Staff.
But I know—it’s the kind of engineer I want to be.