Find the North Star

Amelia, welcome to Still Burning. It's great to have you here. First question — when did you first know that you were a geek?

Good question, Kent. So if we go all the way to the beginning, both my parents are software developers — and I decided that's exactly what I don't want to do. You see them go to work every day, they sit at a desk and they do that all day and then they come home. From the outside, it just looked very boring. So even through college I wanted to do something very different. After college, I moved to Texas to work in a research lab. My plan was to be a psychologist in a prison, because I thought that would be interesting.

The lab needed a website. So I actually built the first version of their website. The first version I built was in Dreamweaver and it was like a brain and you clicked on the different parts of the brain to get to the different pages. And that was rejected immediately. So I had to learn how to make an actual website. I went through Code Academy back in the early days and taught myself how to make a website. And that ended up being the most fun part of my job. I didn't even have interesting projects — I just rebuilt my website over and over again.

So something I want to pick up on is this idea of trying out, building the same thing over and over again. What were you looking for? Like, I've done exactly the same thing. And I think there's a lot of value to it, but it doesn't fit the mold of efficiency, productivity, or the Jira ticket already being signed off on.

Yeah, I feel like that's the beauty of a personal site — there's no goal, right? It's just, what is something that expresses you as a person? And I think I just rebuilt it because I would learn something new. And the only thing I could think of building was my own website, I guess. Eventually I interviewed at a startup and they offered me a job as their only front-end developer to work on a pretty complicated data analytics SaaS app. During the interview, they asked me "Which JavaScript frameworks do you know?" And I said, "What's a JavaScript framework?" And for some reason they hired me. There was a lot of learning on the job, but it was just this amazing mix of learning technically complicated things and also getting to be creative with it. I've been happy doing that ever since.

So what are you building now?

Things have been changing a little bit in the digital world. AI has gone through a transformative time and now we have these ridiculous models that are really good at fuzzy things. It seems like a new material that you get to play with in the digital world. What I've been thinking about for a long time now is how does that change what we can build and how might it change the way we interact with computers? More tangibly, recently I've been working on basically what comes after the IDE.

IDEs have been around for almost half a century and they're wonderful and every pixel has been crafted specifically for the job of reading code and understanding code and writing code. And it seems like our first steps were to figure out how to take these new fuzzy logic machines and put them in a sidebar. First we did autocomplete, which was actually quite nice — a little moving sidewalk. Then we gave them tools so they could read and write code. And then we've actually moved towards CLI — what if we had a bunch of agents in my command line and I'm running ten at once? People are really starting to feel the edges of the current tools.

For me, it's not about reading and writing code. So can you characterize what else we were doing that maybe we didn't realize?

This is actually a project I did at GitHub before AI was everything. It was shortly after COVID — GitHub is fully remote. We talked about GitHub as the place developers do social coding, it's collaborative, but really we don't talk to each other before the PR. The impetus for the project was how do we make a collaborative development environment? But it became very clear immediately that the bulk of the work is actually not in the code. It's in the linear issue, it's in the docs for the dependencies that you're using, it's in the conversations you're having with your coworkers.

Right — what information they have in their heads and how that's spread around. When there's contradictions between what you understand and what I understand.

Right, which is in a lot of ways like the bulk of what we do as software developers — getting the right context at the right time and applying it to the codebase. And so in order to create an environment where you can truly work collaboratively, we needed a membrane around any given piece of work that we were doing. It seems to me that right now we're working on speeding up, we're accelerating with the tools that we've had previously. And it feels like we need a new primitive or two or five. But one of the new primitives needs to put that membrane around the tasks so that we can work more quickly and collaborate with each other and with agents. So I've been working on a desktop app that tries to not replace the IDE — there's a very long tail of things that developers like to do in their IDEs and we're never going to build all of that — but at least adds that primitive where you can have three things going in the same project at once.

So you have this sense of play — of doing things for learning, not for production. Is that easier or hard in your current job to maintain that sense of play without everything having to have a specific purpose?

Play is always sometimes hard to justify. Where it doesn't seem like you're going directly from point A to B, where B is like your KPIs or what you need to build or complete. It feels like you're going in a different direction, or just looking at what directions are out there. But it's more necessary than ever. Because I think without play, we will only be able to iterate on our current interfaces incrementally. I think there's no way without stepping back and trying something where there aren't consequences for the things you try. Like when I think of play, I think of a sandbox — we initially learned physics in the sandbox because there's no repercussions. You get to try something and see what happens.

And I think we're going from an era where we were making fine little tweaks on known processes to build software — to having to make big tweaks. I mean, it's like simulated annealing. If the crystals are mostly aligned, then you can cool. But when things are at the beginning stages, you've got to turn the heat up. And this focus on productivity is in that refinement stage. What we're talking about is if you want to create the revolution, you've got to really be shaking stuff up.

Was there a moment you learned that stepping back? Ward Cunningham was my first mentor. We had some code, made some changes, kind of okay, but getting away from us. And he just reached over and turned the computer off. And I just about jumped out of my skin. The next day, we started over from where we were. And fifteen minutes later, we had everything we'd done in the previous day and the code was clean.

I think earlier you talked about bringing play into work, and I think maybe play is the motivation behind stepping back. When I'm stressed out about a deadline, it doesn't feel like there's time to step back. You're like, go, go, go, code, code, code. You can very easily get yourself into a hole where you've gone very far, but in what direction? I don't really know. As a junior developer, you definitely feel the urge of: I've been hired to do a thing, I have a list of these things, the faster I do them, the prouder these people will be of me.

But it also changes our relationship with code — if you can prompt something and it writes a thousand lines of code, maybe it also helps that feel less valuable. And to be able to throw it away, because you can easily regenerate it.

One thing that's been really interesting: a lot of the way that the app works is baked into what we call specialists — basically personas, prompts for specific types of agents. There's a coordinator agent, an implementer, a PR reviewer, a UI designer. And it's mostly a natural language prompt that anyone could write and anyone could tweak. So you spin up a task and the coordinator will research how to add this feature into this codebase, make a spec, once you approve it, delegate the tasks, have a verifier come in. And all of that behavior — users come in and they think it's baked in because that's the way software has worked historically. And it's all just a prompt.

Hasn't been possible since Smalltalk. Part of the Smalltalk ethos is that you were responsible for the tools that you were using. And if you didn't like how they worked, you'd hit Control-C, look at the stack and say "let me fix the text editor." I always was uncomfortable with this well, I'm a tool builder and you're just a tool user. I'd like those to be a lot closer.

I'm very excited to see how apps change — the paradigm of what an application is. I think we might go towards a remix culture where I share something but that's not set in stone. Like, I can download your app, Kent. And then I say "I don't like this part of it" — and instead of sending you an email saying can you please change it, I can just change it on my own computer and share my version.

One last question for you — what scares you about this process that we're all going through right now? What wakes you up at night?

I think there's the very obvious scary thing — with any change, especially one that happens quickly, and this is a very large, very fast-moving change, we might as a human race end up in a good place after it, but things get pretty rocky in the meantime. And so figuring out how to take care of people who are living through it right now feels very important.

I think if we take only incremental steps — here we are, let's add chat to an IDE, let's see the next obvious thing, let's add a GUI around the CLI tools — we're doing a random walk into the future. There's no directionality, no consideration of where we want to go. And the thing I'm most interested in injecting into the environment right now is: maybe we should do that step back and think about a North Star. What is worth moving towards? How do we want to work with computers? What do we want to build? Obviously you're not going to state it and have it become a thing. But if you have that, you at least know you're going North. Our next step should be daily in this direction.

Thank you so much. What a delightful conversation. I really appreciate it.

Thanks so much. This was fun.