“Most real software is glue code.”
Someone will push back immediately. Glue code sounds boring. It sounds junior. It sounds like the stuff you do on the way to the “real engineering,” not the thing a senior engineer would actually want to be known for.
And yet, if you’ve spent any real time with production systems—especially in mid‑size or growing companies—you’ve probably noticed an uncomfortable pattern:
The glue is where a surprising amount of the actual value lives.
- Not in the framework choice.
- Not in the clever algorithm.
- Not in the shiny new service.
- In the code that makes all of those things behave together well enough for the business to work.
What I Mean by “Glue Code”
When I say glue code, I’m talking about the stuff that connects things that were never really designed to work together in the first place. The code that:
- Maps data between systems with slightly different ideas of what a “customer” is.
- Adapts an API so it fits how your workflow actually runs, instead of how the vendor imagined it.
- Handles the ugly edge cases that never make it into marketing diagrams.
- Bridges legacy systems to new ones without breaking the promises you made five years ago.
It’s rarely pretty. It’s often full of case‑by‑case decisions. Nobody is giving a conference talk about “That One Mapping Layer Between Our CRM and Billing Provider.”
But if you quietly remove it, nothing ships.
Why Glue Code Gets Looked Down On
Glue work doesn’t scratch the same itch as greenfield development.
You’re not sitting down to design the perfect abstraction hierarchy.
You’re not picking the “right” architecture from a blank page.
You’re not refactoring your way into a pristine domain model.
Instead, you’re:
- Reading half‑baked API docs.
- Translating between “almost the same” data structures.
- Dealing with timeouts, retries, and partial failures that only happen in production at 2 a.m.
- Writing defensive code because you’ve been burned before.
Early in their careers, developers are taught—explicitly or implicitly—that progress looks like doing less CRUD, more “pure” problems, more architecture. Glue code is framed as something you pass through on your way to bigger, cleaner, more abstract work.
That framing is off by a mile.
A Real Example: When the “Best Tools” Don’t Agree
A few years back, I worked with a SaaS company that had done what every vendor and blog tells you to do: pick best‑of‑breed tools.
- CRM? Big name, expensive logo.
- Accounting? Rock‑solid, widely respected.
- Data warehouse? Modern stack, plenty of buzzwords.
The slide deck looked great. In practice, it was a mess.
Customer IDs didn’t line up between systems. “Active” meant different things depending on who you asked. Billing events showed up late or out of order. Support tickets referenced customers who technically didn’t exist yet in the reporting environment. Every executive review eventually circled back to the same question: “Why don’t these numbers match?”
The temptation, of course, was to go shopping again. “Maybe we just need a better platform.”
What they actually needed was glue. We ended up building a small set of services that:
- Normalized identifiers across systems.
- Reconciled state when two sources disagreed.
- Tracked who said what and when, so we could trace inconsistencies.
- Made explicit decisions about which system was authoritative for which question.
There was nothing especially glamorous about that work. No new language. No wild new algorithm. Just careful, opinionated glue.
Once it was in place, though, a few things changed:
- Dashboards stopped contradicting each other.
- Finance spent less time in spreadsheet hell.
- Product and data teams stopped arguing about which number was “real” and went back to shipping.
That glue code never appeared on a roadmap slide. But it easily justified its existence in real money and real time saved.
Glue Code Is Where the Business Leaks Into the Codebase
Clean diagrams assume the world behaves. The real world does not.
Real systems have to cope with:
- Partial or bad data.
- Human error and one‑off promises.
- Regulatory rules that don’t fit your neat abstractions.
- Old contracts you can’t just walk away from.
The place where those realities get encoded is almost always the glue. That’s why it’s hard. And that’s exactly why it’s valuable.
When I talk to experienced engineers, I don’t start by asking, “What’s the fanciest thing you’ve built?” I ask things like:
- “Tell me about two systems you had to make agree when they fundamentally didn’t.”
- “What assumptions did you discover were wrong, and what did you do about it?”
- “Where did you have to bend the tech to match the business instead of the other way around?”
The strongest answers almost always involve glue.
The Boring Work That Saved a Project
Another story, smaller in scope but just as telling.
A team I was working with had rolled out a new internal platform. The core service was solid. The UI was good enough. The architecture diagram was the sort architects like to show off.
Adoption was terrible. The reason turned out to be mundane: nobody had time to manually move data from the old system into the new one, and nobody trusted that they wouldn’t break something if they tried.
One developer—quiet, senior, not the person dominating the design discussions—took two weeks and wrote a bunch of “unsexy” code:
- Import scripts to pull data out of the old system reliably.
- Validators to catch bad or incomplete records.
- Mappers to translate old concepts into new ones.
- Reconciliation reports so people could see what moved, what failed, and why.
No new features. No big refactors. Just glue.
Once that was in place, adoption jumped on its own. People stopped worrying about the move and just used the new platform.
Nobody outside the team ever said, “This succeeded because of those import scripts.” But inside the team, everyone knew exactly why the project had been stuck and what had actually unstuck it.
Why Glue Work Is a Career Accelerator
Here’s the part a lot of job seekers miss: companies rarely stall because they ran out of clever ideas. They stall because the ideas can’t move cleanly through the mess of existing systems.
Developers who can:
- Understand how multiple systems and teams fit together.
- Fill in the gaps for a broken/partial design.
- See where abstractions leak and where reality lives.
- Write small, pragmatic adapters instead of chasing perfection. (even though utility code also sounds so unsexy)
…very quickly become the people everyone calls when something important has to cross boundaries. Not because they’re the loudest in meetings. Because things move when they’re involved.
In a lot of organizations, “I made these five systems stop fighting each other” is exactly what senior‑level impact looks like. That’s not junior work. That’s judgment.
Stop Underselling Glue Work
Part of the reason glue stays invisible is how we talk about it.
We call it “just integration,” or “some mapping,” or “a quick script.” We frame it as temporary, even when we know it’ll be around for years.
If you’ve done this kind of work, don’t erase it from your story. I have won projects and gotten job offers where I was told the glue work was what led to the win.
There’s a big difference between:
- “Wrote scripts to sync data between systems”
- “Designed and implemented integration layers that reconciled inconsistent data models across CRM, billing, and analytics, cutting manual reconciliation by 30%.”
Same nature of work. Very different signal.
Glue code shows:
- Systems thinking.
- Awareness of how the business actually operates.
- A bias toward reducing risk instead of just adding features.
Those are exactly the traits people say they want in senior engineers.
There Is No “Glue vs Real Engineering”
Some of the best engineers I know can do both: design clean systems and write brutally pragmatic glue when that’s what the situation calls for.
They don’t see glue as beneath them. They see it as part of the job.
They know when it’s worth pushing for a better abstraction and when today’s priority is “make these two disagreeing systems line up by Friday without surprising Finance.”
That judgment is hard to fake and harder to replace.
The uncomfortable reality is this: if you rip out the glue code in most companies, the business stops working long before the algorithms stop running.
- Payments don’t reconcile.
- Orders go missing.
- Reports lie.
- Customers get angry.
What breaks first is almost never the “interesting” part. It’s the seams.
If You’re Early or Mid‑Career
If you’re early in your career, don’t run from glue work because it doesn’t sound glamorous. It’s one of the fastest ways to understand how the business really runs and how systems actually behave outside of tutorials.
If you’re mid‑career, there’s a good chance your ability to write solid glue code is already one of your most valuable skills—even if nobody’s called it out directly.
And if you’re choosing between “shiny” work and glue work, it’s worth remembering:
The code that looks boring today is often the code everybody depends on tomorrow.
Glue code isn’t a detour on the way to “real engineering.”
It is real engineering—just without the marketing budget.
