On Work and Creating Things
“Work” here is in terms of concrete projects/sequence of tasks that require intellectual exertion, such as an open source project or an MVP app for a startup idea.
There’s the concept of Uphill vs Downhill Work [1] that is important to be congnizant of. Uphill signifies the work that is necessary to validate a project’s feasibilty. Downhill work is that which is done to drive a feasible project to completion.
One must figure out how to place key tasks in either of these categories. More pertinently, one must understand which tasks could actually be described as uphill tasks as opposed to mere conceptualization that has no place on the graph (lets call this flatline work), as there is nothing to show for such work.
A good rule of thumb for differentiating such things is that uphill tasks involve actually getting into the implementation of things i.e. writing code (that runs), building out mocks or collating research.
Ideas from Paul Graham’s 2003 blog post Design and Research [2] **teach us that the process of design and doing uphill work hold many parallels. According to the post, good design is an iterative thing which involves:
- Being cognizant of false starts (flatline work)
- Getting to a working prototype/MVP as soon as possible (uphill work)
- Continuously optimize and improve upon prototypes
- Working prototypes provide inspiration (fuel) for improvement
- Embracing “unfinished” work — “A painting is never finished, you just stop working on it”
The ideas around iterative work and collating learnings from each attempt at things is also a practical way to overcome perfectionist indecision in the process of building things. “Perfectionist Indecision” is something i’d describe as the inability to settle on which one out of a set of possible implementations of a certain thing (be it database library or continuous integration service) to use because of perfectionism.
Singling out a candidate implementation/approach and going in on it is the best way to find out if it could actually work better than the others; if any obvious roadblocks are identified in this process then a new candidate approach can be chosen based on the learnings, after all it’s you’re always working on unfinished prototypes anyway.
Motivations/Sources