About
Merging is the middle of the job, not the end.
I'm based in Yaoundé, Cameroon, and trained as a software engineer at IAI Yaoundé (an engineering diploma in computer science and a Licence in software engineering, both awarded with distinction). Most of what I've built since has been for institutional clients: a national real-estate company, government digital-observatory programmes across West and Central Africa, and municipal authorities managing their own data. That work rarely comes with a spec you can trust - it comes with an existing system, a client who understands the problem better than the technology, and a deadline set by someone else's budget cycle.
I've led three of those engagements end to end - architecture, delivery, and the on-site work of standing up infrastructure inside a client's own datacenter rather than a managed cloud. That included training the people who'd actually run the system after I left, and writing documentation so the next engineer wouldn't need me on a call. I'm currently a Junior Solutions Architect and DevOps engineer, which in practice means as much time on Kubernetes manifests and code-review standards as on application code.
A good part of that work turned out to be geospatial - PostGIS, GeoServer, Elasticsearch, mapping APIs - because most of the systems I was asked to build had a location at the center of them: where a property sits, where a service gets delivered, where a boundary actually falls. It isn't a specialisation I set out to have; it's the shape of the problems that kept showing up.
I work in French (C1) and English (B1), from UTC+1, which overlaps most of the European working day and the morning in the Americas. Distributed work doesn't change what makes software good - it just removes the option of clarifying a decision by walking over to someone's desk, so I write more down and assume less.
How I work
Five rules that decide the arguments before they start.
01
Solve the real problem before adding complexity. Most features are a symptom of a question nobody asked properly.
02
Clear architecture and readable code outlive clever code. The next person to open the file is the actual user.
03
Repetitive work belongs in tooling, not in someone's day. If it happens twice, it gets a script.
04
Systems should be observable, testable and boring in production. Excitement at 2 a.m. is a design failure.
05
Software gets good through feedback, not through planning. A deployed guess beats a perfect document.
Tools
Not everything I have touched what I actually reach for, in the order I reach for it.
Credentials
Recent and verifiable.
DevOps & Cloud
Udemy
Aug 2025
DevOps & Cloud
SkillUp / Simplilearn
May 2026
DevOps & Cloud
SkillUp / Simplilearn
May 2026
DevOps & Cloud
Udemy
Aug 2025
Web & Software Development
Alison
Feb 2025
Web & Software Development
Udemy
Apr 2025
Web & Software Development
Udemy
Mar 2025
Web & Software Development
Udemy
Apr 2025
Web & Software Development
CodeSignal
Feb 2025
Web & Software Development
Udemy
Apr 2025
Web & Software Development
Learn IT University
2025
Methodology & Management
SCRUMstudy
Sept 2025
Methodology & Management
SMstudy
Sept 2025
01 / 13
Contact
I'm interested in engineering problems worth solving, products that need building properly, and teams where an engineer is trusted to own a feature end to end.
I answer within a day.