| title |
|---|
Future of Coding Plan |
Last month, I set aside a single day -- October 16th, 2017 -- to write my life plan. It summarized my past and current philosophies on life. It also help me set my priorities. My work is #8.
Speaking of work, creating this Future of Coding plan has proved difficult. I produced a number of different versions over the past few weeks. This is the 5th.
- TOC {:toc}
I think it's important to explain how I arrived at my ideas. Let me show you my steps. You can even see the eraser marks.
1. /about
My first draft did a good job of justifying the path I was currently on. I articulated my goal of making "programming as intuative as Facebook", and my strategy of getting there by building "a functional reactive Scratch." The next steps, according to this plan, are FRP research, working on my design principles, and starting to prototype!
2. /plan v1
Where the last version was justifying, this next version was inquiring. It was directly inspired by Chris Granger's SPLASH 2017 keynote, which I highly recommend. It refocused my attention on the end-user. What do they want to do with coding?
In it, I also created the follow chart to help organize my dozen ideas on how to move forward:
| # | Customer | Sustained by |
|---+-----------+-------------------+
| 1 | Students | Parents |
| 2 | Students | Patreon / OC* |
| 3 | Adults | Companies |
| 4 | Adults | Open Collective |
| 5 | FoC Ppl* | Patreon |
| 6 | FoC Ppl* | VC Management fee |
* OC stands for Open Collective.
* FoC Ppl stands for "Future of Coding people", other people working on future of programming tools
3. /plan v2
I showed the above table to Dan Shipper last week. He was really excited about #5: doing research, creating prototypes, writing essays, and recording podcasts for the Future of Coding community. It does seem like a good match for me: allowing me to focus on my favorite activities, and get to skip dealing with the logistics of revenue, customers, and employees. This path makes sense as long as I don't care about money (beyond basic sustainability) or having control.
The open questions from this plan are:
-
What if nobody listens? What if nobody builds the future of coding that I write about?
-
How do I write content that people read? How do I develop a following?
-
How do I sustain this strategy financially?
-
Will I enjoy being a full time "researcher", instead of an entrepreneur?
4. /plan v3
In this version of the plan I started keeping this running tab of past versions of the plan. (Something that the unbreakable-links library may one day do for each of my files automatically.)
I also articulated my mission as "empowering creative expression through programming" and my design principles, which I refactored out to their own page.
The central question is to build or to research?
But first, I need to make sure things are wrapped up at The Coding Space, WoofJS.
Then I need to do research on FRP or a blockly competitor.
And also think about sustainability.
5. /plan v4
Bret Victor's Inventing on Pricinple was the main influence for this version of the plan. It imports social activism's notion of a cause or crusade into engineering. The main features of this plan are:
- You don't find your cause, you construct it.
- Pickling myself by reading all of my influences, and their influences
- Reflecting on past work
- Once I have a better sense of my cause, then constructing a "real" plan to attack that cause.
In a sense, this plan was a plan to find a cause, which is vision plus insight. Examples of causes include Larry Tesler's "no modes", Seymour Papert's "microworlds", or Elon Musk's "save the planet from existential risks through for-profit business."
This is the current version below...
Programming can be like playing a video game: rapid feedback loops, a feeling of tangible progress, and social engagement.
It can also be as fustrating as running through water. It make you feel as stupid as watching a movie 10x as complicated as Inception.
I believe it's this combination of a glittering core engulfed in icky crap that makes programming so uniquely worthy of being extracted, reformed, improved, rescued from the parts of itself that make it less than it could be.
I find that a whole category of mental anxiety is eliminated when I am able to earn enough money to pay for my expenses without dipping into savings. This is bare minimum financial sustainability.
Recently I've been able to manage this with ~10 hours of part-time work for Paul Biggar (CircleCi) and Ellen Chisa's new programming langauge startup. It's an amazing sittuation: getting paid for PL research.
Whenever this gig ends, hopefully not for a couple months, I will likely want to replace it. But I don't want to fret about this, because 1) I have time, and 2) maybe I will decide I don't like this part-time consulting, part-time research lifestyle.
In the meantime, it no longer feeels like my savings are falling through my fingers like sand. Hopefully this lack of anxiety will help me make make some progress here.
I heard somewhere that burn out isn't caused by working too much, because we all know that can be envigorating. Instead burn out is caused by a lack of momentum, when it feels like we're a hamster spinning on a wheel.
But I don't want to over-do this, reducing everything to numbers to optimize progress. Instead I want to be able to look back and admire what I've created whenever I need a boost of confidence.
For example, when I add a new feature to Woof, later that night I will go to woofjs.com/create to admire my new creation. It's a wonderful ego boost!
Yet in the past, I've found that the lack of structure in this project, in particular reading and watching online content, leaves me feeling unproductive.
In the past, I flirted with the idea of emulating Bret Victor in the sense that I'd create essays, not products, like an academic.
But my current dreaming is around creating a widely adopted project. For example, I admire projects like React, Clojure/Script, Datomic, CycleJS, Elm, Scratch, Bubble, etc.
Maybe a company would form around this product I'd create. Maybe I'd get hired by some company to develop it open-source, like Elm and No Red Ink. Maybe I'd get cooler consulting gigs via this product.
WoofJS seems to accomplish many of these parameters. Why is it not the project?
- It's a pretty large project at this point, and it's very fustrating to improve and refactor it
- It's not innovative enough, not an interesting solution enough
- It's not naturally growing fast enough
- There's no obvious path to making some amount of money
- I'm not curious about solving the problems it would take to make Woof successful
- It doesn't satiate my motivation of extracting the beautiful core of programming. This is a neat platform for kids, but it still leaves programming mostly stuck where it is.
Rebuttals to these points:
- This happens to all projects. If you leave a project becaues of technical debt, you'll never build a big project.
- It solves a real problem: next step after Scratch, as well as the transition to text-based coding. It is also as innovative as many other platforms in this space, such as Codesters, VidCode, etc.
- We don't have great metrics on growth anyways. We aren't optimizing it in obvious ways yet. Things have a tipping point once they get "good enough" so more work could change this, like it did for Bubble.
- Growth would solve this via trainings or teacher accounts or ads or a small amount of support from a non profit, like the Scratch Foundation, or even Patreon.
- This point is hard to rebut...
- This point is hard to rebut...
One last rebuttal: potentially WoofJS could been "starter project" for me to experience some inital success to build upon, given that I feel like I know how to make it work.
The worthwhile problems are the ones you can really solve or help solve, the ones you can really contribute something to. A problem is grand in science if it lies before us unsolved and we see some way for us to make some headway into it. I would advise you to take even simpler, or as you say, humbler, problems until you find some you can really solve easily, no matter how trivial. You will get the pleasure of success, and of helping your fellow man, even if it is only to answer a question in the mind of a colleague less able than you. You must not take away from yourself these pleasures because you have some erroneous idea of what is worthwhile. - Richard Feynman
Conclusion: For now, I will continue to work on Woof un-systematically (when I feel like it), but might return to it if I feel like I need a small success under my belt.
I don't feel particularly pulled toward open-ended FRP research at the moment...
3. Better layout: MorphicJS, STEP's Nile, Subform Layout, Facebook Yoga, Conal's Fran, Brent's diagrams
The idea is that dumb things like centering elements should be easy, because we have math. It's all just relationships between quantities, right?
Subform takes an interesting approach here, which simplifies things greatly, but I fear may not be as programmatic as one would want. Need to do more thinking there.
r0ml's demo of Squeak Smalltalk was a powerful demo of turtles all the way down. Understanding Nile - Bret has a cool link on this I wasn't able to find, but I did find this one - seems like a worthwhile exercise. Re-watching the Lively Kernal videos with new eyes seems like a good idea too. MorphicJS and chatting with Jens could be quite helpful here as well. I'd be shocked if others didn't have projects in this vein as well - I just need to find the right keywords.
Can a better specification of our app's state help us build it?
Going to start with #5 because it's been on my mind for a while, and I've thought about it from a new perspective recently and it's been on my mind.