| 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 4th.
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?
Go ahead and read it for yourself ;-)
While my strategy still needs work, my mission is becoming clearer.
Yesterday, November 9th 2017, I interviewed Emmanuel at Bubble.is. It was useful to think about my goals in relation to theirs. Bubble's goal is to empower businesses to create apps without code. That's an amazing goal. But it's not my goal. Why? When I use Bubble, I don't feel joy. I don't feel myself getting smarter. I'm not thinking powerful ideas in the Seymour Papert sense. Bubble is the cheapest way to get something done. It's about the end-product, the business solution. That's not what programming is for me.
For me, programming is a medium for creative expression. Just like writing. It's how I articulate what's in my head, refine my ideas, and communicate them with others.
All media -- writing, pictures, coding -- can be used either for business or art. You can write advirtisement copy or a fictional short story. You can create an entreprise software company or share a simple animation with friends.
The same goes for bicyling. Steve Jobs saw the computer as the "bicycle for the mind." You can bike to get somehwere faster or to workout or to simply have fun.
Pencil Code's mission is to "make programming as simple and powerful as using a pencil." That's pretty close to what I'm going for.
Let's go with this for now: "empowering creative expression through programming"
If that's the mission, what's the vision?
Here are some quick phrases I've found effective at communicating what I'm trying to do:
- "Squarespace for apps"
- "A tool as powerful as JavaScript and as easy to use as Facebook"
- "A tool as easy to use as Scratch but with a really high ceiling"
Those phrases more or less sum up the picture I have in my head. However, there are a few additional principles that are important. If we made a "Squarespace for apps" that didn't embody these principles, I wouldn't consider the job done.
You can read them here.
How do we get from here to there? Elon made it seem so simple in his first plan for Tesla:
Build sports car
Use that money to build an affordable car
Use that money to build an even more affordable car
While doing above, also provide zero emission electric power generation options
I think it's safe to say that I don't know enough to declare my plan so succiently. Yet!
There are so many pieces to this puzzle that need work. Think about all you need to learn now to code:
- the language and syntax
- the comptutational model
- the underlying technology stack (the internet, the web, the app store)
- setting up their workflow to allow for fast iteration (webpack, hot reloading)
- connecting to databases (SQL, NoSQL, ORM, deployment)
- setting up user accounts and authentication (Rails, Devise)
- setting up deployment (heroku)
- eventually helping with scalability (redis, load balancing)
- collaboration with other developers (git, github, pull requests, issues)
- version control (semantic versioning, releases, cache busting)
- package and dependency management
No wonder coding bootcamps take three months!
My main strategy question is whether I want to build or research long-term.
On the one hand, builders get shit done. Do I imagine myself starting a company like Looker or Bubble? Creating a new open-source langauge/platform like Linux, Clojure, or Scratch? One benefit of working on a single project is that it could consolidate further innovation on the remaining problems (listed above) by employees and/or the open source community.
On the other hand, it all starts with research. Do I imagine myself staying in research-mode in perpetuity, like Alan Kay or Bret Victor? Would I be fufilled doing research, making prototypes, and publishing papers?
It's clear that both models move the world forward. Without foundational research, people wouldn't know what to build. Without people starting projects, none of the great ideas from research would get built. I guess it comes down to what am I best at? and what do I enjoy most?
Those are two questions that I don't know that answers to. Yet! Luckily, I don't have to decide now for forever. I can take each strategy out for a test-drive, see how it goes, and change later if necessary.
Besides, I'm getting ahead of myself here. Before I take on "building the future of coding" as either a builder or researcher, I need to wrap up my work with The Coding Space and WoofJS. This means communicating what I learned about teaching kids to code over the past years. Writing this will take at least a few weeks, maybe even a few months if I do it justice.
I will also now start looking into various funding options for my work here, particularly for the research and non-profit models because I have much more questions about it than the for-profit model. My current thinking includes:
- starting a Patreon
- talking with foundations
- talking with corporate sponsors
- talking with research groups
- talking with think tanks
- talking to media companies about get paid for my writing content directly
I'd love to have $1k per month coming in in a sustainabile way within the next few months. I really admire Nicky Case and he seems to have figured out how to support himself through Patreon.
After I finish writing about teaching and learning coding, my next step will be picking what to research next. Regardless of whether I'm a builder or researcher, I'll still need to do research as my next step.
Because of how easy it is to understand a program written in the FRP-style, I am intrigued by finding a way to make functional reactive programming more intuitive via visual metaphors. Doing research here would mean:
- reading Conal Elliot, playing with Fran
- playing with Haskell's Reflex
- prototyping Streamsheets
- prototyping FRP Scratch, FRP Woof
Andre Staltz made an interesting research suggestion two months ago. Clearly the coding platform of the future will have some "expression builder" that, as Glen Chiacchieri says, will look more like math on paper than math in Google Sheets:
Given that this is a core component that every tool in this space will need, why not build it into a library that we can all use? The Ace and CodeMirror text editors are underratedly helpful in enabling innovation here. WoofJS would be significantly worse and more fustrating to build without them.
I imagine this library would be quite similar to Blockly, which enabled me to build two prototypes (Cycle v1 and Cycle v2) very quickly. The downsides of Blockly were 1) that it was built on top of Google Closure, and 2) that it didn't provide enough customizibility, particularly around the shape of the blocks, which greatly limits the level of innovation that can be done on the computational metaphors.
In summary, here's my tentative plan:
-
Launch a Patreon. This will happen in the next week or three (because I'm taking off next week for Thanksgiving).
-
Write. Mostly about teaching and learning to code. 4-8 weeks, so Dec and Jan.
-
Research. Possibly into visual metaphors for functional reactive programming, or a library for visual expression building. 4-8 weeks, so Feb and March.
-
Build or Write. Figure out whether my research will turn into a project or essay. If it's a project, build it. If it's an essay, write it. 4-12 weeks, so April, and possibly May and June.
-
Iterate. Re-evaluate progress and create the next draft of this plan.