From Friction to Flow

Over time, I've realized that one of my most portable strengths is not tied to a single discipline. It shows up in operations, learning design, media, and product work in much the same way.

I notice friction quickly. Usually it is a repetitive task, a clumsy handoff, a tool gap, or an experience that feels far more cumbersome than it should. My instinct is to imagine what the smoother version would look like, build a first working prototype very quickly, and then iterate until it actually solves the problem.

That pattern became especially clear to me after reading Philippa Hardman's work on the "full-stack learning designer". What resonated was not just the combination of design, coding, and project skills, but the underlying capacities: vision, empathy, communication, creativity, and judgment. Those are the things I rely on most. The tooling matters because it lets me execute, but the deeper skill is seeing how something could work better and then making that future state real.

The best shorthand for how my mind works is the old XKCD comic about automation and saved time: if a task is frequent and repetitive enough, even a small improvement compounds into a huge gain over time.

The XKCD comic sums it up well. I am always asking myself, "Is it worth the time?" For example, if I could build a tool to automate a process that currently takes 5 minutes, but that I currently spend 15 minutes doing, then I would say that it is absolutely worth the time.

I do not usually calculate that explicitly. It sits in the background. When I run into a workflow that feels wasteful, I instinctively ask two questions: why is this taking so long, and what would the smooth version feel like?

That means I tend to evaluate problems less as isolated annoyances and more as systems with hidden drag. The opportunity is often not in working harder, but in redesigning the process so the friction is removed altogether.

My build process is consistent across very different kinds of work.

I start by picturing the ideal user experience. I think first about inputs, outputs, choices, and handoffs — not about code. I want to know what the person using the system should be able to do, what decisions they need to make, and what a clean experience would feel like.

From there, I prototype fast. With AI-assisted coding, I can usually get to a first working prototype in one or two hours. Most complete builds land somewhere between five and thirty hours, depending on complexity. My typical mode is simple UI first, just enough backend or logic to prove the flow works, then refinement and iteration until the system feels right.

At first glance, these projects look unrelated. Job search automation, learning design transformations, role-playing game tools, plant care reminders, arbitrage monitors, AI worlds. But they all come from the same operating principle.

That matters because many organizations are full of exactly this kind of hidden drag. People spend hours on formatting, routing, monitoring, triaging, copying, checking, and translating. Good people end up doing low-value repetitive work because no one has stepped back to redesign the system. What I do naturally is step into that gap.

The value here is not that I can "code," at least not in the conventional sense. I am not a traditional software engineer, and I do not need to be. The value is that I can move from problem identification to working solution quickly by combining process thinking, UX judgment, light technical fluency, AI tooling, and iterative experimentation.

In professional settings, that shows up as workflow redesign, automation, content transformation, better tooling, lower manual overhead, and more time for real thinking. It is as relevant in operations as it is in learning design. In both cases, the goal is the same: get people out of repetitive admin and into the work that actually requires their brains.