In software development, the challenge is not just producing working code. The challenge is developing systems that will remain reliable, understandable, and maintainable long after the original developer is gone. Asiru Erioluwa is a senior software developer with a high standard of craftsmanship and a forward-looking attitude, but she distills the essence of that mindset into a concise but compelling motto: “Write code as if the next person reading it has no idea what you’re doing and hates you.”
Erioluwa reassures me with a grin. It’s not cynicism. It’s humility. “You’re not building for you as you currently are, or even your team as they currently are,” she tells me. You’re building for someone you’ll never meet, in a situation you can’t imagine, for problems that you don’t yet have.”
After some years of involvement across industries as varied as financial infrastructure technologies and enterprise-scale systems has afforded Erioluwa a front-row seat as a witness to the long-term consequences of short-term software development practices. Projects that look beautiful in the excitement of the moment dissolve when there is minimal documentation, implicit assumptions that aren’t shared anywhere, and architecture that is not explicitly agreed on.
“There is a time”, she says, “when each engineer is a stranger to his code. Maybe six months; possibly six years. But the good engineers anticipate that scenario from the outset.”
Software engineering is a form of asynchronous teamwork with an audience that one never lays eyes on: downstream integrators, open-source contributors, and perhaps, even future colleagues. It is a mindset that makes one write codebases not just for machines but for human readers as well.
She adheres to her collection of rules with a combination of strict convention-naming and abstractions nested according to business logic and good in-line comments explaining not just what the code does but the rationale behind some choice. “The ‘why’ is the one that’s the most apt to get lost,” she warns. “You might be able to deduce the ‘how’. But the ‘why’–that’s the lifeline for the next programmer.”
Erioluwa further contributes that code quality cannot possibly be decoupled from system architecture. “You might have the most elegant code in a broken architecture, and it doesn’t matter,” she says. Her architecture philosophy is more towards modularity and intentional separation of concerns, such that the individual components develop separately with as little cognitive load on the new system developers as possible.
Adopting Unc. The recurring theme throughout Erioluwa’s career is that she is willing to engineer for uncertainty. “Software systems tend to outlive the problems for which they were originally written,” she says. “Business goals change. Companies reorganize. Laws change. So we cannot write systems that get it precisely right today—we need to write systems that get it right tomorrow.”
This forward-thinking has made her a sought-after contributor to high-growth or changing businesses. At one of those fintech companies, he spearheaded the shift from a monolithic payment engine into a service-based architecture, trading off the desire for speed versus long-term maintainability. Instead of rushing ahead with microservices for the sake of it, Erioluwa put seams into the monolith architecturally—intentional boundaries throughout the monolith—to enable future teams to peel off pieces as needed, without introducing cascading failures.
Her approach is not to anticipate all the possible changes but to create systems that welcome change gracefully. “You’re not future-proofing,” she says. “You’re future-welcoming.”
Erioluwa’s influence extends from the systems she designs to the engineers she leads. Former colleagues habitually refer to her as a technical anchor: calm under pressure, thoughtful in action, and munificent with expertise. She is renowned for challenging colleagues to be more thoughtful, not merely about how code works, but for whom it is written and how it might get used in unforeseen ways.
I see mentorship as a type of engineering in itself,” she says. “You’re affecting how someone thinks, how they approach problems, how they make decisions. It has a multiplier effect far greater than anything else that I might ship.”
She encourages junior engineers periodically to get into “time scale”—not the sprint or release cycle, but in terms of quarters and multi-year horizons. “Ask yourself: if tomorrow you disappeared, would the next person on the team be well-positioned for success?”
At last, Erioluwa views sustainable engineering as a cultural issue, not a code one. “Technical debt doesn’t happen in a vacuum. It’s a reflection of the company culture,” she says. “Where you value speed over comprehension or short-term wins over long-term health, that’s where you find rot setting in.”
They should be a high-quality deliverable, code review should not just be strict but also empathetic, and technical decisions should be documented with the readers of the future in mind, people who won’t have the advantage of our current-day Slack chatter or stand-ups.
As she rises the career ladder as a senior engineer, Asiru Erioluwa is sustained by a sense of stewardship to the craft, the systems, and the people who follow after. Her hand is not explicitly apparent in the product UI or API endpoints. Rather, it is evident in how effortlessly a new engineer integrates into a codebase, how quietly systems perform under load, or the absence of frenzied Slack mentions of “mystery bugs.” In a profession that prides itself on speed, Erioluwa is remarkable for her dedication to longevity. She’s writing code for individuals she’ll never have the chance to meet, in firms she might never have the opportunity to work for, addressing problems he can’t yet foresee. And that, she feels, is the pinnacle of engineering.