Who I Am

What I Work On

My work has moved across several parts of the AI and data stack: building and deploying custom machine learning platforms in Python, architecting cloud data engineering pipelines, and developing models and applications that make customer interactions more effective.

That includes recommender systems, predictive models, data workflows, and more classical machine learning use cases. More recently, my focus has shifted toward implementing and deploying chatbot applications and building agentic systems that help customers get practical value from AI tooling.

Why StackedStats Exists

StackedStats exists for two reasons.

The first is simple: I want to give something back. When I started out, I was lucky to have knowledgeable and experienced people around me. I could ask questions, learn from their mistakes, and grow faster because they shared what they knew. I believe knowledge should be freely accessible and only limited by someone’s own ambition to learn.

The second reason is more recent. Over the last few months, I have seen a lot of hype around AI, but also a lot of fear and rejection. I do not buy into either side. AI is a tool, and it should be treated as one.

That means using it critically, testing its limits, understanding where it helps, and being honest about where it does not belong. It is not a blessing sent by tech companies to solve every problem, and it is not automatically something evil that will doom humanity. StackedStats is my place to write about AI, software, data, and tools with a critical but fair mindset.

How I Approach Technical Work

There is this misconception that technical work is done by socially awkward nerds. And truth be told, most of us are nerds, but not socially awkward. Communication is key to every succesful project. That means that before tackling any project, I talk to Stakeholders to understand their problem and how they imagine the solution to look like.

From there on the process can vary between projects. But in a nutshell it is often a combination of thinking hard, trying something out, failing fast, brainstorming/communicating and repeat until I get to a point where I feel comfortable in claiming to have a solution. Of course there is a more detailed sense like, adhering to best coding practices, thinking deeply about architectures before writing a line of code, thinking twice coding once, and making many adjustments along the way to keep the balance of what is possible right now, but not get into a messy state of a PoC that would need a complete rewrite to be reliable. In essence: Everything is possible but it always costs some time.

How I Approach Technical Work

Good technical work starts with understanding the problem. Before I jump into implementation, I try to understand what stakeholders actually need, what constraints exist, and what a useful solution would look like from their perspective.

After that, the process depends on the project. Usually, it is a mix of thinking through the architecture, trying things out, failing early, discussing options, and adjusting the direction until the solution is clear enough to be trusted.

I like moving fast, but I do not like building throwaway prototypes that later need a complete rewrite to become reliable. Good code, sensible architecture, tests, documentation, and clear tradeoffs matter because they decide whether something can survive beyond the first working version.

In practice, almost everything is possible. The real question is what it costs: in time, complexity, maintenance, and future flexibility.

How I Prefer to Work

There is a real difference between shallow and deep work. Both matter, but they need different environments. Brainstorming, alignment, and relationship-building benefit from direct exchange. Implementation, architecture, writing, and debugging often need longer stretches of focused time.

Remote-first work fits that balance well for me. It gives me more control over my focus, reduces unnecessary commuting, and helps me maintain a healthier work-life balance as a father of three. In a field where most of the work happens in front of a computer, flexibility is often the more productive default.

Working remotely does not mean working disconnected. Good team spirit, trust, and strong relationships matter a lot to me. It can be absolutely worth coming together in person, especially for planning, onboarding, difficult discussions, or simply getting to know the people behind the work. But then that should be the purpose of the time together. If everyone sits in the same room, wears headphones, and stares at their own screen, the office is not adding much.

Tools matter as well. People often do their best work with a setup that fits how they think and build: hardware, operating system, editor, and the smaller parts of a development environment. Of course, the choice has to be sensible for the company, security requirements, and the project. But if someone is clearly more productive on macOS or Linux, forcing them onto Windows by default does not make much sense to me. When Linux is not practical, at least having a choice between Windows and macOS is a reasonable baseline.

The same applies to team structure. Ownership should be shared, and people should be able to speak up when something does not make sense. Top-down structures and micromanagement make that harder. Trust still has to be earned, but people need enough space and responsibility to earn it.

Outside of Work

As mentioned earlier, I am a father of three. When I am outside of work and family life leaves some room, I still tend to spend time with technology. Sometimes that means working on a personal project I find useful. Sometimes it means trying a new tool or technology. And sometimes it means spending too much time and money on my homelab to self-host services that my family or I can actually use.

When I need a break from tech, I usually end up with a book, manga, a card game, or a board game.