Saturday, September 13, 2014
More than excellent
Heaps and heaps of progress today, but this is my time to reflect, and I've got some bigger things on my mind
I've been mulling over the development process a lot this week, trying to look at the bigger picture and come to a better understanding of how I can improve my own development. Much to my satisfaction, I've come to what I believe to be a much better understanding of optimal development. It's based on two very simple concepts: problems
. Concretely, I'd like to draw comparisons to content
For so long, I've separated the two. I've separated, at least mentally, the idea of building a game
from the idea of building a toolset
. We all know that they're related in some way. But how? There's the old gamedev myth "you can build a game or you can build an engine," which I think perfectly encapsulates the flawed understanding of that relationship that many, including myself, hold. We believe that we can either build a platform for creating content, or we can use a platform to create content. More abstractly, we believe that we can either solve a problem
or build a solver for problems
. Obviously, given that I embarked on the voyage to build LT, I believed that both could be done. But I've been looking at it in a flawed way. I've failed to grasp the true symbiotic nature of the two processes. Here's what I've come to realize: the two should exist in a continual feedback loop -- neither should stand alone, nor should time be artificially allotted to separate them in a particular manner. If I want to create a piece of content X, I may feel that my current toolset won't allow me to do so quickly enough. So I build a tool Y that helps me produce X at a higher rate. The process can be viewed as part of an infinite web of problem / solution answers: in building the tool Y, I'll inevitably have to solve certain problems like Z and W. Hopefully I'll have other tools (problem-solvers
) that let me do so easily, and, if not, perhaps I will need to develop tools that allow me to solve Z and W quickly so that I can get back to building Y.
What I'm getting at here is that the process is a feedbacking symbiosis
. Without posing problems (like "how do I create Limit Theory"), we never recognize the need for the tools that would allow us to solve those problems effectively. If we develop tools without a problem, we're doing so blindly -- developing technology that may or may not ever come to utility. On the other hand, if we never develop tools that solve problems effectively, we will never recognize the feasibility of hard problems (like building Limit Theory) -- or worse, we may never even conceive of those problems (who would have thought to build a procedural space game in the 1800s?) At every moment, it's important to recognize which
is the rate-limiting component that prevents solutions from unfolding at optimal speed. Do we have powerful tools, but no problems to solve with them? Or do we have difficult problems, but inadequate tools for solving them tractably?
I'm finally beginning to understand that the perfect development process -- at least in my current state of understanding -- is a process in which problems are posed, solutions are recursively developed until the problem can be solved tractably, and then the process restarts (with larger or more difficult problems). By constantly eliminating the rate-limiter, we (ideally) end up in a sort of beautiful, positive feedback loop that yields exponentially more solutions as time goes by. At no point in time do we develop content using tools that make it painful to do so, nor do we, at any point in time, build tools that solve unknown, already-solved, or anticipated problems. I have, of course, made all of these mistakes.
No longer will I separate the two. Content and tech will, from this point on, live in a dance of symbiotic harmony. In the end, we will find ourselves with tremendous volumes of both solved problems as well as problem solvers.
Wish I had more time to talk about my concrete work today, as there's a lot of excitement going on in both
departments (finally!?) But time is moving more and more slowly now as I step into this exponential feedback mechanism. We will no doubt have volumes more to talk about in the coming days
We have time. And now, at long last, I believe that we can use it effectively.