Future of Coding - Research Recap Two

Episode Date: July 31, 2017

Learn about what I did over the last two weeks!  Notes here: http://futureofcoding.org/episodes/4-research-recap-two.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. So I'm two weeks in, and I've been hard at work doing research and getting my friends and mentors on this podcast as guests. You've seen some of that if you've been following my journal at futureofcoding.org slash journal, and following the podcast wherever you listen to it, at iTunes or Google Play or Stitcher, or you can actually stream it on my website at futureofcoding.org. So most of this episode will be summarizing the research that I've been doing over the past two weeks.

That's the purpose of these research recap podcasts, episodes. But before I get into that, I wanted to talk a little bit about how this process has been working for me, reflect in a meta way about the system, my schedule, how I've been thinking about this lifestyle. So, and before I get into that too much, I want to just reframe and talk about the purpose of this entire project in the first place. So, and this has been evolving, but the purpose of this project that I see now is bringing the future of programming nearer. We all have slightly different ideas about what the future of programming looks like. And mine are evolving as well, just like everybody else's.

But I think the core idea here is that programming needs to be better. It can be better. And things like this don't happen by themselves. Sometimes it's easy to see progress and reflect upon how the world is just constantly getting better all the time and think, well, if I just wait long enough, someone's going to solve this issue and the world will just be better. And in some ways that is true and you can be complacent in that way and let others innovate for you. But in other ways, I think that we each have responsibility in the areas we care about to bring the future closer and to keep moving things forward. Where I like to think about, a good example of this is Amazon. Because to me, and I think many people, Amazon seems inevitable.

Obviously, the internet will have a superstore where you could buy anything at incredibly low prices. And I don't think Amazon was inevitable. And if Jeff Bezos and his team didn't, you know, through force of will and smarts and effort, make Amazon what it is today, who knows, maybe it would cost a lot more money to buy things and I'd have to send my payment information to a bunch of different providers. Maybe I'd have to wait more than two days for free shipping. Who knows? And so reading the book on Amazon, I got the sense that without these people,

who knows if this company would exist, but now it feels inevitable. And so I think in the same way, well, I think if we succeed and we make programming so much better than it is now, people might say, oh, well, of course, this was the answer. Of course this was going to happen.

But from where I'm standing right now, it's not inevitable that this was going to happen. But from where I'm standing right now, it's not inevitable that this is going to happen. And we need people like the people I interview on this podcast, like me, like listeners like you, to continue moving this forward. So that's what I'm trying to do here. So when I started this research project about making programming better, I used to think this meant building the future of programming by myself. I used to think this meant building the future of programming by myself. I used to think just the longer I sat with a computer by myself, the quicker the future would arrive. But I have a much broader perspective now. I'm realizing that this is a group project.

When I say group, I mean the whole world, this whole community is working on making the future of programming happen. And part of the reason it's a good group project is because there are a lot of moving pieces. There are a lot of technologies. Another is there's a lot of really core, difficult technical challenges here. And then I think potentially what I'm most excited about or interested in is building abstractions that encourage the right ways of

thinking and and it's just really hard to come up with abstractions when you think about the kinds of mediums that have changed the way humans have thought and enabled more powerful ways of thinking there haven't been that many jumps in all of human history the fact that we even wrote things down at all a a phonetic alphabet, Roman numerals was a big deal, but then the Arabic numeral system with zero was a big deal, mathematical notation, Leibniz's notation. There aren't that many of them,

and each one was a huge jump in the thoughts that humans could even think. And I'm thinking that it would be really amazing to create the next generation of those kinds of tools. But it's hard. And we need as many people as possible noodling on these ideas, throwing up prototypes, talking to each other about what they're working on. That's the way we move forward. So the past two weeks, I've mostly been doing research into other people's prototypes, talks, essays, and products. And towards the end of this two-week cycle on Friday, I spent a bit of time prototyping some of my own ideas, which I was getting really excited about. And I'll tell you about that in a bit of time prototyping some of my own ideas, which I was getting really excited about. And I'll tell you about that in a bit. But before I talk about any of the links or my own prototypes, I want to just say that doing research into other people's products and videos and links and essays

was so much more tangibly helpful than I thought. Part of the reason I started this entire project in the first place in a structured way with a podcast and a website is because doing research on my own in a vacuum just felt so unproductive. Like I wasn't getting anywhere. The more links I clicked on and read about, the more links that I would find because each link linked to other things that I hadn't already read. So it just became overwhelming and it seemed like an unending problem where I wouldn't, we're just in a hamster wheel, I wouldn't be moving forward. However, now that I'm doing good note-taking and I'm taking notes about all the links I'm reading and I'm referencing my journal, how they've influenced my thoughts, I can go back and realize, oh my goodness, this prototype idea that I love that I came up with on Friday is a combination of these two other ideas that I saw videos of the week before.

And I didn't realize until I consolidated some of my research for this review episode that those ideas came from there. I thought they just came from my own brain, but I stole them from these other people. So that was a really powerful thing to realize and has made me more excited to continue doing research as opposed to prototyping. Because who knows how many more of these ideas will be sparked by other people's talks and discussions. So, for example, I was inspired by Mark Mahoney's prototype about version control that was optimized for learning, which inspired my thoughts about a work-flowy Git idea. I've mentioned this a few times in different episodes and a lot in my journal. I'll talk more about that today. I was also inspired by Bill Burdick's Leisure video, which inspired my thoughts around blurring the line between viewing and editing apps. I think he did a good job of showing us what the world would look like

if the Chrome inspector was much more prominent in a web browser. And part of why I'm excited about this idea is that when I teach coding to kids and I show them how the Chrome web inspector works and how they can change things, their minds are blown. They love it. And it makes me, you you know i never wondered before his video like why do we hide that away in a place where people can't see that people would love to see that it would i think it'd be really empowering so and then i spent a lot of time this over the

past two weeks working with lambdo which was really great because i've been meaning to look into them more and i finally did the deep dive i installed ubuntu on my chromebook i spent the like two days basically just installing it while i was watching other to look into them more. And I finally did the deep dive. I installed Ubuntu on my Chromebook. I spent the two days basically just installing it. Well, I was watching other videos and whatnot, but I spent the two days installing it. I played around with it. I had some cool Slack conversations with the founders.

Maybe I'll have them here on this podcast. I really loved it for a lot of reasons. I think the reason I loved it the most is that it implemented ideas that I've been meaning to implement myself. But they did it and they did a better job than I probably would have. And yet I still found that their idea, like, you know, the prototype they've come up with is lacking and it is far from what the world needs. Maybe I'll get there in a bit. I'll have to explain why. Oh, well, here, I'll just I'll say briefly i think the reason lambdo and luna potentially you

know i don't really know luna too well but potentially what's and even unison potentially what i find missing from those um while they do eliminate all syntax errors and all type errors and all runtime errors uh they don't enable comprehension. The syntax is just still too hard to read. I've spent years programming Haskell. And maybe if I spent a decade, it would be easier for me to read. But that's not the point. We don't want people to have to spend a decade

learning how to read Haskell code in order to understand a new program. Things need to just be better than that. And so while LambDew is definitely an amazing piece of technology, an amazing prototype, and has moving the conversation forward, I think we still have room to go, which is exciting to me. I was also inspired by struggling with understanding the LambDew code base and even installing it. I was inspired to think more about how intuitive and user-friendly working with software needs to be.

It needs to be you go to a website, codenow.org or codenow.com, and you immediately start coding. Installing other packages is just clicking a button. There's no terminal involved. There's no installing really involved. It works as seamlessly as Facebook. It's just instead of friending someone, you're adding a package. Instead of creating an event, you're creating a object of some sort. One thing I wanted to mention briefly is that I've been really enjoying using GitHub pages and a GitHub repository as a content management system. It's really a flat structure, and I just put my HTML, CSS, Markdown files in this directory.

I link between each of them. I can edit right in the GitHub UI right there, which is amazing. I could also, if I want to make a bigger commit, I can pull up in Cloud9 and edit it there and commit it there. It's all good. I really enjoy it. It's simple. It's clean, easy to understand, easy to get started, free, which is amazing. And what I really love is theub markdown formatter has so when you make a header you can you know when you highlight over a header there's a link button which you click which will link to that that header which i've been using liberally in the past few weeks and i really like that i can link my notes to notes to notes and it's all linked and i really love it um it

makes me a little anxious because i'm worried that I might mess up my URI schema at some point. I want to change where certain files are located. Well, I really can't because I'll break all those links. So I probably won't do that. Potentially I should link to commit hashes instead of linking to the current version of the file. Who knows? And the other thing I'm worried about is that I'll create two of the same headers at some point in time and then I'll break links because it'll

go to the first one and not the second header so I'll have to keep an eye out for that but if you've been wondering why my headers have been gotten longer and longer and become more descriptive the reason is I'm trying to avoid collisions in the future. Okay, great. One more thing before I get into my research. I want to talk a bit about my schedule. So while I was looking over my notes for the past two weeks to create this podcast, I was struck by the fact of how little work actually got done.

Well, how little time I spent on this project. I really only worked for like five or six days, only a few hours each day, but how much I actually got done. So on the one hand, I'm really proud of the efficiency. I produce a good amount of content and insights for a small amount of effort, but I don't think I'm at capacity. I think I could get more done with focus. So where my schedule is at today is I work around two full days a week. When I say two full days, I mean like 16 hours. It might not be a full day of continuous time, although continuous time is important and I try to do that. So, two full days of research here every week. One day a week I spend on the coding space, my after school program.

Then I started with my co-founder Eli Karev and Nicole Kellner. So, I respond to emails. I help on the coding space, my after school program that I started with my co-founder Eli Karev and Nicole Kellner. So I respond to emails, I help with the curriculum, various other tasks, meeting schools and people and whatnot. One day a week, I'm mentoring a few people who are developing the WoofJS programming language and WoofJS.com. So because that's a really wonderful project that I love to see out in the world and, um, I love improving. So, so I, I dedicate that, that kind of time. And then another, like the last one day a week of the work week will be doing research and also like random podcast tasks, emailing people, trying to get them on the podcast, organizing the website, other stuff like that. So like, for example, for my calendar this week, Monday,

today, it's all research recap. And it sounds like I'll probably get done a little early. So maybe I'll have some time for some other podcast tasks. Tomorrow, I will be working on the coding space with other podcast tasks, because I've snoozed so much of the last few days is emails to tomorrow. So I could focus on research on Friday and today, which I think was really great. It's really hard to get to be focused. And I think procrastination is a really useful tool in order to create focus. And part of the reason people have trouble being focused is that throughout school, they've been drilled to not be procrastinators but sometimes procrastination is the thing you need if you want if you want focus especially on research

um my one of my idols richard feinman talks about how he he would always tell people that he was irresponsible so they wouldn't give him responsibilities we could focus on his research and i really admire that and i I hope I see my future telling people that I'm irresponsible so I can avoid certain responsibilities that will take my focus away from more important things. So on Wednesday, I'm going to be doing mostly research the whole day, but I might have to do some random inbox emails and tasks if I don't get them all done tomorrow. Thursday will be all tasks, no research. And Friday will be all tasks, no research. And Friday will be all research, no task.

I've done a pretty good job so far of keeping my Friday sacred for some deep research and thinking. And it worked really well last Friday. Partially with the help of my shower. If you look in my research journal, you'll see that Friday afternoon I was having trouble focusing with technology distracting me. So I hopped in the shower and took a long shower. Good thing we don't have a drought in New York. And I have a waterproof notebook in my shower, so I spent maybe an hour, maybe an hour and a half getting all wrinkly, taking like five pages of notes about different prototypes. And it was a really productive hour and a half.

So hopefully that offsets the waste and water that happened there. So in reflecting about my schedule, I see that there's not much time for real research during the week. So potentially as this moves forward, maybe I'll scale back on some of the non-research tasks. Like maybe I'll take a break from Wolf for a few months. Maybe I'll take a break from the coding space in a few months. I've also been thinking about watching less TV at night or having one less plans with family or friends per week so I can have an extra three or four or five hours every week towards research. I think even just a little bit would be helpful here. So I think that's all the meta stuff I want to talk about. Let's talk about my research. So the most impactful link I think I saw the entire,

or potentially the most impactful thing that happened this entire week was watching Alan Kay's videos about how to invent the future, his Y Combinator videos. And really there was just this one part about those videos. I'm sure there was a lot that I had subconsciously that was good. But this one part that I really took to heart is having a relentless problem focus. In the past, I've seen this advice before, and I intellectually know that you should build a product to solve a problem.

But often in the moment, I get distracted about that, I've seen this advice before and I intellectually know that you should build a product to solve a problem. But often in the moment, I get distracted about that and I lose sight of the fact that you have to solve problems. I'm a technologist at heart and I really like building things for their own sakes just because they're cool, just because they're fun, just because I enjoyed it, just so I could share the code with someone. Similar to how an artist makes art for its own sake. Art doesn't solve a particular problem sometimes, it's just fun to make, fun to share. However when I'm trying to build towards the future of programming, there is no place for this solutionism. And when I say solutionism, I mean looking around at the tools you have in your tool belt, looking at the Lego pieces on the floor, and asking yourself, what can I do with these?

This methodology becomes quite dangerous when you're convinced that someone would find that thing that you happen to be able to make with the tools at hand useful. That's the perfect recipe towards building a product that solves a problem that nobody has, or as Eric Ries says, achieving failure. I've done it many times, and I've seen many friends do it, and it breaks my heart when the smartest, the brightest people we have waste their most precious resources, their time building things

that are art projects basically that nobody will use they don't solve any problem so Alan Kay does a great job of disabusing me of these tendencies for now, but it's a constant struggle for someone like me who just loves building things. So the way he put it is that you have to focus so intently on the problem that you don't even realize how hard it will be to solve that problem.

It's like you need to build a custom programming language in order to make this thing work? Build it. You need to build an operating system from scratch in order to make your vision, your solution to this really hard problem work? Go for it. And the way he put it was a really big kick in the butt for me because I've always shied away from my most ambitious prototype ideas that would take more than just a few weeks to hack together. While this is a decent technique to avoid getting bogged down in the technical details of a bad prototype, it also precludes me from stumbling into a truly breakthrough idea whose subcomponents don't even exist yet, because that's how breakthrough it is. I've been trapped in an innovation cycle where I'm just trying to make things slightly better than they are now, which isn't what we want. That isn't my goal. I'm trying

to make things drastically better. And if I want to make things drastically better, the subcomponents of the solution probably don't exist now, because if they did, someone would have already combined them into the solution. And that's what innovation is, combining subcomponents that already exist. Invention is inventing the subcomponents that don't exist in order to make your solution a reality. And that's what I'm excited about from that message. And one very, very important sub-skill here that I'm realizing I need to personally get a lot better at is recording problems that I don't see immediately solutions to. As an innovator, a business person, someone in the world trying to make the world a better place today, I often willfully ignore the ideas whose solutions seem too far out.

You say, oh, you know, the problem will be solved when we get to Mars. Well, no, no, no. We need to, like, solve problems today. We need to make the world a better place today. That's a moonshot. We shouldn't even think about that problem. We should be working on solving problems that have more immediate solutions. However, now that I am not a business person, or at least in this role I'm not, problem we should be working on solving problems that have more immediate solutions however now

that i am not a business person or at least in this role i'm not i'm working in my own personal r d department it's my job to think about these big problems that don't have solutions yet or not immediate solutions so i need to retrain myself to write down all these big problems and think about them especially when i don't have any clue about how to solve them yet i think that's really, really important. And I've slowly been getting better at that over the last week. So the fruit of being better at this problem-focused thinking is that I've come up with these wacky ideas,

maybe this one in particular that I'm really excited about, that I don't think I ever would have gotten to if I was stuck in my rut of thinking about what can I solve with the tools I have, my solutionism trap. think I ever would have gotten to if I was stuck in my rut of thinking about what can I solve with the tools I have, my solution isn't trapped. So here's how I got there. As I was trying to understand the lambdew codebase in order to do research into it, I realized how with even of my decades of programming in Haskell experience, I was unable to understand or even get the barest glimpse about how it all works together. I think it would take another dozen painful hours in order for me to get a good place with it. Of course, if someone on the team walked me through their code or they

had a bit more documentation explaining how the code worked, that'd help, but it would still be a struggle and it would be many, many hours before I was able to understand how the code even works, let alone customize things or fix a bug. And I wanted to. A bug happened, I wanted to solve it, and I just felt lost. And I'm someone who has the most confidence in the world and the most experience doing this stuff, so imagine anybody with just a few days of experience or a few weeks of experience, it's a lost cause. To be clear, the Lambda guys seem brilliant, and I'm sure their code is really clean and easy to understand.

And that's the point. Even in the best-case scenario, representing a software program as a series of folders containing plain text does not lend itself well to comprehensibility. The way I see it is you have code that's all the way over to the left, and then all the way over to the right is the output, the user interface, the behavior the user interacts with. And if you're a user and you're interacting with the thing all the way over to the right and you want to change something, you have

to travel all the way to the code and pick through it, shuffle through it, and tweak things and see all the way over to the code and pick through it, like, you know, shuffle through it and, like, you know, tweak things and see all the way over to the right how they change. It's crazy. It's crazy how far apart they are. And so my initial idea, metaphor, goal for this problem was what if we could make that distance between the left and the right, the and the the interface that users work with closer together what if you were looking at your app and you could just peel back you know just peel back

from the corner and look under the next layer of abstraction and what if there were a bunch of layers of abstraction you just peel back layer by layer you know component by component you like there's one component is broken you peel back you see if you could fix it at that layer of abstraction but if not you could peel back that layer too i think this is this is this idea that i've stolen from a bunch of different researchers in this space um the idea that if there are good user interfaces all the way down the data itself has a user user interface um but i've never seen it it really done in a in a reasonable way in a in a real um the real context where you have a gorgeous app and you peel it back and you have another usable interface where you can customize the top level

app so that was the problem that i really had no clue how to solve but i was excited by the problem and how powerful it would be if we could solve it and And if anyone, when they're on any app, could just customize it right there, submit pull requests, and see how apps work, hit the clone button and boom, they're off making their own app right there. And you don't even have to go to GitHub. It's just all there. It's all self-contained in the app.

Like, you know, GitHub kind of becomes integrated in their Chrome browser in this weird way. Or even on your phone, if you're using an app on your phone. So I spent a lot of time on pen and paper drawing out what I think this could look like. And I had a few interesting ideas. The idea that got me most excited was

if we think of the bottom layer of this system, if we think of layers of abstraction the bottom layer is are just streams and what i like about this so much is that streams are an unbelievably powerful data type when you have streams you can define your entire app declaratively and reactively there's no mutation of data you just define everything once and that's the way it is forever so so that got me thinking and i eventually realized that what would it look like if every layer of the app all the way to the top were spreadsheets because streams really are just you know spreadsheets and streams of streams could be spreadsheets that contain spreadsheets, and you can filter spreadsheets, and you can aggregate spreadsheets.

And even the HTML elements themselves can be spreadsheets, where you have each attribute is a column, and you could have... And different rows would be sibling elements. And then if you want to have an element with children elements, you could put it in there in its own subsheetsheet. So that was the thought I had. Spreadsheets all the way down with an HTML element viewer on top.

Who knows? This idea probably won't work out, but I'm really excited about a lot of the implications. In particular, if it's spreadsheets all the way down, the database layer, persistence layer probably has an amazing story because SQL is often the database layer of choice for applications. And if things are already in a spreadsheet-like format, you know, that seems like a great story. I also really love this because it forwards the idea that I've fallen in love with where you think of your app as a big event stream

where the data you actually care about is just a reduction of everything that's ever happened. And what's great about thinking about your data like this is there are no mutations in place. You can undo things infinitely as long as you have unlimited space. And it's just a productive way to think about things. It's a very functional, reactive way. And if we could do that all the way to the back end

and all the way to the front end, I think that Datomic is a really good example of this on the back end, we have a really magical system. As a side note, I think it would be really neat if someone made Datomic a hosted version of it because I would love to play with it, but I'm not going to mess with that. That sounds like way too much work to host my own Datomic instance and whatnot. So before I move on, I want to say that while I'm being strongly pulled towards code and building this prototype right now, I am resisting it. I've noticed in the past,

myself and others, that when I want to build a thing and I'm doing it, I get a bit of tunnel vision and I actively avoid researching other projects. I even feel a sense of dread when I hear about another similar product because I see all that hard work and beautiful code going to waste. So maybe there's a healthy way to code my project and also respect other ideas. But for now, I want to stay in this research mode so I can get inspired some more and get a really strong prototype idea before I commit to it and put on the tunnel vision glasses. So I have three other ideas that I've been very excited about in terms of prototypes. And I also feel myself being pulled towards building them immediately. But I'm resisting.

For now. The first one is this workflow-y Git idea that I've written about. I talked about it with my friend Jonathan. And I've gotten a lot of these ideas from other people. I guess the two places where I've gotten these ideas from the most are from the application Workflowy and the application Git and GitHub. And I'm thinking about merging them in an interesting way. So let's step back and think about the problem. One of the hardest things about programming is keeping track of what you're trying to accomplish.

This is harder in programming than in most disciplines because programming has problems that have problems that have sub-problems that have sub-problems. Fortunately, programming also has a slew of mental techniques mirrored in code for dealing with this challenge. The core technique is top-down programming, but whereby a programmer breaks down bigger tasks into smaller tasks in a nested to-do list.

This is why at our after-school program, The Coding Space, we encourage our students to always have a list of steps for each project they're working on. If they're working on one of our guided projects, which we call Untutorials, we create this list of steps for them. Whenever we go to Socratically help a student who gets stuck, we start by asking, what are you trying to accomplish? And if they don't know, we are easily able to get them to focus on the problem at hand by asking, what step are you on? When our students are working on projects of their own design, not one of our guided projects,

we encourage them to create a similar list of steps to keep themselves organized. However, students don't always take us up on this piece of advice, so it would be neat if there was a way for this workflow to be more deeply integrated into the screen, into the development environment, as opposed to on a separate piece of paper, which feels more disconnected. More importantly, when a student works a tough problem that requires a lot of debugging, a simple flat list of steps on a piece of paper begins to not be enough. What you then need is real top-down programming,

the ability to break down problems down and down and down into subproblems, so you can keep track when you're working six levels deep into a subproblem of a subproblem of a sub problem of a sub problem of a sub problem in a frustrating debugging session so you could see oh this is the ultimate problem i'm trying to solve right now and here is how i got here and oh maybe i need to take a step back so that that's the problem and that's a sense of the solution and so here are my thoughts about what a top down programming interface could look like potentially even on woofjs.com slash create, my own programming language and integrated development environment. So the reason I think it needs to exist on a website like Woof and not as a separate tool is because I think it really needs to deeply integrate into the code interface so

that each subproblem that you create a to-do for becomes its own branch of the code interface so that each sub problem that you create a to do for becomes its own branch of the code and so when you click on a different sub problem it checks out that branch from it from a git perspective it checks out that branch and when you create a new to do or sub to do it's just creating branches as fast as you're typing which is very different than the normal normally working with git so each sub problem would be like a branch or a github issue where you could have discussions you could reference other branches and different people you could comment directly on certain lines of code you could review code and then you could submit it to be merged into parent branches you know marking a task as being done so that's all very similar to

git but it's it's integrated with the code. So another thing I've been thinking about, which probably is too pie in the sky, but I think it would be neat, is if it would keep track of the different subtasks you're working on and how much time you were spending on each one so it could notify you when it thinks you're spending too much time on a subproblem. Maybe it'll send you a notification and say, hey, it looks like you've been stuck on this problem for 10 minutes. Maybe you want to try a different angle? Is there another way to solve this ultimate problem you're trying to solve with this sub-problem? I think this could really help developers with the XY problem. The XY problem is when you're trying to solve problem X,

and in order to solve problem X, you come up with solution Y, and in order to solve solution Y, you come up with a whole slew of other solutions, and you lose sight of the fact that you're actually trying to solve problem X, and problem Y isn't the best way to solve it. So the XY problem has you refocus on X, so you can realize that Z is actually a more efficient solution, and you just solve Z and forget about Y. So I think this kind of system could help you think about that more explicitly.

So another reason why I think this could be amazing is it combines version control and code development in a way that allows you to jump right into development. So right now, if someone's working on a complex pull request request it's hard for me to jump in and help you know i could see that they're working a pull request and i can commit to that i could branch their pull request and make certain commits but it's hard for me to jump in because like who knows what part of they're working on next etc but if they had a tree a really long tree you know that their pull request was just one branch but but then inside that branch were hundreds of other pull requests. I could just pop in and complete little helper functions, complete little API things. I think this could really enable collaboration in a way that

Git and GitHub only do one layer deep. This could be infinite layers deep. You can collaborate infinitely in a way that now you can't. You can only collaborate at the pull request level. This you can collaborate at any problem level. And I think another way this could be really helpful is it could allow mentors to really help their mentees get started because they could create this tree of what needs to get done, and the mentee could just go and run at that tree and work on all the problems and get it all together.

And I think that could be a really great platform for mentoring and learning in context. Because it would combine like a classroom-style learning method online, like Free Code Camp or Codecademy, where there's a target little goal, you have to complete this project, make a function that adds up all the numbers in a list great so you do in code academy whatever you move to the next problem it's not very motivating but if that was just a sub problem in a longer list of real problems and it kind of added up to this project being done but at each step it was just a well scoped out problem that you could definitely accomplish that's powerful for learning and mentoring and educating someone, welcoming them into a new code base.

So one open question with a system like this is how permission works. Who is allowed to edit what files and what branches? Is it all like a Google Doc? That seems a little messy. Can you clone someone's entire tree of to-dos and branches? Or are you just creating more branches on the same tree? I'm not exactly sure how that would work,

but I am proud of myself for writing down this problem, even though that is a big gaping hole in the solution. Sometimes I should also think about how Paul Graham's bottom-up programming ideas could relate here, because they are relevant. Another benefit of this system is that it would leave a wonderful breadcrumb trail about how the code was built. I'm stealing this from one of the links I was researching that I mentioned above. I think it could entirely replace comments, because for each little tiny piece of code,

you have not only the name of the task that was done when that code was written, so it's like a commit message but much more granular, but it's also tree structures. You could see the larger task that was being accomplished when that little piece of code was added. You know, infinitely. So I think it could be a really good breadcrumb trail that helps new developers understand how code works

and debugging in the future. So that's this idea, and as you can tell, I'm pretty jazzed about it. And it's also neat because I have this tool that it could integrate into, wolfjs.com. So I think that would be a really fun experiment prototype to do. And after I build it, I could, you know could roll into class and try it out with different students.

I could put it behind a feature flag or something like that. So I'm excited about that idea, but again, I don't want to jump to code too soon. I'm going to keep thinking about different ideas. So I have three other ideas. They're all pretty related. And they are building a more reactive game engine. So WoofJS is a JavaScript game engine, or animation and game engine, similar to ProcessingJS, but it has the abstractions and metaphors of Scratch,

and that's good for two reasons. One, it's good because Scratch's metaphors are better than Processing, they're just great metaphors. And then two, the students who are using this often have come from Scratch, so they already know those metaphors and abstractions, so it makes it even easier to learn the syntax of JavaScript. However, I've been wondering if we could make Woof even better. We can move away from the abstractions of Scratch,

and towards the more modern hotness of reactivity in game development. And I think this would be a fork of worth. It wouldn't be the same product. It would be kind of a separate product. It would probably be a different name. It would be a game engine with different abstractions. Maybe with the same underlying code because I'm the one making them both. But it would be an entirely different project.

And so I have in my journal, you can see, I came up with this with my friend Andrew, I should probably get on this podcast, where I showed him how easy it is in Woof and in Scratch to develop gravity. And so what you do is you create a sprite, and you create a speed variable. And then you create a forever. And in that forever, that loop that happens every render cycle, you decrease the speed by one. And you change the position of the sprite by the speed. And so just like that, the character will now fall with realistic gravity because you have an acceleration of minus one.

And you can mess with the acceleration. And I really love how simple it is. But could it be even simpler? So that forever loop is neat. But what if we defined it all declaratively? So what if we said acceleration is negative one. Speed is the previous value of speed plus acceleration. And the x value is the previous value of speed plus acceleration and the X value is the previous value of X plus the speed that seems pretty clear to me you have to worry about any forever so it's all very declarative and functional

reactive there are some real problems here I don't exactly understand how you'd reference the previous value of a thing and and what is the initial value there are definitely some open questions here, but I'm excited about it. And I think it could also be cool to think about how you could do this with a apparatus-like interface. I think that's how you pronounce it.

The website is aprt.us. So it's this really cool interface inspired by Brett Victor. And I think it's by a guy who works at Brett's research lab and it's very reactive. It's kind of like a spreadsheet-like interface where you define everything in terms of other formulas and you can define these really cool interactive widgets.

But what you can't do is have cycles. So I was trying to create objects that would move on their own like the x position is x position plus 1 but it says sorry circular dependency can't do that so what would it look like if you could do that in that tool what would it look like if you could have gravity in that tool I think that tool could be kind of like

in between unity and woof it could be a really powerful user interface or it could even be a better scratch it could really be a cool way to build games on the web in a reactive way in a way that is very extensible you don't get the spaghetti code like you do in scratch i'm excited about that idea both building a reactive woof js which is a text-based javascript library but a react but reactive and less less Scratch, less imperative

with the forevers, no forevers but also building it in this apparatus-like interface where it's more of a spreadsheet kind of thing less code, more values and I think another place another project that would help me think about this in the right way is trying to build a generic game engine for Elm. Elm was a front-end programming language that I've talked about before, and McMaster University teaches Elm to children, how to make games in

Elm to children, which I think is amazing because it's this exact same thing I'm talking about you know but where I don't like it is at the bottom of their projects they have this section that says don't touch this code this sets up your game just just just customize the way you know how high the gravity is to customize the way the player looks you know it's I find that very disempowering so I don't know if it's possible but I would be very excited to see if you could build a generic game engine in Elm where a kid could build any game they wanted to

and understand the whole thing top to bottom without any starter code, et cetera. So that's another thing that could help me think through all of this. So that's it. So that's where my head's been at the last two weeks. I've done a lot of reading and consuming, a little bit of prototyping and thinking about what's next for me in the next, these next two weeks. I'm going to continue with my researching and reading and

journaling and we'll see how it goes. In terms of what's next, let me think. I really want to take a look at EVE now that I'm realizing that my spreadsheet and streams idea is probably pretty similar. I want to take another look at IMP, which I heard about from the Future of Programming meeting. We have a meetup in New York. I heard about that from our first meeting.

One of the kids there had showed us Imp and how cool it was. So I'll check that out because I'm into spreadsheets too. I still haven't checked out Luna, but I have plenty of other stuff, so I don't need to worry about the fact that that's in private beta. And yeah, that's about where my head's at. I'm sure I'll add more links to this in the future. And I'll probably also want to make sure to continue listening to inspirational-like things

like Morbid Victor Morale and Kay because those people continue to bend my brains in the right ways. Thanks for listening. Again, please reach out if you have things you'd like to contribute to this conversation. You can find me at Steve Krause on Twitter.

My name is spelled S-T-E-V-E-K-R-O-U-S-E. And you can see all of my thoughts at futureofcoding.org. And you can also find a lot of this stuff on github and if you see any typos or things you want to add or correct please make an issue uh fork me and make a pull request i'd love to engage with you however you want to engage with me so thanks again for listening and i will talk to y'all in a week