For the past decade, I've been exploring a counterintuitive idea: that software development isn't about writing code — it's about discovering and expressing constraints. Using Answer Set Programming (ASP) as a thinking tool, I've found patterns that connect everything from database queries to creative writing.
Interesting analogy with road lines! But I'd suggest constraints are actually more fundamental than that. They're not just rules we impose for safety - they're the very fabric of how systems work and evolve.
Think about database queries: those aren't arbitrary limitations like road lines, they're expressions of what's logically possible within the system. When we model these constraints explicitly (using something like ASP), we discover they're not restrictions - they're revelations of the system's inherent nature.
This goes beyond datagrams or interfaces. It's about understanding that constraints aren't something we add to systems - they're what systems are. Every API you've ever used, every protocol you've implemented, every interface you've designed - they're all manifestations of underlying constraint spaces waiting to be discovered.
Would love to hear your thoughts on this perspective. Have you ever encountered a situation where what seemed like an arbitrary restriction actually revealed something fundamental about the problem you were solving?
A remarkably ambitious project- a decade's worth of thinking distilled into a cohesive framework. I'm particularly struck by the connection you draw between seemingly disparate fields, from ASP to creative writing. It challenges the conventional view of constraints.
Curious about the evolution of your thinking. How did your understanding of these core principles change? Were there any major 'aha!' moments that changed your perspective. Will spend time exploring this whole work.
Thanks for the thoughtful comment! The evolution of my thinking had several key "aha" moments:
The first came while struggling with working with Firestore. I knew what I wanted to build but trying to juggle the constraints of Firestore Rules, Firestore queries, TypeScript itself, the problem itself that I was trying tackle, etc, etc, etc. was a cognitive nightmare. There had to be a way to grapple with all of the constraints in a more systematic way.
The second breakthrough came from reading George Saunders' "A Swim in a Pond in the Rain." He describes writing not as executing a perfect plan, but as making a move and then reacting to it - each sentence creating constraints that shape what comes next. I realized this was exactly how I approached coding problems!
The third moment was connecting these dots across domains. Whether debugging code or writing prose, we're all doing the same thing: making decisions that create constraints, then pushing against those constraints to discover new possibilities. The todo app example in the Foundations section illustrates this - when we say "a todo item must belong to exactly one user," we're not just stating a rule, we're revealing a web of relationships that shapes everything from database structure to UI flows.
What's been most surprising is how this lens transforms seemingly technical problems into creative ones, and vice versa. A database query and a poem suddenly look remarkably similar - both are explorations of constraint spaces, both emerge through iteration and refinement.
I'd love to hear if any particular section resonates with your own work or thinking!
Thank you for sharing your journey, it itself is already insightful. I've never thought of writing as creating constraints that shape what comes next! And putting technical problems next to creativity, that makes a lot of senses!
As a software developer, I’ve found that most of my work revolves around uncovering the constraints of a problem, asking the right questions, doing just enough exploration to understand what’s truly worth working on, and letting those boundaries guide the solution. The ideas behind Surface Tension resonate deeply with this process. Constraints aren’t blockers; they’re the framework that shapes meaningful progress. This perspective has fundamentally changed how I approach my work.
Is there some kind of "Constraint Driven Design" pattern that one can follow when doing... anything? Is it good for specific domains?
Do you have insights about constraints when working with LLMs?
Thanks for the thoughtful comment - you've captured exactly what I've been exploring!
Yes, there absolutely is a "Constraint Driven Design" pattern, though I've found it works less as a rigid methodology and more as a conversational approach to problem-solving. The basic flow looks something like:
* Start by explicitly articulating what you know must be true (constraints)
* Let these constraints interact to reveal implications you hadn't considered
* Use these revelations to discover new constraints
* Repeat until the solution space comes into focus
In the Blueprints section, I walk through how this works with Firestore queries - transforming documentation into explicit constraints that interact to reveal exactly what's possible and impossible.
As for domains, I've found this approach particularly powerful for:
* API design (constraints become your public interface)
* Database modeling (constraints reveal natural structures)
* UI/UX (constraints map to user mental models)
* System integration (constraints expose compatibility boundaries)
For LLMs specifically, I've discovered something fascinating: they're excellent at generating potential constraints, but terrible at understanding how constraints interact. In "Inner Logic," I explore how we might build systems that combine the pattern-matching strengths of neural networks with the logical reasoning of constraint solvers.
8 comments
[ 73.7 ms ] story [ 627 ms ] thread“It’s about the datagram” for software is an information ecosystem.
Or to show how foolishly we play this game, “it’s about the interface” for software is about usage experience.
Think about database queries: those aren't arbitrary limitations like road lines, they're expressions of what's logically possible within the system. When we model these constraints explicitly (using something like ASP), we discover they're not restrictions - they're revelations of the system's inherent nature.
This goes beyond datagrams or interfaces. It's about understanding that constraints aren't something we add to systems - they're what systems are. Every API you've ever used, every protocol you've implemented, every interface you've designed - they're all manifestations of underlying constraint spaces waiting to be discovered.
Would love to hear your thoughts on this perspective. Have you ever encountered a situation where what seemed like an arbitrary restriction actually revealed something fundamental about the problem you were solving?
Curious about the evolution of your thinking. How did your understanding of these core principles change? Were there any major 'aha!' moments that changed your perspective. Will spend time exploring this whole work.
The first came while struggling with working with Firestore. I knew what I wanted to build but trying to juggle the constraints of Firestore Rules, Firestore queries, TypeScript itself, the problem itself that I was trying tackle, etc, etc, etc. was a cognitive nightmare. There had to be a way to grapple with all of the constraints in a more systematic way.
The second breakthrough came from reading George Saunders' "A Swim in a Pond in the Rain." He describes writing not as executing a perfect plan, but as making a move and then reacting to it - each sentence creating constraints that shape what comes next. I realized this was exactly how I approached coding problems!
The third moment was connecting these dots across domains. Whether debugging code or writing prose, we're all doing the same thing: making decisions that create constraints, then pushing against those constraints to discover new possibilities. The todo app example in the Foundations section illustrates this - when we say "a todo item must belong to exactly one user," we're not just stating a rule, we're revealing a web of relationships that shapes everything from database structure to UI flows.
What's been most surprising is how this lens transforms seemingly technical problems into creative ones, and vice versa. A database query and a poem suddenly look remarkably similar - both are explorations of constraint spaces, both emerge through iteration and refinement.
I'd love to hear if any particular section resonates with your own work or thinking!
Is there some kind of "Constraint Driven Design" pattern that one can follow when doing... anything? Is it good for specific domains?
Do you have insights about constraints when working with LLMs?
Yes, there absolutely is a "Constraint Driven Design" pattern, though I've found it works less as a rigid methodology and more as a conversational approach to problem-solving. The basic flow looks something like: * Start by explicitly articulating what you know must be true (constraints) * Let these constraints interact to reveal implications you hadn't considered * Use these revelations to discover new constraints * Repeat until the solution space comes into focus
In the Blueprints section, I walk through how this works with Firestore queries - transforming documentation into explicit constraints that interact to reveal exactly what's possible and impossible.
As for domains, I've found this approach particularly powerful for: * API design (constraints become your public interface) * Database modeling (constraints reveal natural structures) * UI/UX (constraints map to user mental models) * System integration (constraints expose compatibility boundaries)
For LLMs specifically, I've discovered something fascinating: they're excellent at generating potential constraints, but terrible at understanding how constraints interact. In "Inner Logic," I explore how we might build systems that combine the pattern-matching strengths of neural networks with the logical reasoning of constraint solvers.