15 Years in Software: The Lessons That Survived
From a loan system in the Philippines to marketplace and insurance platforms serving millions in Japan. The principles that kept being true across every stack and country.
My first production system was a hire-purchase loan platform at a consumer finance company in the Philippines, in 2011. Since then: banking software, R&D contracts for major automotive manufacturers, a fintech startup, two stints at a marketplace serving millions, a global insurance group, and now leading architecture for three products in Japan, including six months as a company's only engineer. 15 years, seven industries, two countries, and a stack list I've stopped maintaining.
Most of what I believed in year one didn't survive. These did.
Boring technology is a strategy, not a compromise
The systems that hurt me most were never the old ones. They were the clever ones: the framework someone loved at a conference, the database chosen for a use case we didn't have. Meanwhile the boring Spring MVC service from 2013 kept processing loans, because boring meant understood, hireable-for, and debuggable at 2am.
I still adopt new technology. I ship production LLM pipelines today. But the question changed from "is this better?" to "is this better enough to pay the novelty tax?" Most things aren't. The ones that are, you adopt deliberately, with an exit plan.
Reading code is the senior skill
Somewhere around year five, the job quietly stops being "write code" and becomes "understand systems you didn't write." Migrating a legacy C-framework project, untangling decade-old scripts on an automotive R&D contract, remediating vulnerabilities in a marketplace serving millions. The common skill in all of it was archaeology: reading code with respect, assuming the author had reasons, and finding out what those reasons were before "improving" anything.
The fastest way I know to evaluate an engineer is to watch them enter an unfamiliar codebase. Do they read before they rewrite?
The database outlives everything
Frameworks rotate every few years. The loan-system schema I designed in 2012 probably still exists in some form, migrated but recognizable. Every shortcut in a data model becomes a tax paid by every engineer who follows, forever. I've done ERD design and review for an insurance platform, modeled Cassandra for a fintech, and normalized Japanese real-estate chaos into PostgreSQL. I'll take a week of schema argument over a year of application-layer workarounds every time.
Same for APIs, which are just schemas with consumers: design them for the second consumer, because the first one forgives you.
Communication is engineering
A global engineering summit in Cologne, where I spoke about the inclusion of women in IT, taught me something adjacent to the talk itself. The engineers with the most impact in that room weren't the ones with the deepest stack knowledge. They were the ones who could make a complex thing understandable to someone who needed to decide about it.
Every senior artifact is a communication artifact: the design doc, the incident writeup, the PR review that teaches instead of gatekeeps, the estimate with its assumptions attached. Working directly with CEOs these past years compressed the lesson. If you can't explain the trade-off, you don't get to make it.
Own something end to end, at least once
Being the only engineer for six months (architecture, releases, infrastructure, the bill, the 11pm incident) was the most concentrated learning of my career. Not because heroics are good. They aren't, and I built process specifically to replace the second engineer I didn't have. But total ownership deletes every "someone else's problem" boundary that lets knowledge stay shallow.
You learn what monitoring is for when nobody else will read the alert. You learn what documentation is for when the person confused by your six-month-old decision is you.
The through-line
If I had to compress 15 years into one sentence: software engineering is decision-making under constraints, and the decisions compound. The stack is the costume. The judgment about what to build, what to buy, what to make boring, and what to write down is the job.
I wish someone had told me in 2011 that the loan system's real lesson wasn't Java. It was watching a decision made in a hurry get paid for, monthly, by everyone. Including, eventually, me.