Building Software Across Two Time Zones
My work is split between two places that sit four hours and an ocean apart: Benin City in Nigeria, and Porto Alegre in southern Brazil. People assume the hard part is the jet lag, or the calendar math. It is neither. The hard part — and, it turns out, the useful part — is that living between two very different places makes it almost impossible to design software around a single comfortable assumption about how the world works.
You learn quickly that "the network" is not one thing. It is fast here and patchy there, cheap in one place and metered in another, reliable on a Tuesday afternoon and gone entirely when the power is. When the same tool has to serve both ends of that range, you stop building for the best case.
Distance makes you honest about latency
When part of your life runs on a connection that is occasionally excellent and occasionally absent, you stop treating connectivity as a given and start treating it as a variable you have to design around. Things that feel instant on a good link reveal their true cost on a bad one: the screen that needs three round-trips before it shows anything, the action that silently fails if the request times out, the app that assumes you will always be online to sync.
That experience pushed me, over time, toward a set of defaults I now reach for without thinking:
- Assume the weak connection is the normal one. If the experience is acceptable on the worst link your users have, it will be wonderful on the best. The reverse is never true.
- Make the important thing work first. A message that has to reach a parent should not depend on the same fragile path as a cosmetic feature. Separate what must arrive from what would be nice to.
- Prefer channels that survive. This is part of why so much of my work keeps returning to SMS — it lands when richer channels quietly do not.
- Design for the gap, not just the connection. Let people do the work offline and reconcile later, rather than holding everything hostage to a live link.
Two places, one standard
Working across Benin City and Porto Alegre also keeps me honest in a less technical way. It is easy, sitting in one comfortable context, to mistake your own conditions for everyone's. Moving between two places that disagree about what counts as reliable infrastructure makes that mistake harder to make. It is a built-in reminder that the person on the other end of the software might be sharing a phone, topping up data in small amounts, or working through an outage I will never see.
I did not set out to make distance a design philosophy. But building between two time zones turned a personal circumstance into a discipline: serve the weakest connection, protect the message that matters most, and never assume the world looks the way it looks from wherever you happen to be sitting. The schools I build for are better off for it — and so, honestly, is the work.