How I Think

How I think about systems, constraints, and lateral problem-solving

How I Think: Systems, Constraints, and Lateral Solutions

This isn’t a typical portfolio page. It’s an invitation into how I approach problems. If you’ve read my About page, you know what I do. This page explores why I do it that way—what shaped my thinking and why I believe it matters.

What’s a System?

Most people see a system as a set of rules: input → process → output. Follow the rules, get the expected result.

But that’s not how the world actually works.

A system is an interconnected web of constraints, feedback loops, and unintended consequences. Change one variable and three others shift. Good processes create cascades of positive outcomes. Bad ones create ripples of stress everywhere.

I learned this from:

  • Douglas Adams: His absurdist exploration of impossible problems. How do you navigate a universe that makes no sense? By thinking laterally. By questioning assumptions. By finding elegant solutions in chaos.
  • Terry Pratchett: His relentless dissection of social and political systems as living things. His characters don’t just follow rules—they navigate complex webs of incentives, traditions, and unspoken agreements.
  • R.A. Salvatore: How Drizzt navigates a world that constantly tries to define him. Character growth through constraint. Becoming stronger not despite limitations, but by understanding them deeply.
  • J.K. Rowling: The depth of a fully realized world where magic itself has rules, costs, and unintended consequences. Systems that feel alive because every element connects.

When I design a system—whether it’s an automation pipeline at Consumr Buzz or game architecture in rpgCore—I’m asking: What are all the ways this can break? Where are the feedback loops? What unintended consequences might cascade?

This is why I obsess over edge cases. Why I document constraints. Why I refuse to ship code I’m not proud of.

How Do You Design a System That Works?

The easiest answer is wrong: follow the template. Use the framework. Do it the way it’s “supposed” to be done.

The real answer is harder: understand the actual problem you’re solving, not the problem you think you’re solving.

This is Douglas Adams’ lateral thinking applied to code.

Adams taught me that the most creative solutions come from questioning assumptions. In The Hitchhiker’s Guide to the Galaxy, Ford Prefect doesn’t solve problems by following established procedures. He solves them by:

  1. Accepting that the situation is absurd
  2. Asking “what if we ignored the obvious constraint?”
  3. Finding an elegant, unexpected solution

In my work:

  • At Consumr Buzz: The “obvious” problem was “we’re doing too much manual data entry.” The real problem was “we don’t have reliable systems to feed lead data to our campaigns, so we’re stuck in manual workflows.” Once I understood the actual constraint, I could build systems that solved the real problem.

  • In rpgCore: The “obvious” architecture was “build a game engine in one language.” The real problem was “how do I create systems flexible enough for multiple game genres while keeping code maintainable?” The lateral solution: Python core + Godot + NEAT AI. Not what a template suggested. But it works because it solves the actual problem.

  • In PhantomArbiter: Everyone says “build a trading bot.” The real problem is “detect arbitrage opportunities faster than the network itself.” That’s not a problem you solve with standard algorithms. It’s a problem you solve by rethinking what “fast” means.

Lateral thinking means:

  • Question the constraints. Are they real or assumed?
  • Reframe the problem. What’s actually broken? (Usually not what people say.)
  • Find the elegant solution. Not the complicated one. The one that makes people say “why didn’t I think of that?”

Why Does This Matter?

Because systems affect real people.

I learned this the hard way: raising a 6-year-old daughter with high-functioning autism, significant GI issues, and ARFID (Avoidant/Restrictive Food Intake Disorder).

When your child’s nervous system is sensitive to change, you learn that systems aren’t abstract. They’re not theoretical. They’re real:

  • Schedules matter. Consistency matters. A system that works on Tuesday but breaks on Wednesday creates stress that echoes through everything.
  • Edge cases aren’t edge cases. They’re real scenarios where real people live. My daughter’s dietary restrictions aren’t a “special case”—they’re her reality. Systems that ignore them don’t work for her.
  • Good processes create space. Bad ones steal it. When our household systems are reliable, we have energy for what matters: family time, learning, connection. When they’re chaotic, everything else suffers.

This is why I think about:

  • Maintainability: Will this system still work in 6 months? Can someone else understand it? Does it degrade gracefully when something breaks?
  • Constraint documentation: What are the actual limits? What breaks when you push them? Where are the edge cases?
  • Real-world testing: Does this work in practice, or only in theory? Does it work when things go wrong?

When you build systems that serve people—whether it’s lead enrichment pipelines for Consumr Buzz or game mechanics for players—you’re making decisions that affect their productivity, their experience, their ability to focus on what matters.

That’s not abstract. That’s real.

What Are Constraints?

Most engineers see constraints as problems to overcome. Deadlines, budget, hardware limits, requirements—obstacles to the “ideal” solution.

I learned to see them differently.

Constraints create clarity.

Think about game design. The most creative, innovative games come from severe constraints:

  • Roguelikes were born from limited memory. This constraint forced designers to think procedurally. Now it’s a beloved genre.
  • Tetris works because of a single constraint: pieces fall. Everything else flows from that.
  • The Legend of Zelda emerged from the constraint of “fit an entire world on an 8-bit cartridge.” That constraint forced innovation in level design.

Constraints force you to:

  1. Understand what actually matters. When you have unlimited resources, you build everything. When you have constraints, you build only what’s essential.
  2. Find elegant solutions. Unlimited options = complexity. Constraints = clarity of purpose.
  3. Innovate. The best ideas come when you say “how do I solve this given these limits?” Not “how do I remove the limits?”

At Consumr Buzz, my constraints are:

  • Limited development time (I’m one person building automation)
  • No ability to change core systems (we use existing tools)
  • Need to integrate disparate data sources

Those constraints forced me to:

  • Build systems that work within existing tools instead of replacing them
  • Prioritize automation that has immediate ROI
  • Think about edge cases (because I can’t just “throw more servers at it”)

Result: systems that are lean, purposeful, and maintainable.

How Do You Think About Cadences?

Music is rhythm. Systems are also rhythm.

I have an eclectic music taste—everything from orchestral to metal, jazz to electronic, folk to hip-hop. What connects them isn’t genre. It’s knowing which rhythm fits the moment.

The same is true for systems. They have multiple rhythms operating simultaneously:

Code-level cadence (async patterns, concurrency, timing)

How do components communicate? When do things happen? What’s the timing?

In PhantomArbiter, everything is rhythm:

  • WebSocket streams from DEX feeds: constant updates, millisecond sensitivity
  • Detection algorithms: scanning for patterns in real-time
  • Execution: respond within microseconds or lose the opportunity

The cadence isn’t “whenever”; it’s specific, precise, coordinated.

User experience cadence (feedback, pacing, information flow)

How fast does feedback happen? How much information do you present at once? What’s the rhythm of interaction?

In TurboShells, the user experience cadence is:

  • Place a turtle with genetic traits
  • Watch breeding happen (visible, not hidden)
  • See results (immediate feedback)
  • Decide what to do next (clear options)

The rhythm respects the user’s attention and understanding.

Business cadence (peak times, seasonal patterns, predictable cycles)

When do things happen in the business world? When are there crunch times? When is there capacity?

At Consumr Buzz, the cadence is:

  • Month-end: lead delivery peaks (heavy automation load)
  • Mid-month: lower activity (good time for maintenance)
  • Seasonal: certain industries (restaurants, fitness) have seasonal peaks

Build your systems around actual business rhythm, not theoretical smooth distribution.

All three cadences matter. They’re not separate—they’re interlocking. A system with perfect code-level timing but terrible UX rhythm is broken. A system with beautiful UX but misaligned business rhythm will fail.

Good systems have all three in harmony.

It All Connects

Here’s what I want you to understand:

I don’t think of systems as mechanisms to optimize. I think of them as ecosystems to understand.

Douglas Adams taught me lateral thinking. Pratchett taught me systemic thinking. Salvatore and Rowling taught me that constraints create depth. Video games taught me that limitations force innovation and elegance.

My daughter taught me that constraints are never theoretical—they’re always real, and they always matter.

This philosophy shows up everywhere:

  • In my code: I write for maintainability, not cleverness. Edge cases get documented. Constraints get tested.
  • In my automation: I build systems that solve actual problems, not template problems. I question assumptions.
  • In my game design: I respect the player’s time and intelligence. I use constraints to create coherent, elegant experiences.
  • In my approach to work: I think about ROI and user adoption and real-world friction because systems serve people, not abstractions.

When you hire me or work with me, you’re getting someone who:

  • Thinks systemically about complex, interconnected problems
  • Approaches challenges laterally instead of following templates
  • Respects constraints as sources of clarity, not obstacles
  • Understands cadences at multiple levels (technical, UX, business)
  • Builds for real people using real systems in real constraints

Not a template engineer. A systems thinker.

Questions for You

If you’ve made it this far, you probably have some. Here are the ones I hear most often:

“This sounds great in theory. Does it actually work?”

Yes. At Consumr Buzz, my approach to automation has freed up 60% of routine tasks. Those systems have survived 2+ years of maintenance and regular modification. In game development, my systematic approach to architecture has made rpgCore flexible enough for multiple genres while staying maintainable. In trading (PhantomArbiter), thinking systematically about the market structure has revealed opportunities that template approaches miss.

“Aren’t you overthinking things?”

Maybe, sometimes. But underthinking is worse. Most system failures happen because someone didn’t account for an edge case, didn’t understand the constraint, or didn’t think about long-term maintenance. I’d rather overthink constraints than underthink them.

“How do you balance ‘questioning everything’ with actually shipping?”

By distinguishing between constraints that matter and those that don’t. I question assumptions, but I respect deadlines. I document edge cases, but I don’t build for theoretical scenarios. The question-driven approach is about understanding the problem deeply, not about perfecting it endlessly.

“Do you really think about all this when coding?”

Not consciously, every time. But yes, fundamentally. Over years, it becomes intuition. You see a system and instantly recognize the constraints, the likely failure points, the cadences that matter. Then you build accordingly.

What Comes Next?

If this resonates with you:

  • Check out my projects to see these ideas in action
  • Read my blog for specific technical deep-dives
  • Explore my about page to see how this shapes my current work
  • Get in touch if you have problems that need systematic thinking

If you think I’m overthinking things: that’s fair. Different people, different approaches. We probably wouldn’t work well together, and that’s okay.

If you think I’m onto something: let’s talk. I’m interested in problems that need lateral thinking, systems that need careful architecture, and teams that value depth over hype.

Last updated: February 2026

Want to see how this thinking applies to my work? Check out my About page or explore my Projects.