Future of Coding - Research Recap Three (WoofJS Workflow)

Episode Date: August 24, 2017

Over the last two weeks I had a suprise trip to Boston to meet with other researchers in this space. In preperation for the event, I spent most of the last two weeks building the WoofJS Workflow prototype. Notes here: http://futureofcoding.org/episodes/6-research-recap-three.htmlSupport us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

Welcome to the future of coding. This is Steve Krause. As you'll know if you listened to my last research recap episode from two weeks ago, you will know that my plan for this week, these past two weeks, was to look into other people's research into prototypes and interfaces that point towards the future of coding. But as things happen, that wasn't what actually happened over the past two weeks. Not this past Tuesday, but the one before, I got a phone call from Paul Trisano of Unison, who I've talked about before on this podcast. He invited me to a, quote, white writer's workshop for programmers who are trying to build future programming interfaces. That was happening in Boston the following Monday.

So this was so it took place last Monday. The way it worked is everyone who was attending the workshop needed something to present and then get feedback on. So I had a few different ideas about what to present. I wanted to come up with something that was top of mind, but also polished enough that I would get good feedback on it. What I eventually decided to present is my idea to combine Workflowy and Git, which I'm now calling the WoofJS workflow, because I built it into the WoofJS.com IDE. So let me tell you a bit about how that project ended up. I work at the coding space with students learning programming at all different levels of experience. And all students, but especially beginners, get stuck in a very common way.

When they work on a part of their project, they get lost in the weeds about trying to make that project work. They lose the forest for the trees, and they really forget what they're working on in the first place. So when I go over to help a student whose hand is raised and is stuck for some reason, the first question I ask that I train my teachers to ask is, what are you working on? What are we trying to accomplish here? And way more often than you'd expect, students look at you with confusion in their eyes and just shrug their shoulders. They've entirely forgotten what they were even working on in the first place. So my second question is, well, what step are you on? And this question works if they're working on

one of our guided projects, which have numbered steps. And so then they'll remember, oh, there's a list of steps. First of all, they forgot about about that so then they'll go hunting in uh in their open tabs for that list of steps they'll scroll to find the one that they're on and then they'll look back at me for help and then i'll say well can you read it to me and they'll read it to me and then now finally we're both on the same page about what they're working on and sometimes that's all i need to do in order to get a student unstuck just remind them what they're working on and they can solve their own problems from there even if they need more help the fact that we both know what they're working on is a big step forward so that's one problem that i want to solve with this new tool the second

problem i want to solve is that this whole problem can be made even worse when a student is working on their own creative project that doesn't have a list of steps that we've created for them. So we love when students work on creative projects. However, when they get stuck, I can't say, well, what step are you on? Because there is no list of steps. That's why I always encourage my students to create a list of steps for their project. It's basically like an outline that you would make for an essay in English class. But just like in English class, students don't like making outlines. Or just like in math class, students don't like showing their work. They just like going for it. And it's hard to communicate to a student why it's important for them to show their work or make an outline until they're already lost

because they haven't done that. So my idea to solve all of these problems is to create an integrated outline tool that will help students stay on track with what they're working on, and it's integrated into the project. So it's not a separate sheet of paper that feels disconnected from coding. It's right on the same screen that they're coding in. It's at the top of the screen, so if they ever lose track of what they're working on, they can see in big letters right at the top of the screen. So if they ever lose track of what

they're working on, they can see in big letters right at the top screen, that's what I'm working on. Then I had this other idea that instead of just being a flat list of steps, it could be a nested list of steps because in programming, we have tasks that have subtasks that have subtasks that have subtasks. So really, this tool could be a top-down programming assistant that allows students to break their tasks into smaller and smaller tasks and then click on any one of those tasks all the way nested deep and that task now becomes the task you're working on it's its name is big in big letters at the top screen and the path the breadcrumb trail of of its parent tasks are above it kind of like a file path. So you can see

how the task you're working on now relates to the larger project. So it makes it much harder to lose the forest for the trees because both the trees and the forest are all right in your line of sight in the same environment you're working on. The other big idea I came up with is that I noticed that this branching structure is similar to the branching structure of Git. And I could turn every one of these to-do items into its own isolated branch of code. So you can go work on any piece and not affect any other to-do. And then when you're done with any task, you just hit the merge button and it merges it up. It creates a interface for you to merge the code you've written of this subtask into the parent branch.

What's exciting about this is that I think it could enable collaboration at many more layers deep than we currently have now. Right now, if I go to create a pull request on someone's repo, I'm just collaborating one level deep. Maybe I'll solve one issue. But in order to solve that pull request, I need to solve a bunch of subtasks, and nobody can help me with those subtasks.

But if I was able to outline my whole plan to solve this issue in a nested way, someone could come along and see that I need help with an issue four levels deep, sorting a list, and they could just work on that. And then at my leisure, I could merge that into the larger projects I'm trying to complete. I think it could also help if you're working as a novice under a mentor programmer, the mentor could help you sculpt out this outline, and then the novice could go tackle each task by themselves.

Because I noticed as I mentor my teachers and my other colleagues in programming, that this outlining, keeping track of what you're working on, staying focused is one of the hardest things that they work on too. Even I have trouble with this workflow sometimes, and I have to do it on a scrap of paper. And I'm constantly frustrated and wondering why git commit messages seem to work backwards. You come up with a plan of what you're going to do in your head, then you do it in code. And then when you're done, you now write what you already did. Like, isn't that backwards? Shouldn't you first write the plan for what you're going to do, then do it, it and then hit the done button and so that's kind of how the product is going to work

when i found out that i was going to be presenting on uh in a week i i quickly made a plan for this tool what it would look like how it would work and i built it thursday friday saturday and sunday i kind of worked like five about five hours each day so it's like a 20 hour project and it was tricky and i wasn't sure i was going to get it done and it's buggy and not super intuitive now but i think as a prototype it kind of shows generally how this tool would work So let me walk you through it. You can try it yourself at wolfjs.com slash workflow. And I will also put a link in the notes to the presentation I gave on Monday, it has a bunch of screenshots to the tool. So you can so if you don't want to play with it yourself, which I would understand because it's buggy, you can kind of kind of walk you through it here um i i walk you through creating

the base the beginnings of a floppy bird project where you you first add a to-do that says you make the bird and then under that you have um make the bird fall and so you go to make the bird and and when you're done with make the bird you hit merge, that kind of thing. Currently right now merging isn't super pretty. Basically I put the parent code and the child code next to each other and give you a diff and you kind of have to copy and paste the child code into the parent until you think the parent is merged as much as you want.

Then you hit the done button and the child kind of goes away, it gets crossed out, and the parent now has the child's code within it. One thing I didn't work on at all that I think will need some thought is how to get changes from a parent or a sibling into a different child or sibling, because that's, I think, gonna be a common use case kids are going

to make a list of tasks that aren't quite as isolated as they could be and so they're going to want to move code around i guess they could just be copying and pasting it from branch to branch but it feels like we should have a more semantic way to get changes from from branches to branches other things that i didn't really work on that will need work before i release this to students um is is permissioning so because i think this really enables collaboration but i don't understand i don't quite have a plan for how to allow students to edit each other's branches and submit pull requests to different tasks. So that requires some thought.

And there are various bugs. The code isn't quite as isolated as I would want. And sometimes I want it to not be isolated. So if you edit a parent task and you haven't changed anything in the children, I kind of want the parent changes to flow to the children. But then if you do change the children and you change the parent, but they don't conflict, I feel like it should prompt you in the child if you want to accept the parent changes. Various things like that. Because I rebuilt Workflowy, which was mainly what was so time consuming when I was building this. But if I really want to do this right,

I have to basically rebuild Git into this task. I'm not going to rebuild everything. I'm not rebuilding rebasing and stuff like that. I'm not rebuilding some of the more advanced features, but I really am rebuilding a lot of the core features of Git, and that's going to take more than 20 hours. However, even if I built all that, I still think the core interface and workflow isn't as user friendly as

i think it needs to be i think it's maybe 10 times more or maybe 50 times more user friendly than using git on the command line is right now however i think it still needs to be like another factor of two times more user friendly before i release this onto my students. But I hope to be able to do that at some point. I'm not going to continue with that right now because there's more, I think, transformative research that I can be doing, more interesting prototypes I could be building. And there's also lower-hanging fruit to improving Woof

that I need to be working on. So I'm going to put this prototype on pause, but I do want to tell you about it because I think it is interesting and could spark some ideas in your heads to make other cool prototypes or products. So check out the prototypes. You can check out the code on GitHub,

and you can see the paper in the links to this podcast. So let me tell you a bit more about the writer's workshop that I was at. It was really exciting because there were some real luminaries of the industry that were there. So Jonathan Edwards, I knew a bit about before this conference, but I got to read maybe a dozen of his blogs while I was there. I really hope to read all of his blogs. I think he has like around 50 over the last decade. And it's been really exciting that he's been working on this exact same problem that I've been working on, maybe with like a little bit of a different focus, but almost entirely the same for the last 10 years.

So there's really a lot for me to learn from him. So it's exciting that I got to meet him and I get the sense that he's interested in continuing the relationship and maybe even coming down to New York to meet more people like me and him that are interested in this kind of thing. I told him about how I'm a part of this meetup group, future programming, and we have a Slack, so I invited him to Slack. So that was all very worthwhile. He's an interesting guy. And then I also met Richard Gabriel, who is known for the Worst is Better essay about why C beat Lisp, because it was just faster to market. And I met Mel Conway of Conway's Law, who's, Conway's Law talks about how an organization

will create systems that resemble the organization so it was really interesting to see his work and and hear about what he thinks about and there were a lot of other interesting people including paul who was the one who invited me so um one of the most prescient piece of feedback i got is um basically why are you here talking to us about this prototype why didn't you just try it out on your students like i i think what they were trying to say is this isn't theoretical research this is product development and you have a product that's used and you have students who use it why didn't you just go to them like you know we could just speculate about how well this will work with students and if they'll like

it and if they'll use it, but if you have the students, why don't you just test it with them and get real data? They're the real arbiters of whether or not these things will work. That was kind of what I wanted to believe about product development and research, but I was surprised when these researchers and luminary people suggested that as well. And I think the reason they did is because my research isn't that theoretical. It's pretty practical stuff.

I'm not creating proofs. I'm not... Yeah, my research is mostly practical up until this point. So I think that's good feedback. I submitted this paper that I'm linking to here about the WoofJS workflow, which I call in the paper my top-down programming assistant.

I submitted it to the SplashPX conference while I was there because the deadline was the next day, but I think I'm going to rescind that application because it's just not worth it to me to fly 1,000 miles and pay thousands of dollars. Well, maybe not 1,000 miles, but fly all the way to the West Coast and to Canada and pay thousands of dollars to talk about things that I could talk about just as well from my room in New York City like I am

now I can make videos about these things which I'm planning to do I'm planning to make videos about a lot of my prototypes so that the people who want to actually see these things and not just hear about them can do that but yeah yeah, so I think I'm not going to do the conference thing, or at least not do it very much, maybe once or twice a year. Part of the reason I'm not going to do it is I really don't like traveling. So, and traveling is expensive. So that's the conference. One other thing I want to tell you about the conference is that Paul, who invited me, gave a really, really compelling talk about, I think, that does a good job defending why, defending his approach to creating the future of programming and how it differs from mine and Jonathan Edwards.

So Paul started where Jonathan Edwards and I still am, where we're trying to create more intuitive interfaces to programming so that anyone, even beginners, can code. So we're trying to kind of raise the floor, if that makes sense, like make it easier for people to get into programming. So Paul's early demos are these structured editors for a Haskell-like language. And that's what really had me interested with what Paul was doing in the first place. Over time Paul's moved towards building more powerful mathematical functional abstractions that enable programmers to do way more powerful things, which is amazing, but he's kind of left behind this vision of making programming easier for beginners.

He's kind of more raising the ceiling than he is raising the floor, if that makes sense. And I really admire his task. He wants to make programming on a cluster of computers as easy and intuitive as programming on one computer. So his vision is, you know, you build Twitter in a weekend or in a week as your learn-to-coding exercise, and then it works for a few thousand people at the same time. But if you want to scale to billions of people, it's going to take hundreds of engineers and years to reach that kind of scale

because you're going to have to be doing all sorts of DevOps and computer-to-computer coordination. Why can't that Twitter that you build in a week or weekend scale to billions of users just automatically? And his answer is that we don't have the right abstractions to do that. We don't have the right, the languages aren't built for that. So that's what Unison is doing now. He's building a language that's designed for scale and clusters.

And the talk he gave at this workshop was making the case that this is a more powerful way to go because when you raise the ceiling there's more room

like up up in the ceiling to create new abstractions that are more powerful and the floor can always catch up so one argument he made is would you rather a brain to computer interface to x86 assembly so you could type x86 you could type x86 assembly as fast as you could think. Or a dumb Emacs text editor interface to a programming language of today, like Python. Or a programming language from 10 years into the future. And most people, I think, would prefer a text editor to a programming language of today with its more powerful abstractions than a brain interface to x86 assembly. And that's because what Paul argues is that a more powerful programming language lets you do less work.

And so even if it's harder to actually do the work there's just less of it so it was really compelling i'm doing a bad job of explaining it but i it hasn't made me want to switch tasks and be more of a abstraction person if if you will like i don't want to drop everything and go help Paul build Unison. But I do think it's compelling. And I think that potentially what my research will lead me to is once Unison is more solidified and the runtime is working, I could spend some time trying to build a better front end, which could be similar to what Paul's early demos looked like, or maybe more visually appealing, more visually intuitive with shapes as types or other abstraction interface visual metaphor ideas. Okay, so moving on to the next two weeks, my plan going forward. So I really hope for

the next two weeks to actually be doing research into other people's prototypes and demos and research. I've got a number of new links from Paul. I want to make it through all of Jonathan Edwards' like 50 different blogs over the last decade and then reach out to him and get him on the podcast, which will be a really wonderful conversation, I think. I found this website Expressions of Change while I was reading old Unison Gitter conversations. And it seems to be researching like the single question of how do we make changes to code semantic. And I think it's a really wonderful question because as the guy says, code is constantly being changed, and that isn't built into our languages. So similar to how Paul says, our languages are built for one computer, this guy would say our languages are built for our code never changing.

Both assumptions are crazy. And Paul's unison has a really interesting refactoring story that makes them semantic, but I think this guy has some also really interesting research as well, so I want to look at his website. And still I want to dig into Imp, the spreadsheet plus relations plus time project, and I also want to spend a day or two with Eve because I really need to give it a fair shot because I really respect those guys. So my hope is to just do research for the next two weeks, but I really am obsessed.

I'm becoming more and more obsessed with my spreadsheets plus streams idea. To recap, it's an idea that will allow you to make interfaces through functional reactive programming, FRP. And it's really most similar in my mind to CycleJS, but it's also pretty similar to Elm. My name for it is StreamSheets. I know, very original. Maybe later this week, or hopefully not until late next week i actually dig into this

and um following paul's advice i want to prototype on paper how i would build to do mvc and a basic chat app before i go to code because i think that like paul said there's a lot you can work out in your head which will save you dozens of hours of time in code because when you're coding, you're dealing with all sorts of ancillary problems that just take up your time. And when you're prototyping on paper, you could kind of get to the meat of it.

So some other notes. I ended up buying all the technology on which I could edit these podcast episodes i first heard my chromebook but it was a little too slow so i bought a 500 pc that was like a snail so then i even slower than my chromebook so then i bought a the cheapest imac i could for 1100 that was really slow compared to my chromebook, even though it had like twice the RAM or like four times the RAM and like way more cycle processing speed. And then I bought a more expensive iMac, but that was just like $1,500, way too expensive. So I tried an iPad Pro and that was

wonderful for $650. I was editing exactly what i wanted to with this wonderful app called hakusai 2 and it's free with the ability to buy extra features but i really don't even need those extra features and then i saw on a lark that the same app i was using to edit audio on my ipad is available for the iPhone. And so I pulled out my phone and tried it out, and it was really just as fast as the iPad Pro. So I returned all my computers and iPads, and now it turns out the solution this whole time was in my pocket, and so I'm now editing these episodes on my phone,

which is kind of funny. Another thing that changed logistically is I used to keep track of some of the to-dos for this website and podcast and research project in a Google Doc. And I've since retired that Google Doc, rest in peace. And I will be putting all those things into GitHub issues. So if you want to see what I'm working on, what my to-dos are, they're there. I think I have like 20 or so to-dos at the moment. Feel free to create more issues for me if you want me to do anything else, or feel free to comment on any of those issues. I'm really excited about having this whole thing as open source as possible. One last note before I leave you is that I wanted to let you know that I'm entering a bit of a busy time for the coding space, my after school computer science program for

kids in New York City. We are expanding the program to the Upper West Side along with the Upper East Side program that we already have. So our goal is to teach 400 students every week, and we're going to need between 30 and 40 part-time teachers in order to make that happen. So we have about 15 part-time teachers hired at the moment, so we have a lot more to go. So I probably have like 50 or so interviews that need to happen in the next three weeks. I'm trying to consolidate them all onto Tuesdays and Thursdays through this service called You Can Book Me that allows people to book times in the slots available on my calendar. And I hope that will be enough. And

I'll be and I'll leave me Monday, Wednesday and Friday, mostly free for this research and this podcast. But sadly, that might not work out in reality as well as I hope in theory. So that's it for this week. Keep an eye out for my updates at my journal, futureofcoding.org slash journal, and futureofcoding.org slash links, because that's where I hope to be mostly this week.

And I have a really fun interview coming up with my old boss lloyd tab from looker so hopefully that will come out early next week that's going to be a really exciting one and i will talk to you all about my research in two weeks see ya