Give the editors
the keys.

There is no definitive formulation of a wicked problem.

When I was three months old, I had intestinal volvulus. I wouldn’t stop crying, every doctor had a different explanation, and my parents kept looking until they found one who could see what the others missed.

The choice of explanation determines the resolution.

That persistence saved my life. It also gave me something I’ve carried ever since: the recognition that how you frame a problem determines whether you can solve it at all.

Every wicked problem can be considered a symptom of another problem.

I don’t just say “wicked” because I’m from Massachusetts. In 1973, Horst Rittel and Melvin Webber described wicked problems: the kind where the crying is a symptom of something deeper, and treating the surface never reaches the root.

Every wicked problem is essentially unique.

I started where a lot of CS grads start: writing Perl scripts for an escalation engineering team at Dell EMC, then two jobs in the gaming industry building things that were complex, fast, and fun. But games ship patches. The problems I kept gravitating toward were the ones where you don’t get to patch. I earned a Master’s in bioinformatics because I wanted to bring engineering somewhere the problems don’t repeat: healthcare, government, regulated systems where every deployment is its own context and every patient is their own case.

Wicked problems do not have an enumerable set of potential solutions.

I joined a small studio designing for healthcare and government because the solution space is never closed. There’s no dropdown menu of correct answers. You design, ship, learn, and revise, knowing the next version will be different, not because the last one failed, but because the problem shifted underneath you.

Every solution is a “one-shot operation”; every trial counts.

In regulated environments, every release matters. There are no sandbox deployments when someone’s care depends on the system working. That weight is something I chose, not something I stumbled into.

The planner has no right to be wrong.

When you build software for medical contexts, you carry a specific accountability. The system you ship becomes part of someone’s care, and “move fast and break things” is not an option when the things that break are people.

Wicked problems have no stopping rule.

Over the past several years, that same instinct has pulled me toward problems with no finish line. I started researching neurodegenerative disease on my own, not because I expected to solve it, but because I couldn’t stop looking once I started seeing what others were missing. That’s how I work on everything: once I care about a problem, there is no clean stopping point, only the next question.

There is no immediate and no ultimate test of a solution.

I’ve learned to be comfortable building things I can’t fully validate yet. Whether it’s a healthcare prototype shipping to users whose feedback won’t arrive for months, or a research framework whose predictions won’t be tested for years, the work has to be good enough to act on before you know if it’s right. That uncertainty isn’t a flaw in the process. It is the process.

Solutions are not true-or-false, but good-or-bad.

That’s the lens I bring to everything I build. Not “is this correct” but “is this better.” Better communication, better questions, better tools for the people using them. My independent research on neurodegeneration, Project FELINES, follows the same principle: it doesn’t claim to be the right answer, just a framework that generates better questions than the ones we’ve been asking.