Mary Rose Cook

I set up my GPT-3 account so I can text with it over SMS. It’s pretty fun.

To build this, I combined Airtable and Twilio. Here’s how it works:

1. I text my query to a Twilio phone number. E.g. “What is a good thing to reflect on as I fall asleep?”
2. Twilio receives the text and sends a webhook with the query to Airtable.
3. Airtable receives the webhook and this triggers an automation.
4. The automation stores the query.
5. The automation sends the query to the GPT-3 API.
6. The automation gets the response from the GPT-3 API.
7. The automation stores the response.
8. The automation texts the response back to me.

Airtable serves two purposes.

First, it sends the query to the GPT-3 API.

Second, it provides a way to store queries and responses, which allows it to build up context in an exchange. For example, imagine I send this initial message to GPT-3:

The following is a conversation with an AI movie buff.
The movie buff has excellent taste in movies and is
great at recommending obscure but high quality movies.

Human: Hello, can you recommend me a movie?
AI: Sure, how about Hoop Dreams?
Human: I loved that.  Can you recommend me a movie like it?
AI:

It replied with:

Sure, how about Beautiful Girls.

I replied:

...Human: I actually didn't like that movie at all.  Can you
recommend me another?

GPT-3:

AI: Sure, how about Boyhood?

Me:

...Human: I did like that one.  I really loved Drinking
Buddies which felt more truthy.  Can you recommend a movie
like that?

The ...s are what create the context. GPT-3 only operates based on your query. It has no memory of what you sent it previously. To retain context, each query you send must recapitulate earlier messages.

So, in step 5 above, Airtable gathers up all earlier consecutive queries that start with ..., plus one more (the query that started the exchange e.g. “The following [etc]”), plus the intervening replies from GPT-3. It sends this whole chunk to GPT-3 as a query.

This enables you to steer the algorithm towards more and more useful responses.

I was interviewed on the Future of Coding podcast. It was a really fun conversation. We talked about:

• My work at Airtable helping build tools for non-programmers to make software to do their work.
• Making software without writing code.
• GameMaker, an amazing environment for creating games with minimal code. It has been used to make killers like Nuclear Throne, Hyper Light Drifter and the first version of Spelunky.
• UI design lessons from games like Into the Breach and The Witness.
• Code Lauren and Isla, my past attempts at making accessible programming environments and how my goals of learning to write compilers conflicted with the tools’ goals of making it easier for beginner programmers to build software.

I wanted to get a better intuition for exponential growth. So I made this exponential explorer.

It lets me directly manipulate the starting amount, growth rate and number of periods of a graphed exponential.

I can create multiple graphs and overlay them or compare them side by side to see the relative effects of the different factors.

I can create a set of graphs and share a link to illustrate a property of exponentials. For example: in this exponential, nothing happens for half the periods, then it goes off like a rocketship.

Try it out.

Use Step to get a more precise understanding of how code executes.

You see a code listing. You click on the part of the code that you think will execute next. Then you click on the part of the code that you think will execute after that. And so on.

This is just a proof of concept. You can’t enter your own code, but I plan to change that.

Try it out

My new talk. No maths, no code, no slides.

Inspired by Dynamicland, I added a feature to Paper Programs to make each page publish a picture of itself. I used this feature to write a very crude animation program.

I want to help foster the community of people in London who are interested in the dynamic medium / tools for thought / interactive simulations for creation or understanding.

Here is a hopelessly narrow set of example projects:

• Inventing on Principle
• Hypercard
• Sketchpad
• Dynamicland
• Max/MSP
• Seymour
• Subtext
• Eve

A possible first step. I’ll arrange a meetup. At the meetup, I’ll give a brief talk that provides an overview of some of the interesting projects that I know of. Around the room, there will be posters that give more information about each project. These posters could attract groups of people who might discuss the project, or even get out a laptop and work together on trying it out.

This is just a set of initial bad ideas. If you have thoughts about how I could make them better, I’d love you to email me at mary@maryrosecook.com or send me a reply on Twitter. Thanks!

Makers Academy is a programming bootcamp. I’ve coached there for the last nine months. I love it.

In this essay, I’ll describe some of my favourite parts of coaching. For each part, I’ll explain how my work supports a learning goal at Makers. And I’ll explain how the environment at Makers supports this learning goal.

Note: we refer to our students as developers.

Giving as little help as possible

At Makers, developers lead their own learning. This lets them follow their curiosity. It lets them learn in their own style. It lets them learn at their own pace.

I support the developers with their self-led learning. Sometimes, a developer may ask me for help. Every problem is a chance for them to learn. I want to avoid robbing them of that chance. I want them to wring the maximum amount of learning from the problem. I try to identify the tiniest nudge that will get them going again. Sometimes, we’ll have a Socratic dialogue. Sometimes, I’ll suggest they diagram their current understanding of their problem to uncover wrong connections.

The environment supports self-led learning. Developers work on challenges that are designed to be rich playgrounds for exploring programming topics and practising programming skills. Developers work on team projects where they choose the what they make and how they organise their work.

Debugging learning processes

In some educational environments, the focus is on accumulating knowledge. The measure of success in these environments is: how much does the learner know about a topic? At Makers, we focus on improving processes. These are the approaches and techniques that a developer uses when learning or programming. Our measure of success is: how much have a learner’s processes improved? This means that a developer arrives at Makers as one person and leaves Makers as a different person.

I help developers improve their processes. For example, I run weekly surgeries. Developers discuss programming struggles they’ve had. A developer often describes their struggle as a problem with a programming concept. Through discussion, we try and uncover the skills and behaviours that are the actual cause of the struggle. A description of a struggle might be: “I find it hard to get RSpec syntax right”. Through discussion, it emerges that the developer is trying to memorise syntax, piece by piece. I might suggest they build their skill in mentally parsing syntax. Or, a description of a struggle might be: “I don’t understand database relations”. Through discussion, it emerges that the developer has spent a lot of time reading. We talk about how it is essential to learn by doing. We talk about how they could build a behaviour where they try stuff out in a REPL.

The environment helps developers improve their processes. Pair programming, group work and retrospectives help them reflect on how their processes could be improved. Skills workshops suggest new processes to try. And working on projects gives developers a chance to practice new processes.

Being a role model

At Makers, we help developers aspire to become better programmers.

I support this in a number of ways. Two examples. A developer asked me what programming language would help him explore functional programming further. I took great pleasure in suggesting Clojure. It’s wonderful to be able to share the things I’m excited about. If a developer asks me for help with a programming problem, I might show them a cool technique. Or, I might talk through the source of my intuition about where to look for the problem. It feels good to share techniques from one craft practitioner to another. Sometimes, a developer will ask how I started making games, or how I got a job at Ableton, or how I made a programming language. It feels great to be able to give them advice.

The environment supports the aspiration to become a better programmer. We recommend books and talks by expert programmers. When pair programming, developers frequently work with people who are better than them. This gives them someone to learn from and a standard to aspire to. By encouraging varied projects (from a virtual reality city-builder to an arithmetic interpreter written in Haskell), the environment becomes a community of developers who inspire each other.

Getting better at learning

At Makers, I spend my whole day steeped in our environment. I get to learn about educational psychology. I get to think about learning all the time. I get to reflect on my processes and improve them.

Every time I help someone learn, I improve my own ability to learn.

Summary

In this essay, I’ve talked about some of our goals at Makers. I’ve talked about how I support these goals. And I’ve talked about how the environment supports these goals.

And here’s my greatest joy. As a coach, I’m a part of the environment. But I also get to design the environment.

Want to help? We’re looking for a new coach.

I used to love Google Movies. It was a site that listed the films showing nearby. For some films, there was a handy link to the film’s IMDB page, or its trailer. Unfortunately, it was taken down a few months ago. So I built my own.

It lets me find out more about a film I haven’t heard of. It lets me quickly scan to find something to see in the next few days. And it lets me find out about that one random screening of Taxi Driver happening at 9.40pm on a Tuesday in three weeks’ time.

I spent a couple of days making a prototype of a GIF search engine. My goal was to make it as fast as possible.

Each time the user types a character, the app sends an Ajax request to the Giphy API. When the response comes back, the app extracts URLs for the GIFs listed in the search results. To preload these GIFs, the app sends Ajax requests for each one. When the first image response arrives, the app inserts the corresponding image into the top search result position on the page. When the second image response arrives, the app inserts the corresponding image into the second search result position on the page. And so on. The GIFs are less jarring to the eye because they load from the top of the page down.

Each time the user types a new character, the previous search request and previous image requests are aborted. This saves bandwidth. The app is fast because of this bandwidth saving, React’s fast rendering, and Giphy’s responsive servers.

Sadly, I can’t deploy the app publicly. It doesn’t have any features beyond the ones offered by Giphy, which means it violates their terms of service.

I used Create React App to build my project. This was a dream. No messing around with Webpack. Built-in deployment build script. ES2015 support.