Nine years ago I wrote my first Spring MVC controller at Econet. It was terrible. The mapping was wrong, the exception handling didn't exist, and I had no idea what a transaction boundary was.
Today I've built systems that process over a million transactions a day, led teams, architected solutions across six African countries, and spent three years keeping EC2 infrastructure running at Amazon.
Here's what the journey actually taught me — the things no course covers.
1. You don't understand a system until it breaks in production
The e-learning portal I built for 2,000 Econet staff? It went down on the first day of a company-wide training event. Every lesson I know about load testing, graceful degradation, and connection pooling came from that day.
There's a version of engineering that only exists in controlled environments. Then there's the version that exists at 2am when a payment gateway serving a million users is timing out and you have to find the problem in a live system.
The second version is the one that makes you good.
2. The integration is always harder than the algorithm
You can implement any algorithm in a few hours. Integrating with a payment provider in Zambia who only gives you a PDF spec from 2015 and a test environment that's down every Friday? That takes weeks.
When I built integrations for the Kwese Mediation Gateway across MTN, Airtel, Vodacom, and Econet in multiple African countries, each one was a negotiation — different protocols, different error formats, different retry semantics, different test environments.
The real skill isn't writing the code. It's managing uncertainty long enough to ship.
3. Boring technology is usually the right technology
Early in my career I wanted to use the newest thing. Microservices when a monolith would have been fine. NoSQL because SQL felt old. Message queues because event-driven sounded impressive.
Nine years later: MySQL, Spring Boot, REST, RabbitMQ. Boring. Battle-tested. Running in production processing transactions while I sleep.
New technology is a bet. Bet responsibly.
4. The most important thing you build is trust
Technical skill gets you in the room. Trust keeps you there.
At Entelect, deployed to FNB, my job wasn't just to write a Camunda compliance service. It was to make seven engineers, two business analysts, a product owner, and a QA team confident that the thing we were building would work when it went live for a bank's customers.
That's a different skill set than writing code. And it matters more.
5. The best engineers I've worked with are obsessively curious
At AWS, the engineers I learned the most from weren't the ones with the most impressive CVs. They were the ones who, when something didn't work the way they expected, had to know why.
That curiosity is what separates engineers who grow from engineers who plateau.
Nine years in, I'm more curious than ever. Especially now, as I start learning AI engineering — not because it's trendy, but because I want to understand what it can actually do inside the kinds of systems I've spent a decade building.
More on that soon.