Pioneering as a Process Person
"Never memorize something that you can look up."
Albert Einstein
I love process.
I rely on process because I don't like remembering things. I don't like having the additional cognitive load required to having to remember things, and burdening myself with the fear of forgetting them. I also like building products, and in a way, you could define products as things that don't need you in the loop to sell themselves (as opposed to say consulting). And I like process because talking about process leads to investment in a system where everybody can benefit, which could reduce friction, increase alignment, and dampen negative human influences.
Process is progress. Since it's based on hard metrics, you have some understanding of the underlying truth around what you're measuring. Since you only need to invest a small amount of willpower to update the process, you can rely on rote routine to do things instead of having to constantly think about things. All this continues to bring me great joy, that I can stop focusing on the little things and focus on the big things.
Yeah, the big things. Process isn't so great in a lot of important areas, especially when it comes to first starting out and proving an idea works, and when you conquently need the flexibility to do things that process explicitly denies. It also fails when it ages and the reasoning behind it is lost; unreasonable process is beaucracy, which isn't much fun. And process isn't good at innovation; a good process leads to a faster horse, not a car. I've experienced all these blind spots in one way or another, and it smarts.
I think a good engineer learns to balance when to pioneer and when to apply process. Oliver Eidel wrote a great blog post about pioneers vs. process people, which to me demonstrated the potential of blending these two strengths together to create a great product.
I've never created a product (or a framework or an open-source tool), and after reading technical books and maintaining a technical blog and working in industry for a few years, I think something like this is the next Rubicon I should aim to cross. So I've been spending the past week or so working on a proof of concept for an open-source project I've been wanting to build, and I'm pleased to say that I've finished the MVP, located here on GitHub.
I'll make another blog post right after this one to discuss said project. For now, I want to talk about how I pioneered this as a process person:
-
Tunnel all the way to the end: What I wanted to prove out in the proof of concept was mere technical feasibility. For me, that required a massive expenditure of willpower, even though the proof of concept is honestly quite simple. Once I can see the light at the end of the tunnel though, I have no problems widening that tunnel so that cars can pass through. This is how I delineate between pioneering and process.
-
Write tickets to focus: I use Basecamp Personal, and I can say without it or a similar kind of easy-to-use issue tracker, I wouldn't have finished the barebones MVP. Describing to myself what I wanted to build, and having a ladder of todo items to check off, remains tremendously comforting to me. I can see where I'm going. Apply process to pioneer when you can.
-
Keep momentum up any way you can: Write specs you know you won't follow. Issue empty updates to people who may or may not be listening. Add in more comments or move code around the project aimlessly when you're first getting started. Do anything you can to avoid giving up, since the most important thing to getting this done is to make sure there's no "zero days". As long as progress isn't zero, it will take a finite amount of time to finish.
I think the more I pioneer, the more getting started will become easier.