Victoire HABAMUNGU TAKIZALA
Software Engineer specializing in Data Systems, Distributed Systems and Platform Engineering
I grew up in Bukavu, eastern Democratic Republic of Congo. I first learned to code through YouTube tutorials and Pluralsight before I understood what a career in software engineering meant. What I did understand early was that if I was going to do something, I was going to do it properly.
How I think
Software fails in two ways. The first is obvious: bugs, crashes, errors you can see. The second is invisible, and it is the one that actually costs you. Systems that work but were never built to last, that make sense today and become a liability in six months, that solve the ticket but miss the problem entirely.
I have always cared more about the second kind of failure. Anyone can fix a bug. Not everyone thinks past the deadline.
When I sit down to build something, I think about the business before I think about the code. I think about the user before I think about the feature. I think about what breaks if this does not work, because that question changes every decision that follows. A simple bug can cost millions. A complex one can cost nothing. The cost is never in the complexity. It is whether someone asked the right question before writing the first line.
I also think a lot about what it means to build something serious in the age of AI. I use AI every day, and I think it is genuinely transformative. I also know exactly where it fails, where it over-engineers, where it introduces patterns that look correct and are not, and where it optimizes the wrong thing with confidence. I document that line publicly because I believe it is one of the most important distinctions an engineer can make right now.
At the end of all of it, what I care about is building things that outlast the moment they were built. Systems that the next engineer can understand, that survive scale, that hold up when things get complicated. Not just things that work. Things that last.
How I got here
Early engineering, DRC (2017–2020)
This is where I first heard the words "best practices." Saying I was overdoing them would not be wrong, but as a junior engineer, there is nothing better to do than follow instructions precisely, and sometimes understand what the instructor actually means rather than what they say.
After a few months, I was writing modules independently and was recognised as a mid-level engineer.
I later moved to Ets BNJ Congo. My curiosity about electronics and embedded systems brought me there. That is where I understood the boundary between software and hardware while building embedded systems where data loss was not a requirement anyone needed to state. Everyone already knew it was the first.
Going independent, building and studying (2020–2024)
Leaving a stable role to go independent while preparing for university was not the obvious move. But I had built enough to know I could sustain it, and I believed that a great engineer needs more than competence, so university was not optional; it was part of the plan.
The four years that followed were some of the most formative. Long engagements with international clients averaging 10 to 18 months each and small missions from one day to many weeks across data intelligence, e-commerce, and industrial tech. Full ownership from architecture to deployment. Clients who stayed were not staying out of loyalty. They were staying because the work held.
The studies ran alongside all of it.
Building and contributing while leading (2024–now)
Joining TechAffinity was a purposeful decision. An opportunity to contribute to something significant through global networking while being part of the digital transformation taking place across Africa.
After 17 months I was promoted to Module Lead, where I now guide a team of four engineers on multiple client projects while remaining involved in the technical aspects of the work. Transitioning from engineer to lead did not mean stepping away from coding. It meant taking responsibility for both the code and the people who write it.
Outside of my work at TechAffinity, I'm giving back to the community through open source projects. One of these is Normalize, a data normalization engine designed to eliminate the guesswork that can corrupt data pipelines.
Let's work together
If something I built or wrote is relevant to what you're working on, reach out directly or use the contact form.