Yves Kalume

Expertise isn’t about knowing all the answers.

Career growth isn’t linear. There are periods of rapid progress and long stretches where nothing seems to change. Both are necessary. Trust the process, but stay intentional.

Career growth isn’t linear. There are periods of rapid progress and long stretches where nothing seems to change. Both are necessary. Trust the process, but stay intentional.

Teaching is one of the most effective ways to learn. Explaining an idea forces you to confront gaps in your understanding and clarify your thinking.If you can’t explain it simply, you probably don’t understand it deeply yet.

Building software is a continuous negotiation between ideal solutions and real constraints. Deadlines, teams, users, and business goals all shape the final outcome. Ignoring these realities doesn’t make you principled, it makes you ineffective.

Some of the best learning happens after you’ve already “finished” a project. Reflecting on what worked, what didn’t, and why certain decisions aged poorly builds real experience.Experience is reflection plus time.

I don’t think great engineering starts with code. It starts with understanding the problem space, the people involved, and the constraints that shape decisions. Code is just the final expression of that understanding.

and how their needs change.

reading about history and culture; It helps me understand how humans think, adapt, and evolve over time.
And if you want to be a good engineer, technical skills alone are not enough. You need to understand the domain you’re building for, the people who will use what you build,

ideas are worth adopting.

The key is not to chase trends, but to understand why things evolve the way they do. If you’re a Kotlin developer, start with Kotlin KEEP proposals.

You’ll learn more from the discussions than from the final feature.

It’s not only about tech. Sometimes I just enjoy

One of the things that helped me learn the most wasn’t a course or a book. It was being surrounded by passionate people especially early adopters.Not every hype is worth following.

But watching how technology evolves teaches you, why certain problems exist how solutions mature, when

Teaching is one of the most effective ways to learn.
Explaining an idea forces you to confront gaps in your understanding and clarify your thinking.
If you can’t explain it simply, you probably don’t understand it deeply yet.

There is comfort in familiar solutions. But comfort can slowly turn into stagnation if we stop questioning why we do things a certain way.
Growth often begins at the edge of that discomfort.
Curiosity is a professional skill.

It’s easy to think progress comes from constantly learning new tools. In reality, progress often comes from understanding the same ideas more deeply. When you revisit a concept with more context and experience, it reveals new layers.
Depth beats novelty more often than we like to admit.

New tools don’t automatically make systems better.
If the problem isn’t clear, better tools just help you build the wrong thing faster. Clarity about the problem always comes before optimization.Most technical debt starts as unclear thinking, not bad code.

Does this fragmentation make us better engineers because we have to deeply understand the machinery ? Or do you wish we had a language built specifically to handle the Android constraints natively ?

Because Kotlin is General Purposea and doesn't care about Android's lifecycle.

We are constantly building workarounds (wrappers, lifecycle-aware collectors) to make a general-purpose language play nice with a platform that kills its own UI every time you rotate the phone. 👇

Use a SharedFlow ? You might also lose your event or trigger the navigation twice if the screen rotates.

Remember SingleLiveEvent ? A Google architecture sample hack that became a standard.

Why isn't this solved natively ? 👇

🤣 In 2026, sending a simple "Show Toast" event from a ViewModel to a UI is still a heated architectural debate.

Channels ? SharedFlow ? StateFlow with a flag ?

Use a Channel ? You might lose the event if the UI is paused. (even thaugh there's a workaround for that) 👇

let's be honest it wasn't built for Android and because of this, Android development often feels like we are applying "Sophisticated Adaptations" to bridge the gap between a modern language and a legacy OS architecture 👇

I had an interessting discussion recently that stuck with me. We were comparing the engineering philosophy of iOS vs Android 🤔

Swift was built by the platform owner for the platform. Language features often evolve specifically to solve iOS architectural problems.

Kotlin is incredible, but 👇

Big goals aren’t the problem. Starting big is. Ambition works better when it grows naturally from small, repeatable experiences.

We don’t need to go big from day one. We need to go small enough that we want to come back tomorrow.

Tiny experiences create space for discovery and fun. They help us understand what we actually enjoy before turning it into something serious. They build momentum without pressure and confidence without exhaustion.

We should learn the power of tiny experiences. Choosing actions that are small enough to feel easy, light, and even playful. Moving for ten minutes at home. Building a quick prototype. Exploring an idea without deciding what it has to become.

The intention behind this mindset is usually ambition and discipline. But the outcome is often the opposite. We burn out quickly, or we abandon the project altogether. Not because we aren’t capable, but because the entry cost is simply too high.

When we want to exercise, we decide we have to go to the gym every day, follow a strict plan, and never miss a session. When we want to explore a new project, it’s not allowed to stay small. It has to become a startup, with a vision, a roadmap, and pressure attached to it.

There’s a belief many of us carry without really questioning it.
The idea that whatever we decide to do has to be done in its biggest, most ambitious form.

Complexity isn't lines of code or fancy algorithms.

It’s a tax on every future PR.

If a "simple" change requires a 5-file refactor and 3 cups of coffee to keep the dependencies in your head, your system is complex.

Simple = easy to reason about. Simple = easy to change.

The engineer who ships 10x faster by ignoring design, skipping comments, and hacking abstractions.

They look like heroes today. But they leave a wake of technical debt that the "slow" senior engineers spend months cleaning up.

Speed != Velocity.

If your interface is as complex as your implementation, you haven't abstracted anything.