Every so often a junior developer asks me for advice, and I catch myself pausing. Not because I have nothing to say, but because most of what I could say has expired.
I started in Seoul in 2001, building web systems when “web developer” was still a job you had to explain to your parents. Then Tokyo for nine years, writing Java e-commerce platforms that ran storefronts for Softbank, JAL, Toys “R” Us — the kind of systems where a bad deploy made the evening news in somebody’s office. Then Toronto, where I’ve spent the last seven years on procurement software that cities and courts run their bidding on. Three countries, three working languages, and I’ve lost count of the stacks.
Here’s the uncomfortable part: take my best technical advice from any point on that timeline and say it out loud today, and it’s wrong. The frameworks I mastered are museum pieces. The architecture patterns I defended in meetings have been rotated out twice. If I had written down my hard-won 2008 opinions and handed them to you as wisdom, I would have handed you a liability.
So I’ve built up a list of things I don’t say. Which framework to bet on. Which language is about to matter. How many hours to grind. All of it is weather forecasting, and juniors deserve better than a forecast delivered in the voice of a prophecy.
What survives is a much shorter list — the things that were true in Seoul in 2001, true in Tokyo in 2010, and are still true in Toronto this morning.
The domain outlives the framework. Every line of code I wrote in Japan is gone — rewritten, replaced, retired. What I still use, weekly, is what those systems taught me about how orders, inventory, and settlement actually behave: which states exist, which transitions are legal, what must never happen twice. Platforms rotate underneath you. The shape of the problem barely moves. If you get to choose what to be good at, be good at the part that transfers.
Work backward from the end. I don’t start from a feature list. I start from the finished scene: the invoice prints, the parcel ships, the award notice goes out to the winning bidder. Then I walk backward and ask what has to be true one step earlier, and one step before that, until I reach the code. Done this way, the system mostly designs itself — and the features that don’t serve the final scene reveal themselves before you build them, not after.
You will read far more than you write. Nobody told me this in 2001, and it’s been the truest ratio of my career. Other people’s code, ten-year-old code that used to be other people’s and is now legally mine, logs, specs, RFPs written by lawyers. Writing code is the visible tenth of the job. Learning to read — quickly, charitably, and with suspicion in the right places — pays off every single day, in every country, in every stack.
Trust compounds. It’s the only currency that converted cleanly across all three countries. Keep the deadline, and when you can’t, say so before the deadline says it for you. Deliver the bad news yourself, early. The engineers I’ve watched rise fastest were never the flashiest — they were the ones nobody had to double-check.
Today’s juniors ask a sharper question than I ever did: does any of this still matter when an agent writes the code? I think it matters more. I work with coding agents every day, and what they automate is precisely the typing — the part that was never the durable skill. What’s left over when the typing is free is this exact list: knowing the domain well enough to judge the output, knowing the end state well enough to aim, reading critically, being worth trusting. The tools changed the ratio of the work. They didn’t touch the constants.
Which is the real reason I hesitate when someone asks for advice. Twenty-five years doesn’t transfer; nobody’s does. The only honest thing I can do is point at the ground that hasn’t moved the whole time I’ve been standing on it — and let you walk it yourself.