Do/did ideas from systems theories (like feedback loops, complexity/emergence, non-linearity) influence your designs & decision making at all?
Well, I tend to follow the linux development Best Practices, here are some of them relating to building systems that I try to always apply in my process:
- Separate policy from mechanism; separate interfaces from engines.
- Write simple modular parts connected by clean interfaces.
- Design programs to be connected to other programs.
- Write programs to write programs when you can.
In your design process, did you balance between designing for “desired outcomes” that you wanted to encourage vs. “unexpected (emergent) outcomes” that you couldn’t predict? If so, how?
I tend to have a specific issue to solve, and everything else are side-effects. But one thing that is important to me is building an ecosystem of things instead of isolated projects, and so it feels a lot more like I am iterating over that one over-arching story, than constantly starting back from the ground up. Each new project, elevates the others.
What were your primary references and sources of inspiration outside of CS/tech?
You can see a list of some of the most influential works here.
How does your mindset shift when building infrastructure vs. something higher up the stack? E.g. Do you use different heuristics or simple rules, how does your workflow/process differ?
No, I always follow the same rules, no matter how abstracted, this is also one of the main reason for my using of Javascript and LISP languages:
Each project should aim to persist across technological Long Term,
not one part of it should be prebuilt, precompiled, or minified —
Every method should be specific, unobfuscated, and each one carefully
chosen against general-purpose libraries, frameworks or wasteful foreign entities.
Using these tools should be frictionless and undisruptive,
their formats and subsequent products versionable, re-purposable,
interpretable and text-editable. Only through open sources, open standards,
human-readable formats and their independencies, might they survive this
fleeting age of self-destructing informatics.
These attributes should not only be perceptible in their design,
but deeply rooted in their code.