Off the Clock: Oh wie schön ist Panama

 

I'm a product-oriented software engineer who spends work hours thinking about products, users, and how to make things that matter. After hours, I work with my hands - fix things, build things, plant things, read things, and explore things. This is where those worlds meet. Sometimes a hobby teaches me something about my day job. Sometimes my product instincts change how I approach a craft. The lines cross more often than you'd expect. And this series of posts will be about that bi-directional influence. 

A Gem at the Library

A few weeks ago, I was at our local library in Berlin. Then a small children's book caught my attention. A bear and a tiger on the cover, looking happy. The title was "Oh, wie schön ist Panama". (how beautiful is Panama).

I read it many times. And every time I read it, I reflected more on some aspects in my life from their perspective.

Everything They Wanted

The story starts with the little bear and the little tiger. They live together in a small house by a river. They fish, they collect mushrooms, they have each other. Life is good. They have everything their heart desires. There is no problem to solve, no crisis to escape. They even have their own boat.

This reminded me of something I have seen many times in software teams. A system that works. Users are happily paying. The code is clean enough. Deployments are stable. And yet, someone reads a blog post or watches a conference talk, and suddenly the current setup does not feel enough anymore.

The Empty Box

One day, the bear finds a wooden crate in the river. The word "Panama" is written on it. The box is empty, but it smells of bananas. That is all. A word and a smell. From this single clue, the bear builds an entire dream in his head. Panama must be the land of their dreams. Everything there must be bigger, better, more beautiful, and smells like bananas.

In software, we do this all the time. We see a keyword on a landing page, a demo video, or a social media thread. Serverless. Microservices. AI-native. Blockchain. We do not investigate deeply. We do not ask if we actually need it. We just catch the smell of something exciting, and we build a whole dream around it.

The Departure

The bear goes home and tells the tiger about Panama. They talk late into the night. By morning, they have decided to leave. But there is one problem. They do not know which direction to go.

So they take the wooden crate and build a signpost. They place it at their door and point in one direction. They invented this direction themselves, but now they follow it with full conviction.

I have seen teams do exactly this. A working monolith gets torn apart into microservices that nobody needs. A simple CI pipeline gets replaced by a complex chain of tools. A stable hosting setup gets migrated to the next big cloud solution because everyone is doing it. The old system was not perfect, but it was working. The new dream was based on an empty box.

We build our own signposts. We read three articles, watch one keynote, and suddenly we know the direction. We point forward and start walking with confidence.

The Journey

Along the way, the bear and the tiger meet many animals. A fox, a crow, a hare, a hedgehog. Each one offers them something. A place to sleep, a story to hear, a new perspective. They discover many things they never knew before - like how a comfortable sofa feels. And they decide that one day they will have their own sofa too.

The journey is long and not always easy. They walk in the rain. They sleep in a barrel. They get hungry and look for food. But they keep going, because the dream pulls them forward.

In software, the migration journey is the same. You meet new tools, new communities, new ways of thinking. You learn about distributed systems, observability, infrastructure as code. You make connections. Some of these lessons are genuinely valuable. The problem is not what you learned. The problem is that you left home to learn it.

The Return

After a long journey, the bear and the tiger arrive at a place by a river. There is a small weather-beaten house. Big trees. A damaged bridge. A signpost on the ground which reads "Panama".

"This must be Panama!" they say. "It is even more beautiful than we imagined."

They do not recognize their own home. The wind and rain had changed it just enough. The overgrown trees made it look different. They see it with new eyes and fall in love with it.

Their boat is gone. It was destroyed during their absence. But they find the wood by the river and build a raft. Not the same as before, but something new they made themselves.

The Repair

The bear and the tiger do not sit and complain. They get to work. They fix the bridge. They repair the house. They clear the overgrown garden. They do this happily, because they believe they are building their dream.

This is what happens when teams finish a big rewrite or migration. They look at the new system and feel proud. It looks clean. It looks modern. But slowly, they would realize it solves the same problems the old one did. The business rules are similar. The challenges are familiar. They sought and built Panama and ended up at home. And sometimes, the old useful boat is gone. You build a new one from what you found along the way.

This is the part that changes everything. The story is not cynical. It does not say the journey was a waste. It says something warmer: sometimes you need to leave home to appreciate it. And when you come back, you bring the energy to fix what was always waiting for you.

In software, this is what real maintenance looks like. Not shameful debt reduction. Not grudging fixes. But caring for a system you now understand deeply because you tried everything else first.

The Sofa

A favorite detail in the story is the sofa. At the beginning, they did not have one. They only had wooden chairs. During their journey, they sat on someone else's sofa and loved it. When they arrived at their "Panama," they realized they wanted a comfortable one at home too.

They were delighted. But here is what they missed: they already had everything they needed. The sofa was just a nice addition to what was already complete.

The Lesson to Keep

Someone might ask if the bear and tiger could have just stayed home and saved themselves the long walk. The answer is no. Then they would never have met the fox, the crow, the hare, and the hedgehog. They would never have learned how their skills mattered and how they completed each other in the journey. They would never have seen their home from a new angle. And don't forget the Sofa!

The journey was not wasted. The return was not failure. Both were necessary.

And maybe that is the most honest thing I can say about software trends, framework migrations, and every empty box that smelled of bananas. We chase, we learn, we come back, and we fix what was always ours. Not because we were wrong. Because we needed the walk.

Off the Clock: Make a P.M. Decision

I'm a product-oriented software engineer who spends work hours thinking about products, users, and how to make things that matter. After hours, I work with my hands - fix things, build things, plant things, read things, and explore things. This is where those worlds meet. Sometimes a hobby teaches me something about my day job. Sometimes my product instincts change how I approach a craft. The lines cross more often than you'd expect. And this series of posts will be about that bi-directional influence. 

One of my favourite comedians is Kat Williams. And one of my fourth jokes he told tells a story about his son wanting a new Xbox. Instead, Kat convinced him to buy a used Nintendo console with two controllers and like 20 used games. His reasoning stuck with me for quite some time because it fits exactly how I think about product decisions in my engineering role.

He said multiple things in a matter of 2 minutes that changed how I see my work. Let me break down a few of them.

Daddy Can Do This All Day Every Day, No Problem

Kat said this about buying an Xbox for 199.99$. He had the money. He could do it. But he advised his son not to.

This sounded very close for engineers. We get asked to build things all the time. Use new frameworks. Add big fancy features. Complex architectures. My answer is often yes I can if that's the only choice. I can do it every day, all day. But that is not the question.

The real question is whether we should. A Product Manager mindset asks what outcome we are trying to reach. Is this the fastest path? Does this solve the actual problem? Or am I just showing off technical skills while wasting time?

I have said no to tasks I could easily complete. I once (or twice?) harmed my own bi-yearly performance review because I sounded "against the change" when it came to adding a new unnecessary fancy dependency to our stack. Not because I could not do them. Because I had a better idea for that time and effort. The best use of engineering power is not saying yes to everything. It is choosing the right thing to say yes to.

It Only Comes With 2 Demo Games and One Controller

Kat said the Xbox was a trap. Buy the base unit, then pay for every game. It comes with one controller. Daddy can't play with you. Your friends can't play with you. Buy another controller.

This happens in software too. A tool sounds free until you add the plugins. An API seems cheap until usage spikes. A microservice architecture starts simple but needs monitoring, logging, deployment pipelines, and five more services just to talk to each other.

These are hidden costs. Nobody shows them on day one. By the time you see them, you are already locked in. Migration takes months. Rewriting takes longer. Now you cannot go back.

A P.M. decision asks what comes in the box before you sign the contract. What are the real limits? What do I pay later that I ignore now?

20 Games That Other Kids Have Already Opened and Played With To Make Sure It Is Fun

Kat explained why the Nintendo was better. It came with like 20 games other kids had already tested. You knew they worked. You knew they were enjoyable.

Software has the same lesson. Some love shiny new tools. The latest library. The newest cloud service. The framework everyone is talking about. But who has really tested them yet in production? Nobody knows if they hold up under our pressure and our specific uses.

A P.M. decision looks for the games that already came with the system. Use patterns that work. Copy what others have learned. Solve the problem with code that has been proven before.

This does not mean staying old forever. It means being smart about when to risk. I would rather ship a boring feature that works than build something cool that crashes.

We Got Like 300 Dollars Leftover

If Kat's son chose the Nintendo over the Xbox, the saved money stayed in Kat's pocket. They could go across the country and have all the ice cream and nuggets they want! The point was not about saving cash. It was about having resources for other things.

In engineering we call this technical debt or opportunity cost. Every hour spent building unnecessary complexity is an hour taken from solving real user problems. Every server running unused features is budget gone from hiring someone new. Every bug in unfinished code slows down the next sprint.

Making a P.M. decision means looking at what you save when you choose simple over flashy. That saved time becomes freedom. Freedom to try real experiments. Freedom to pay down tech debt. Freedom to have fun building the next thing that actually matters.

Sometimes the smartest engineering move is doing less work.

The Bottom Line

Kat Williams taught his kid something bigger than video games. He taught him to look past the hype and the peer pressure. To value proof over promise. To keep resources for what matters.

Same applies to my work as an engineer. I can say yes to every request. I can build every feature. But a product mindset changes the question from can I to should I.

Make a P.M. decision. Choose the used game. Save the money. Keep the resources. Build what proves valuable over time.

Off the Clock: Prepping the Leather – Small Wins, Onboarding, and Lowering Barriers

I'm a product-oriented software engineer who spends work hours thinking about products, users, and how to make things that matter. After hours, I work with my hands - fix things, build things, plant things, read things, and explore things. This is where those worlds meet. Sometimes a hobby teaches me something about my day job. Sometimes my product instincts change how I approach a craft. The lines cross more often than you'd expect. And this series of posts will be about that bi-directional influence.

Some time ago, I had an idea: what if I sold a kit for making a leather wallet—not the full process, but just the final step?

I had already done the hard parts. I had measured, cut, punched holes, installed the push buttons, and glued the zipper. What remained was the stitching. The buyer would receive a nearly-complete wallet, two needles, some thread, and one skill to learn. One weekend, one satisfying project, one personal leather wallet.

The person who bought it told me it was a lovely weekend project. For them, the experience was about creating something without frustration. For me, it was about recognizing where the real barrier was—and removing everything except the one thing that makes the craft feel like craft.

What I didn't expect was how much this little experiment would influence how I think about my day job.

Where the barrier actually lives

When I started learning leathercraft myself, I ruined materials. Not because stitching is hard—it isn't, once you try it—but because getting to the stitching required a wall of tools, precise cuts, and mistakes that were expensive to make. The entry cost wasn't the skill. It was everything around the skill.

The same is true in software engineering. When a new engineer joins a team, the actual coding is rarely the bottleneck. The barrier is the setup, the domain knowledge, the unwritten rules, the context that lives in someone's head. By the time they write their first meaningful line of code, they've often already felt lost, slow, and unsure of themselves.

I've seen what happens when someone's first contribution is a small, successful one—fixing a bug, shipping a minor improvement. And I've seen what happens when their first task is unclear and goes nowhere. The first one builds momentum. The second one builds doubt.

The wallet kit taught me this in a different material: prep the hard parts, hand over the meaningful part, and let the learner feel competent early.

What product scoping and leather prepping have in common

There's a moment in leathercraft where you decide how far to prepare and where to stop. Cut too little and the user struggles. Prepare too much and you've removed the craft entirely—there's nothing left for them to own.

This is the same tension in product scoping.

When I've worked on launching a new product feature, we spent time in early research before writing a line of code. We looked at existing solutions, built small prototypes, and tested our assumptions. The goal wasn't to ship everything at once. It was to ship the minimum thing that would make a user feel: "Yes, this solves a real problem I have."

We cut features. Not because they weren't valuable, but because they weren't the first valuable thing. The wallet kit works because stitching is the first valuable thing—it's the moment where the pieces become a product. Everything before that is preparation. Everything after that is improvement.

In product, I've learned to ask the same question the wallet kit answers: what is the one action, the one moment of value, that this product delivers? Build toward that. Cut the rest for later.

The feedback loop I didn't plan for

Here's what surprised me: the product thinking I use at work started flowing back into my hobbies, and vice versa.

When I scope a product feature now, I think about the wallet kit. Not literally, but structurally: What am I asking the user to do before they reach value? Can I remove some of it? Am I handing them a pile of pieces and tools, or am I handing them a nearly-complete experience with one meaningful step to own?

When I design any other hobby project now, I think about user research. Who is this for? What do they already know? What will frustrate them, and is that frustration necessary—or is it just there because that's how I learned?

Neither side owns the lesson. They feed each other.

Small wins, bigger bets

The person who bought that kit wasn't trying to become a leatherworker. They wanted a weekend project that felt good. A small win.

But I've noticed—in engineering, in product, and in craft—that small wins are where bigger things begin. The new engineer who ships a fix on day three comes back on day five wanting something harder. The user who tries a feature and saves time asks what else it can do. The person who stitches a wallet starts looking at leather and wondering about more.

You don't get people to bigger commitments by making the first step harder. You get there by making the first step possible—and letting the satisfaction do the rest.

That's what the kit was really about. Not leather. Not wallets. Just the idea that lowering the barrier to a first win is one of the most generous things you can do—for a teammate, a user, or a stranger who wants to make something with their hands.