#13 – Maggie Appleton: Barefoot Developers, AI, end-user programming - podcast episode cover

#13 – Maggie Appleton: Barefoot Developers, AI, end-user programming

Aug 13, 20241 hr 5 minEp. 13
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

The guest of this episode is Maggie Appleton, a designer, anthropologist and developer who has recently explored the world of local-first by giving the closing keynote at the last local-first conf. This conversation will dive into the topics of her talk including home cooked software, the idea behind barefoot developers and how AI complements local-first software development. 

Mentioned in podcast

Links:

Thank you to Expo and Rocicorp for supporting the podcast.

Transcript

Intro

there's a group, and this is what I call the Barefoot Developer Group, who really do want more agency over their computers. They're, like, currently using Airtable and Notion and like spreadsheets and like doing really crazy, complex things with them. But they also hit the limits of these apps. And they keep being like, well, how do I make it like do this thing? And I'm like, well, you can't, like this other company controls that software. You can't. add that feature onto it.

but these people, if given access to a language model, and kind of taught how to prompt it in a way where they can clearly ask for what they want, it can write the code for them. welcome to the Local First FM podcast. I'm your host, Johannes Schickling, and I'm a web developer, a startup founder, and love the craft of software engineering. For the past few years, I've been on a journey to build a modern, high quality music app using web technologies.

And in doing so, I've been falling down the rabbit hole of local first software. This podcast is your invitation to join me on that journey. In this episode, I'm speaking to Maggie Appleton, a designer, anthropologist, and developer who's recently explored the world of local first software by giving the closing keynote of the first local first conference.

In this conversation, we dive deep into the topics of her talk, including home cooked software, the ideas behind barefoot developers, and how AI complements local first software development. Before getting started, also a big thank you to Rosicorp and Expo for supporting this podcast. And now my interview with Maggie. Cool. Hey, welcome, Maggie. Thank you so much for making time today to come on the show. How are you doing? Hey, yeah, I'm really good. I'm excited to be here.

Thank you so much for having me on. So for the few in the audience who don't know yet who you are, would you mind briefly introducing yourself? Sure. Uh, I am a product designer slash developer of some sort. and I've been working in developer tooling.

for I think my entire career at this point, so pretty much 10 years, and I do a lot of work that's like doing designs for development tools, but most recently I was a designer at a company called Elicit where we were using language models to make software for scientists and researchers, so that dropped me into the world of language models and AI and machine learning, so I've been thinking a lot about that for the past two years. Amazing.

I want to give a little bit of background since we just had the local-first conference in Berlin a couple of weeks ago. And I've been getting in touch with you, must have been at the beginning of this year and through some common friends we've been introduced. And I was hoping to get you somehow interested in speaking at the conference. And when you and I were on a Zoom call and I've been suggesting this topic to you.

You seem super polite, but you weren't quite sure what you should say about local-first since you haven't really been building something with local-first. And now a few weeks later, you got back to me, said, okay, you're, you're down to do it. And you've delivered the closing keynote and I think it was hands down by most people, their favorite talk of the day and really blew me away.

so we want to go into the talk, momentarily, but maybe starting first, like what convinced you to do the talk and what has since seemingly local-first pilled you?

Local-first and home cooked software

Yeah, um, So yeah, when you first reached out, I mean, I had heard of what, I had heard of local-first, mostly from Ink And Switch's famous essay, like, I follow a lot of Ink And Switch's research, and I had read it, but at the time was like, okay, this has a lot to do with databases, and I, I like, I do front end web development, so I know nothing about back end.

I hadn't even thought to look into it, or it just never appealed to me, because Most of my motivation for development is often, like, I want to make a cool thing animate on, a screen, or, like, I want to see, something move. I like the reactivity, but, you know, I'm, like, JavaScript. so I'd never thought of backend as an interesting area or really understood, like, why I would want to be interested in it. so I'd read the essay, been like, cool, that's not my thing.

I'm not one of these backend people. Um, so when you reached out, I had to go Googling again and be like, what, what is local-first? Like, what is this concept? Like, why would I care? because I was compelled by a lot of the people who I saw, were going to go to this event, or were involved in the local-first community, were people who I knew were working on really interesting stuff and who had really interesting original thoughts about ways we should build software.

Not just from a technological perspective, but from like a cultural, social perspective. Which is really the thing I love, is thinking about, like, who's building these tools, who are they building them for, what are their implications in society, like, how does this affect equality and economics and, like, everything else that is not just, like, what code are we writing and, like, you know, how do we architect the app kind of stuff.

so once he reached out and I started googling and thinking about it, I saw this connection in things that I care about. with things that I saw that the local-first community cared about, which is things like data ownership, people being able to kind of own and control their own software.

and things working offline for me is, it's quite important in like a very sort of banal personal way in that, like I spend a lot of time on the tube, like doing stuff on my phone where there's no wifi, like a lot of time on the tube and a lot of time in airplanes where there's no wifi.

So just personally, I like need a lot of stuff to work offline first and, and I had also an understanding that in a lot of the world there's very limited internet connection or it's very slow, like the vast majority of people like might not have constant stable fast internet access all the time, and I hate the idea that we're always designing for a context where we do have that, and so we assume that everyone does, but this is like, like, Gets into the inequality stuff

and the like, you know, designing for everyone in the world, you need to have different systems than if you're designing on a 16 inch MacBook in San Francisco. Yeah, totally. I've lived briefly for a year or so in London as well. And I do remember that I think you had some connectivity, at stations, but maybe not in between.

And sometimes you're also like, as you're leaving this, the station, your device thinks, Oh, I have some connectivity and it tries to do stuff, but this is actually the worst. So I feel like a lot of software works more reliably on a plane where usually you're just entirely offline, but on a train, it's much more tricky because you have sort of this intermittent, and unreliable connectivity. And I think this is where software really struggles. So I know exactly what you're talking about there.

But as you were preparing for the talk, how did you find sort of like the, the topic that you wanted to talk about? It was definitely quite hard. I mean, I liked this because right when you kind of reached out and then I liked that you said, you know, you can talk about whatever you want. I mean, it needs to be about local-first, but like take whatever spin on it you want.

That's really nice because I like that kind of freedom in conference talks or doing any kind of research where I can go, Okay, I'm going to think about the things that I think are interesting trends that are unfolding or that are topics that I care a lot about. And I'll just find a way to like weave them in because most of the time everything is interconnected. Like this is all one, you know, one like software development philosophy that we're all trying to figure out.

and it was once I figured out how that local-first, I felt like had a strong connection to the world of, what, um, Robin Sloan came up with this phrase called home cooked apps or home cooked software that I had been collecting information on for like a year at that point, I have this note taking system.

I will just like collect examples of every single time I see someone building something that is just for them or just for their family or just for their local neighborhood, this very like local, you know, just for me and my people, not meant to scale, never going to be a VC startup, just like I'm solving my own problems kind of software. I'd written essays on this before. Like I wrote one called folk interfaces about people kind of like reusing existing interfaces to make these kinds of apps.

So I had a ton of content and a lot of thoughts on this topic. And it was when I looked at it and I was like, Oh, like local software. If you take that like at face value, that is like local to me, my family, my community, my neighborhood, my country, whatever it is like near and close to me. it might also mean the data lives on my device and the way that we use it in local-first software.

But I realized there was like, Oh, there's this interesting interplay where we can say local as in data or local as in culture and community. And once I figured out that connection, I went, Oh, this totally can work. Like I can build an argument around this, that actually connects these two together and can make. a bit of a, an ask to the local-first community to also care about this other version of local that I care about.

So you didn't just go for software for yourself and like your local context, but you found a way to pose the question in a much more globally impactful way by, I'm not sure, I think you introduced and like you came up with a new concept with a new term that you call like the Barefoot Developer.

And put that into perspective and into context with local-first software, home cooked software, would you, for, for those in the audience who haven't seen your talk yet, highly, highly recommend watching the talk also, like not just hearing the talk, but watching it. You've, as a designer, I think there's no one out there who's able to as a visually compelling and clear way, find visual narratives that makes this even clearer.

So I highly recommend watching the talk, but would you mind briefly giving the idea of the talk? Sure. Um, so yeah, I came up with this concept called Barefoot Developers. and this, name comes from the concept of barefoot doctors, which was this initiative in Maoist China in the 1950s and 60s.

It was not actually run by Mao, you know, he's a bad person, etc. But like, probably someone else in his cabinet who was very smart started this movement of barefoot doctors where they would take people from very rural villages. And this was at a time where there was very low health care access in rural China. There's just tons of people spread out. There's not a lot of expertise in these local places.

And they would pick, like, one person from each village, bring them into the cities, and train them up in, kind of, basic medical healthcare practices, like, immunization, right? Like, treating basic ailments, just, like, giving people nutrients, and this kind of thing. And then send them back to their villages, where they are, like, local, everyone trusts them, everyone knows them, and then they provide healthcare for the people around them. And this worked really well.

It, like, raised life expectancy a ton, and the whole philosophy of it was, like, we're taking, the power, not away from, but we're distributing the power from these, like, very urban centers where they have all the medical expertise out to everyone, out to all these very rural, poor villagers who now can have a better quality of life because we're giving them access to, to proper health care in a sustainable way, this is kind of a famous project.

And people ended up using this phrase of barefoot. Insert your profession here in a number of different ways. There's like barefoot designers, there's barefoot architects, and the whole philosophy is redistribute the power away from the urban elite and into like the rural masses. So, People advocate for this in all kinds of ways, but I kind of looked around and was like, no one's advocated for this in development so far.

And it's the same philosophy as end user programming, as the other word we would usually use for this philosophy, is like, normal people should be able to program and have agency over their computers to the same degree that programmers do. Now, In reality, we know that's really, that's a hard, like, difficult ask, right? As programmers, we deal with all this, like, complexity. There's a reason it's a profession. There's a reason it's a highly paid profession.

There's a reason that not many people, like, have enough skills and knowledge to do it at a really high level. It's just, it's incredibly hard, right? Computers are super complex. It's all these edge cases. We know it. Just like layers of complexity, just 60, 000 layers of complexity in every app. Like we are struggling to make the apps work well, let alone some end user doing it.

but the argument is, you know, maybe they don't have to be able to build Facebook by themselves, but surely they could build some software, some programs that serve their needs, that solve their problems in a way that no giant VC funded corporation in California ever would or would ever think to, because people who are far away in very rich urban areas don't understand the problems of people all around the world in all kinds of different communities.

And probably shouldn't try because it's usually quite, uh, I don't know, like colonialist in a certain way. Right. Trying to say like, Hey, you know, whatever it is, a street seller in Turkey or like a homemaker in Tokyo.

Some like bro, California, VC guy shouldn't be trying to solve their problems because he can't, he can't, there's not enough Zoom interviews that are going to give him the context to solve their problems well, and they should have the power and the tools and the agency to solve their own problems. , and you know, sure in the areas of design and architecture and healthcare, but also software, computers are part of everyone's lives and they should have more agency and control over them.

So, sorry, that was the long version, but like, that is, that is the concept of Barefoot Developers are, people who are part of local communities who have enough programming knowledge and skills to build software for their communities and solve problems for them. It's not everyone, right? Like, not everyone, like, nurses and teachers and whatever, don't need to learn to program.

But if you can have one person, like, who's in their neighborhood or in their school who can, then you get that person to build all the software for them.

Barefoot Developers

I love that idea and, uh, I agree that this is thoroughly needed. and I think most software that we use on a daily basis is , by a super wide margin built by folks in San Francisco or New York or like in some like Western hub. but this is where not everyone in the world is living. And so if you're just also look, looking at the density. and distribution of datacenters If you're looking into the global south, you don't have, nearly, nearly, uh, as many data centers, et cetera.

And you can only think about like how poorly the Western made software is running there. But we could. from a technological perspective, built as an entirely different way. So this maybe leads to a question I'm curious about. why hasn't the idea of a barefoot developer, why hasn't that been a thing before? Why hasn't that existed before? And why can't this change now? See, it's interesting. I think, it probably did exist before in the earlier days of computing.

When, in a way, like, before GUIs, and before, like, we got all the complexity, all the wonderful complexity of, like, the web, and, like, more sophisticated, more complex software engineering stacks, right, before we all had, like, Node and NPM, like, I don't know, just backends, and just, we were able to build much more impressive stuff in, like, the maturity and rise of personal computing and software, but it did mean that it became such a highly specialized, complex,

professionalized, thing, versus I think in like, let's try to figure out if these are the right years, but the 80s to 90s when it was still the command line, like a lot of people could build their own little things in like Linux, or just like little command line scripts, it was probably a lot more accessible that if you did on a computer, you probably knew how to program it versus now, that's not true at all.

so, and even I think in the early days of the web, like, you know when WordPress was still the hot thing? I mean, it is still the vast majority of the web is WordPress, right? Still, vast majority of websites. But I think early on, it was like, you could just kind of get in there and like, tinker on your own site in a way that now feels a lot more inaccessible, like now that we have, like, bigger build chains, right, and all these frameworks.

It feels a little bit illegitimate to just, like, spin up a WordPress site to try to build an app. You're probably going to reach for React if you know what you're doing. I mean, you should just reach for, like, HTML and CSS, sure, like, but most of us reach for React. in a way that if you're just, like, a, you know, someone in your neighborhood trying to build something, like, set up a community newsletter or, like, help build some script for your local library.

you probably don't know what tools to use or like how to use them well. You probably are like just using something like Airtable or Notion, which is great, but you don't really have the same agency and power as someone writing command line scripts.

So, I have some sense that we had more of this earlier on in computing, and as it's gotten more complex, it's like we, maybe we're on like a little bit of a curve where it needs to come back down the other side of complexity, or we need to build tools that simplify it for people to be able to build their own software, but we're in some, what I call like the high modernism industrial phase, where everything's done in these like big centralized hubs and it's not

distributed across everyone's tool set. Yeah. So just from the perspective of a software developer, I can think of so many use cases where I would love to build a little tool for myself, but with the stacks that we have available for the last 10 years or so, there's like, Just my mind is typically approaching it the same way as like how I would build a software product for a startup. And that is like way overkill.

There's like so many layers of complexity that by now we're just used to, like there's like the hammer that we're used to using, that it sort of like kills the entire idea. In the initial phase where I don't even get to build it because I already know like, Oh, I've, but I know all the implications. I need to build this. I need to deploy that. And like, if that thing changes, then, this will ruin all my weekends to come. So we, we have like done so much innovation.

That, was always adding more functionality, cooler stuff, but it always came at the price of complexity, just like layering on and like compounding. And I think where I see local-first enabling this age of the barefoot developer is by bringing down the, the complexity in a massive way that you can, with a much simpler technology stack build very interesting things that don't need to scale to Mark Zuckerberg Facebook scale.

but if it works for your family and you build it when you want it, and then you don't really, it doesn't break constantly because you depend on all so many other external things. I think not just for, use cases that I can't think about, but just for, for my own personal context in a, my family stuff that I might as a Barefoot developer build for my friends and extended family, but also what other people in extended parts of the world can build.

I think this is what's changing now that the complexity is coming massively. But there's another thing happening now that you've also, built in as sort of the second layer of your talk, which is AI is happening now. so it seems like that is also a fundamental aspect that's also ushering in a new era of end user programming. So maybe we briefly shift gears a little bit and, talk about that aspect.

AI

Yeah, so this was kind of, like, the big claim I tried to make in the talk, which I do believe, but it's definitely a claim that, like, needs a lot of evidence and a lot of, like, questioning. But at the moment, I think I'm still pretty firmly in this camp, where I genuinely believe language models make a significant difference to end user programming being more possible.

when language models first started getting popular, and, like, we realized they were really good at code assistance, like, They're questionably good at other things. I'm not going to say that they generate, like, useful articles for the web. I don't believe they do. But for code assistants, it's like, anyone who uses Copilot regularly, or Curso, or any of these other assistants, I think you would have to be crazy to claim that they are not, like, speeding you up, like, helping you debug things.

I know a lot of senior developers are like, well, I could just do that. myself. And it's like, well, yes, you are a senior developer. you understand the bugs in the way that I do not. like, I've started to joke, I'm kind of a mediocre developer without language models, but with them, I'm, like, almost a full developer. I'm, like, actually, I can pretty much do anything you assign me to.

Like, in the world of front end, like, a little bit of making, you know, back end calls, but, like, it just, it just knows, you know, I just ask what I want it to do. And it pretty much gives me working code. Sometimes I do have to go in and debug it or like, ask it to do revisions, but like, the amount it can do that I could not do on my own is really just astonishing. it's very much a sort of subjective, personal qualia.

Everyone that I talk to, like, feels this way, especially people who aren't great programmers, like more experienced programmers are more skeptical, like, oh, this is causing more bugs, but I don't know, if you're more on the junior end, you just feel like you've just been given a superpower and you can like, make way more than you could. so this big claim is that like, not, I'm not saying all normal people, right?

As I said in my talk, there are a bunch of normal people out in the world who just don't, they don't care about programming and we shouldn't force them to. Like, I think there was this moment where we were like, everyone needs to learn to code, right? Every nurse needs Every, like, accountant, every teacher, you all have to learn to code. And they were like, well, we don't want to learn to code, like, why are you making us do this?

So I feel like we should just leave people alone who don't want to code. Like, let them do their other very important jobs in the world that have nothing to do with computers. but there's a group, and this is what I call the Barefoot Developer Group, who really do want more agency over their computers. They're, like, currently using Airtable and Notion and like spreadsheets and like doing really crazy, complex things with them. But they also hit the limits of these apps.

Like, I feel like I have a lot of friends in this category who have a lot of software needs and the software doesn't meet their needs and they keep being like, well, how do I make it like do this thing? And I'm like, well, you can't, like this other company controls that software. You can't. add that feature onto it. but these people, if given access to a language model, and kind of taught how to prompt it in a way where they can clearly ask for what they want, it can write the code for them.

It can build the app for them. If we, like, get the infrastructure right, it could set up some kind of local-first database, ideally, but some kind of database, put it on a URL, let, let people log in, store data somewhere, let, you know, figure out a way where we can have language models set up, the schema for them. It's like, It doesn't have to be super complex stuff, it might just be something like, Hey, help me organize a trip for 12 people for a week.

Like, that involves a lot of logistics and ops and planning, or like, you know, help me plan meal prep and groceries. There's a thousand apps for this, but what if you could just prompt your own, tweak every single feature that you wanted, like make it work just the way that you want the thing to work. These are not complex situations, but tons of people have these basic needs and language models could easily get them to working local apps that they own and control. Right.

That makes a lot of sense. And I think this kind of puts it nicely into two compounding steps. Step number one is even for more experienced engineers like myself, Like even for me, it would be too much to build all of like these ideas that I have in my mind, because I know like, okay, this is easy enough to think about, but to build, you need to wrestle with all of those layers of complexity that will just like drown you at some point.

And this is where step one is local-first, simplifies everything to the core again, that it becomes feasible, but it's feasible, but you still need to have quite a bit of experience to build it. And now step number two is LLMs that just bring down the barrier to entry by so much, by having someone who knows what they want to build and having a little bit of an intuition, how computers work, et cetera, and how to put those things together, who are not afraid to get some autocomplete.

Sure, I have no idea what it is, but let me try and then, like, iterate from there. And this is the second part where LLMs bring down the barrier to entry and now, like, make this possible on a wider scale. Did I get this correctly? Yeah, yeah, exactly. I think I should add on too that, I just, I showed in my talk some demos from both Vercel's V0 and TLdraw drawing interface.

Because as much as I was saying, you know, of course you'll describe and text what you want, You can do that, but often it's sometimes hard, or there's an ambiguity. but with TLdraw, and with, uh, B0 from Vercel, you're drawing a visual interface. Like, in TLdraw, you can, like, draw boxes, right? And you can, like, point to a button and say, when I click this button, you know, increment this counter. And, like, when I click this button, start a timer for three minutes.

And you can just sketch out what you want with these instructions. And then they have this make real button, so you select what you're drawing. You click make real and it makes the app for you. And like, it doesn't work a hundred percent of the time, but like 90 percent and these models are only going to get better. So we would hope if you get closer to a hundred percent, it just builds exactly what you told it to build and it works. And it's like, it's on a URL. It's like, it's a real app.

You can click it, all the things work. it's hard to look at that and still be skeptical that we're not at some step change in end user programming. Definitely.

and I think this is like this going beyond the medium of auto completing code, but that you have like the modality of like a visual modality where you can draw a napkin sketch and from that napkin sketch, you have like some working React code that you now like I feel like the next step in the evolution of putting together all of those systems.

It would be something like TLdraw, make it real, but for your local-first data model that you basically describe like your, your use cases, or you could even use your, your visual sketches that you've made through TLdraw, feed it into an LLM and say like, Hey, can you suggest to me Data stuff that I'll probably need for this. And it might spit out some code or it might spit out like some, some other artifacts that you can now use to iterate from there.

So I think that multimodality just brings down the barrier to entry even more, as well as making experienced people more productive. So now it really clicks how the, that answers the question of like, why now? Since I think the idea was compelling before as well. But with all of that complexity and, with all of the learning curve that needs to be done before, that wasn't feasible. So, uh, I love that.

Like I had also cited in my essay, uh, an essay written by, well, I guess more of a short post written by Clay Shirky in I don't want to mess up the year. Was it 20 2004 or 2014? I want to bet 2014. called Situated Software, which was about which was the same claim as Barefoot Developers. Like, software should be situated in the local environment that where, like, it's the people that it serves, it should have been made there.

He made this idea at a time where it was, like, completely infeasible. Just, like, No one could build sophisticated software, which didn't have the tooling, like we hadn't gotten this far. And, like, what would be the interface for normal people to build this program? It was one of those, like, wouldn't this be nice kind of concepts. And now it does feel like, yeah, we've reached this point where it's like, wow.

The coming together of like better tooling, like reducing complexity, like better abstractions, plus language models trained on all those abstractions and all that tooling. It is like, Oh, this is possible. Yeah, that, that makes so much sense. I can't wait to see like how quickly that's going to unfold.

This was also a big part of what we try to do with the conference is, not just get the, people who are already excited about local-first from, and who are trying to figure out how to build it in the best way, but also people who've maybe heard about local-first before, or haven't heard about it before, and that they get to understand what could be the possible impact of that.

And I think this is where you've just knocked it out of the park with, at the end of the day, with your talk, where I think before. Your talk, everyone was already excited about like, Oh, this is going to make software development so much easier, brings down the level of entry for people to build local-first. And it also enables next generation user experience, like Linear, et cetera.

And that's also why I initially got excited about local-first to build sort of like a really cutting edge, next generational products with Overtone. But I think you really expanded the horizon even further, what on a kind of societal level, local-first could have an impact for. So, do you have some theory of like, what are some, like milestones that you would like to see happen there as sort of success stories?

Yeah, um, I talked about a bit at the end of my talk that we're missing a few bits of like tooling or infrastructure, I think, to make this work, because at the moment, what you can do easily with language models is prompt front end code, right? It's mostly what people are doing, like even a 4. 3. 5 Sonic came out, I think, a week ago, and it's really, really good at code generation.

People are making crazy stuff, and I have this whole fat collection on Twitter every time someone makes something. I'm just, like, saving all this stuff as evidence of, like, here's where we're at. Here's the current state of things. But it's just making front end code, right? It's giving you React components, interactive, it looks cool, it looks capable. But it's not connected to a back end. Connecting it to a back end would be like a whole different thing.

Um, user authentication and logging in would be a whole different thing. Like security, like multiplayer collaboration. Like, there's just, there's all this other stuff to have a real working product. Like, deployed to a real domain. Imagine if you're not a software developer, like, you would never figure out how to glue that stuff together. No matter how much you have, like, chat GPT helping you and, like, you asking it questions and trying to put together a working piece of software.

You wouldn't even know those things exist, right? Like, no one knows what a database is if you don't work in software. so we're missing, all these other pieces of tooling. I think what I'm waiting to see is, like, I don't know, you know, I've kind of tried to put this idea out into the world, tried to make more people aware of like, hey, we should be trying to build things to serve these developers.

and I know of two projects, Jazz and DXOS, who are both at local-first, Jess and, um, Anselm are hopefully building this kind of thing, which is like some sort of full stack local-first, like, framework for people to build within. I think if you could train a model on those kinds of things, where it's like, You're talking to a language model, but its whole goal is to get you to build a full stack local-first app. That would be the goal for me.

That's like, oh, I want to come in, I want to be able to sketch, I want to be able to prompt things in it. and I want it to sort of be architected and trained in a way where it's acting like a product manager, like helping me move towards my final goal. Like, you know, it's It gets me to tell it the requirements and it gets me to tell it what I want. And then it's doing, it's making technical decisions for me, right? It's like, hey, I'm just going to figure out how to model this data.

I'm going to figure out how to make this front end code. All you have to worry about is looking at the end result and telling me, yes, no, you know, what should I edit? What needs to change? And just looping. Like that, that's, that's what I'm waiting for someone to build, honestly. I agree.

I think there's sort of the, this gap in going from A to B where like, A, where we're right now, where I think we have the conceptual right ideas, how things can be simpler, and a few pioneers such as the folk from linear. And a few other products who have already had those right ideas, but they're technically very savvy so that they could like build that new hammer, that new framework themselves so they can live in the future.

And, then you have the, the other group, what you've described with like DxOS, Jazz, and there's many other technologies who are not primarily building it for their own apps. But to kind of build this for developers, so that the next Linear has a much easier time, can focus on the product and doesn't need to build off like the underlying tech. So that's coming along, and once that is there, then we're kind of halfway there, since at that point, now the AI also needs to pick this up.

Since, I think this is why the AIs are so great at bringing down the barrier to entry for things like React development, et cetera. There's already a lot of training data out there, whereas for local-first, this is all like very little training data, all like very, very new.

So I think once we have those ingredients and the AIs can also integrate that into their more encompassing, solution corpus, then I think we've, I guess like to, to a much more comprehensive degree enable a Barefoot developer, since I guess right now a Barefoot developer already lives in the future by, things like front end React programming, et cetera. That already works super well for them. And then they get sort of this glimmer of hope, Oh, a local-first is going to make everything simpler.

But the, the fact of reality today is you either need to use a very Early technologies such as jazz, et cetera, and where you still need to be a bit more on the more expert y end, or you need to wait a little bit until all of that is AI ready. But I, I like the way how you think about that sort of like as a big next step function change. Yeah, I expect they might meet in the middle.

Like what I think will happen is, like, people will build these kind of like full stack language model helpers, which are not local-first, of course, right? They will just build one that like uses cloud databases entirely. And it's like, all like not, doesn't work offline. and then the local-first tools will get more mature and maybe in a few years, like these come together in the middle so that you have.

You know, something for barefoot developers that just has natural language inputs and visual inputs for them to define what they want. and the stack is, like, mature enough, right? We have, like, stable enough technologies that they get all the stuff around local-first, like, CRDTs, all the fancy stuff for free, just because we, like, have enough training data and we figured out the complexities of it. I don't want to put too many timelines on it, but I'm like, five years? Maybe less.

I don't know. Some people think that we're all going to die from AGI in five years. So maybe just speed up timelines, like, but I think reasonably five years. , I think a very frequent philosophical question that one can entertain is like, my life as a programmer has certainly become a lot better over the past couple of months and years with things like Copilot and Cursor and, ChatGPT, et cetera. I can like take a screenshot of an error message and it gives me some useful clues. so that is.

Definitely getting better, but is this just like a very nice time before, I don't have to do my, anyway, this is not a question to debate here, but it's certainly also, I'm not immune to, to those sort of thoughts as well, but I'm, I'm choosing to see the world as like glass half full. and, I'm a tool builder, so I'm excited for new tools that make me more productive and, make me more capable in doing stuff.

Yeah. I mean, I was gonna say, if we, if we automate all the code, we'll all just become designers and product managers, you know? Like, we'll just, we'll just help. Help the AIs, like, write the code and we'll just be like, Hey, you know, focus on this. This is your priority. You know, this usability piece isn't working very well. I still think it would scratch the same itch that a lot of developers have around like building beautiful systems and like solving like logical puzzles.

Cause it's still design. You're solving a lot of logical puzzles. I don't know. So maybe that's why I'm not as afraid of like the whole. Automation fears, but I also think they're ridiculous. Like we'll never get to a hundred percent code automation and it seems crazy.

Elicit

Yeah, definitely. So I want to shift gears slightly, and not just look at AI as an enabling technology to make us more productive. But if we put ourselves into the shoes of a product builder, possibly of a tool builder, how. Can AI be a ingredient that we can put into possibly local-first powered apps? and so given that you've worked at Elicit, which is maybe you can briefly give a summary what Elicit is about and what you've done there, but after that, maybe we could explore a little bit of.

maybe you have thoughts on how to best bring AI into products and how is that a challenge or an even better benefit to do it in a local-first context? yeah, I actually, this is funny, like, after I had written the talk and was talking to more people, I had that realization of, like, oh, language models and local-first go really well together.

I think this is actually Jeffrey Litt, who's at Ink and Switch, that kind of got me onto realizing this, how they're, like, actually perfect for each other. but I'll back up a bit and talk about Elicit.

So, yeah, I was the designer there for two years, It is a tool that helps scientists and researchers do this thing called systematic literature review, which is this frankly very long manual boring process that no human wants to be doing, but they're sort of like forced to do because they have to. where let's say they want to do a study on like, vitamin D deficiency or something like this. They have to read every single paper that's ever been done on like vitamin D deficiency studies.

And like, what do we know? What's already been tested? What needs to be tested in the future? Just like read tens of thousands of papers and extract all this data from it. Like how many people did they study in each paper? And like, what were the results? , what was the effect size in the population? Like just all this stuff. And usually humans, Open up PDFs one by one and type this data into a spreadsheet.

They're just like sitting there for, it takes six months usually, it takes a couple people six months to do one of these. And you have to do it for every like new drug release to market or any new medical device. So there's this whole consultancy whose whole job is to do manual data entry. and it turns out language models are quite good at extracting structured data from these PDFs.

Or if you prompt them in the right way and you have Frankly, at times, quite sophisticated architectures to make them accurate, but you can build them, which is what we focused on at Elicit, is like, raising accuracy rates and making sure models got the right data out of papers. But you can get them to do it to over 95 percent accuracy, which is what humans roughly get out of doing this process.

So you just speed up this thing, used to take six months, you can do it in a couple days, maybe a week, of you just going through and reviewing all the answers that the models extracted. So, yeah, working there for two years, I learned a lot about, both just like prompt techniques and architectures for making models accurate. It's actually quite hard, but, but good to know it can be done. That was like really useful to learn.

it definitely made me very skeptical of most use cases of language models, I think, in that we found one that was really appropriate. It's like, okay, you There's data and a bunch of text. Get the data out of the text. That's like quite straightforward. But there's a lot of stuff people are trying to use them for where I'm like, is a language model the right hammer for this nail? Like, I don't know. You're trying to write marketing copy for your company.

I don't know that you want the most generic, predictable text to really be the thing that you're like putting out into the world. Or like, okay, some people are like, yeah, I want to write 10, 000 SEO keyword stuffed articles to like get to the top of Google, but and everyone does that and then there's no point in like you, you doing that because you're not actually going to get any traffic from it.

So, I'm strangely quite skeptical or like negative on a lot of uses of language models, but the data extraction, like summarization, like getting it to do very small structured things over text, I actually think they're really good at that. And code generation and debugging is actually one of those, right? Like, that's one of the things where like, okay, we've proven they're actually useful for this, so like, we should use them for this.

This is like, they are shining here and like, ignore the areas where they're not shining, like all the other, like, everything turns into a chatbot kind of stuff, which we don't really need. yeah, so that's, that's the long version of like, that was, that was what I realized at Elicit. but the thing with local-first and language models that makes them go really well together.

Language models perform better when you have lots of really specific data for them to run things over, right, to summarize or to extract data from. And if all the data is local on your machine already, and you're not having to, like, go up to the cloud, or it's not trapped in someone else's app to run a model over it, You can just run a model locally. You don't need to be making a call to OpenAI or to Anthropic, which gets really expensive.

You could just be doing this all on your machine with no delay, which is like, why are local-first makes perfect sense if you want to actually be doing language model work. Yeah. So thank you so much for, for the background, on, Elicit. I was not as aware of like the entire, process that researchers need to go through and just hearing the word manual data entry. it gives me shivers. So that sounds like a well needed thing and whatever , makes research and truth easier. that is very welcome.

also your insights in regards to where LMs are a good fit versus not to. I've coming to on a much smaller scale, but I'm coming to similar conclusions, for example, when I'm writing documentations for, for some technologies that I'm working on. And this is where I typically disable LLMs because like what they typically suggest to me is exactly not what I'm doing. I'm building a different thing that challenges the status quo for very particular reasons.

So I found it actually, it increases my cognitive overhead of like trying to. like come up with a thought and like a very fuzzy process. And then like, it's basically constantly like slapping me in the face. Like, do you want to say this? No, exactly not. So, there's like use cases for it, where it's good and where it's not good.

but, I think also that giving it more contextual information is exactly the, the key to make it feasible and maybe make it even so that I do want to have it enabled for docs. So if I imagine that I give it access to all of my source code. then it could actually draw, draw the right conclusions. So , this use case where you have your source code and you want to generate documentation, I think is a much simpler one from a technical perspective because everything is static.

I, don't need , my source code, sure, maybe some of it, I don't want to have leaked, but a lot of it's going to be public. So privacy concerns are not as much of a concern. But where that is the context, if we're now talking about the health app, this is where my context is possibly very, very sensitive data or financial data, et cetera. So this is where the contextual data is even more important to drive good results for the AI, but it's so much more sensitive.

And I think this is going to be a huge challenge and a huge question, how different AI systems will be built. And that's a key. topic that I'm interested in, this is where I think where we've seen with Apple's recent AI announcements, where they hijack the term AI to mean Apple intelligence. Well done. And now what Apple has announced at the latest WWDC is where they basically shared their AI strategy. and what I like about it is that most of the AI stuff is also happening locally on device.

And I think the, the way how to do that is, an approach that hopefully more technologies follow. And I think this will be sort of like a bit of a dividing line, whether you're gonna do it locally or whether you're going to do it in a cloud. And I hope that more products, more technologies will enable all of that to happen locally.

Since if I can keep my most sensitive data locally on the device, and if I can run the AI model locally, it's not just gonna give me the fastest results, but it's also, in my perspective, kind of like the only sane way how to respect the user's privacy. It was more of a coin flip to go with Google versus Apple before in terms of products, et cetera.

But if Google's only way in the future is to drive everything into the cloud and do AI there, and Apple's is to do it locally, that's a very clear call for me. But I think that's a major question overall. Like how do we run AIs locally and how do we drive the right contextual data there?

Apple Intelligence

Yeah, this is something that I haven't seen yet come up as like a SaaS or a service of any kind, or I guess it'd be more of developer tooling. Like, there's plenty of, wherever it is, like, toolchains on top of the, all the foundation model APIs, and like, you know, analytics and, visibility and, like, tracking and all this stuff, like, coming up around, around doing language models and product.

But I'm waiting for someone to just be like, hey, We help you run LLAMA locally on the user's device and then only when needed, like, when, like, as Apple said in their presentation, only when you need something that's more compute intensive do they send it up to a cloud server.

Something that allows you to do hybrid, local, and uh, remote, so that at least ideally the user, I mean, this is probably more likely to happen in a B2B case, could say only do these kind of like, functions on this kind of data, uh, locally, maybe this is more sensitive data, maybe this is more sensitive stuff, but stuff that's maybe more complex or stuff over here, you can send to OpenAI if needed, or to a cloud, I mean, to Anthropic if needed. So I haven't seen that happen yet.

I don't know what that is. That's like hybrid language model prompting, but that seems like a very obvious piece of infrastructure we could build in. I'm wondering, like, what will be the thing that wins the argument one way or another?

one possible path could be, Oh, it gives you the best performance or that it needs to work offline in certain scenarios, whereas like, I think with local-first, we already see that the, the works offline case is kind of like a, Argument that is not as compelling for many or not as intuitive for many as you might think. but I think what I would hope will be the winning argument is privacy.

But I'm saying that as a European, and I know that other people might, uh, not value privacy as much, but do you have thoughts on what will be like a big lever in terms of one way or another? Yeah, I mean, I also agree on the privacy bit, but I also know a lot of people who just, I don't know, doesn't, don't, they don't care, or it's just like, oh, this is just whatever. This is like my, you know, notes on my product development app. Why do I care, about privacy? But I think it's speed.

Like, one of the biggest UX challenges of the list that we faced is just that loading times are Or just on a whole different level. It's just, it's, we're so used to quick, quick loads, right? At the most one, two seconds. And even then users are getting, you know, antsy and like, oh, this feels slow. This app isn't working. Sometimes you have a load time with a language model. If it's doing a complex call of like three minutes, like, What do you do with a user for 3 minutes?

Like, there's only so many animations you can play on the screen. Like, there's only so many minigames you can have them play while this thing loads in. so having models locally on your machine that could run language model functions faster would be a huge UX benefit. A lot of the time we're just waiting for the OpenAI API to reply, or like, Maybe we're doing multiple, you know, a hundred calls.

So every single time there's a couple seconds of delay on each one, this is just adding up into a huge, huge time sink. so that would be a big benefit, but I of course agree on the privacy front, especially for companies will care about this, right, for proprietary data, but yeah, individual uses for finance to health and anything where you just don't want it going off your machine. Yeah, so this is a topic I'm highly interested in, want to explore also in future episodes.

I think luckily there's so much momentum and so much good stuff happening on the AI capability side where models are getting more powerful, but also more efficient that makes it possible to run them locally. I think Google announced or released, uh, Recently, like a Google, uh, Google Chrome version, I think a Canary version where you have, I think, Gemini Nano working actually already locally where it can say window. ai and run some little prompts.

So this shows some first, building blocks in that direction. But, I'm more interested in exploring and figuring out a path. How can we.

Figure out the contextual data side, since I think this is where I'm less concerned about a AI model that runs locally, temporarily having, some contextual information about me that it has like flushed again, like in a few seconds, what I'm more interested in is exploring all of that contextual data that is highly personalized, that might be text messages I'm sending to my close friends or to my family, that might be health information, that might be my

emails, that might be my personal notes I'm taking after a nightmare, or whatever. Like, all of that stuff needs to be accessible to the AI in a local way. And that is much easier to do if, some entity, for example, Apple controls the overall ecosystem and can do it in a way that is secure, privacy respecting and fast. But where we are all building things for, for the web, this is where our playing field is much more constrained to the browser.

So one possible path That I could imagine where this is going is that the browser takes even more responsibilities of an operating system and where a lot of my contextual data lives in the browser, which raises the stakes and the risks even further. That now like some cross site scripting could access even more personal data. Since right now, with the stuff that we have really saved in the browser is like close to nothing.

This is actually one of the problems we tried to solve with local-first that Right now we treat the web browser like it's not capable to do anything, but we need to flip that. We need to store a lot in it to make that happen, which brings up a lot of privacy questions. So lots of interesting questions to explore there. Well, okay, wait, I have a good, a good dumb question for you as like a non backend person, like a non, like, databasey person.

Could you just make either an Electron app or web app that just accesses, like, a bunch of local files? Like, let's say, like, you've got 10, 000 local markdown files that, like, your personal notes, and a lot of them very sensitive. Maybe you're, like, journaling or nightmares or whatever's in there. Is there a way for some web app to just access those without it being uh, at risk of like cross site scripting or some other attack like this.

So, I mean, there's always risk and there's always like the figuring out the right balance between making something possible, making something convenient and keeping it secure and privacy respecting. So I think one capability that browsers already offer that could enable that would be Chrome extensions. But this is also, I think in a parallel universe, Chrome extensions would be even more common.

and we'd use them maybe even more, maybe in a parallel universe, Electron wouldn't have taken off as much as it did and Chrome extensions instead would have been that medium. So, Chrome extensions could, or browser extensions, generally, could be a bridge towards local data, and I think that will be a, a mechanism that might be used for that. I'm actually building a Chrome extension over the last couple of weeks for LiveStore, the staff tool that I'm building. And it's, really complex to build.

And one of the big reasons why it's complex to build is because the browsers are already very intentional about trying to minimize the, the sort of like security risks. And I think this will be even more important. And I think we need to, strike like an interest, find a nice balance where it's secure, but still gives you the capabilities and in a way that a end user is able to make the right decision for them. And so I think, yeah, that's going to be interesting balance to strike.

Okay. Okay. Okay. That gives me more hope. Cause yeah, I'm in the phase of experimenting with, um, you know, Obsidian, local-first, like note taking tools. Yeah. Right. So like all my All my notes are in there. I was in something else before that was all cloud based and actually going to local-first. I was already on the edge of being like, Oh, personal notes should really be, Oh, you should own that on your own machine. That should be marked down.

That shouldn't be stored in someone else's cloud server. so went through the process of moving them all into this like local-first Obsidian app. and then now exploring building plugins to like build on top of that, like integrate language models, like do more interesting things with this like huge database of notes I have.

but it made me realize all I needed was some sort of like, Interface or runtime or primitives in place, which is what the browser gives you, or what something like Obsidian gives you. And then people being able to build things on top of that. That's when you get into the more interesting stuff. But making sure that base layer of like somewhere to store data, some security and making sure it's local-first. Like once that's in place, people can build much more capable things.

Local-first in the tools for thought space

So maybe this is a good time to shift gears again a little bit. you've been mentioning Obsidian and in the past, and I think still today, you're a very active person in the tools for thought space and Obsidian, obviously being one of the prominent tools in that space. Do you have thoughts on how local-first could be an interesting lever to make those experiences even better, both in terms of like end user apps that you're using, but also in terms of you as a builder?

Yeah, yeah, I mean, I kind of had this like, I've been so dumb moment, I guess, with the, with the tools for thought note taking thing, or realization, I should say, like around, around the time of the local-first conference, where for years I had been using, I was like early to roam research, and I moved to this app called Tana, which is like, Gorgeously designed, like, totally acts like a really flexible database, and they have a really beautiful outliner, things

where everything has types and schemas, and it's just the sort of thing I love. Like, types and schemas everywhere, super structured data. and their product is great, but it's not local-first. I don't think it's ever going to be. It's nowhere near their roadmap. And I just had this moment of realizing, like, After, after going to the conference and like hearing all the arguments against it, I mean, for it and against it.

And I was like, Oh, I, even if there's a UX cost to switch into something that's local-first, I like absolutely have to. This is like crazy that I've been using something that doesn't work on airplanes. That is my note taking database. It's just like nuts. Doesn't work on that too, but it's wild. Well, you just don't think about, you just don't think during airplanes.

No, no, I know, I know, because you kind of go, oh that's just, you know, all software doesn't work offline, of course, this is just the way of the world, like I just have to accept this reality, it was like my mindset before, and then had this switch of like, oh no, like that's totally unacceptable, I absolutely cannot use, like, Software that doesn't work online anymore. That's just like nuts. even Figma is sometimes on the edge of it. It doesn't always work like perfectly offline.

If you're trying to finish like a huge design presentation on the flight on the way over to your job, it's like, this needs to, this needs to work, you guys. You can't have this not work when I go offline. so anyway, I made the big switch to Obsidian. It was like a fair amount of work. Something only someone who like really cares a lot about. notes and structured notes and like knowledge bases, I guess would enjoy doing it, but it was worth it for me.

and it opened up my mind to what was possible now that I had my whole giant notes database local. And now I could, and as I said, they have this plugin ecosystem where anyone can build plugins. It's all in JavaScript on top of it. And I was like, oh, wow, I can extend this now. This is my environment. Like, This is not just my data. I now have control over the functionality of this thing. This is totally malleable software. This is end user programming.

Like, I'm going to build my own spaced repetition language model like crazy, Zettelkasten reviewer system on top of this thing. Um, but no one else, I don't, well, other people might want it. We'll see if I get them to work properly. But, um, It just, it just was like, oh, so much more is possible in this really exciting, empowering way where I went, oh, I own this. Like I fully have control of this in a way that I didn't with the previous tools. I was always checking the change log.

What have they just released? Like, are they going to prioritize my feature? Are they going to make the changes I want? I would often write crazy CSS stuff to hack the interface to make it the way I wanted, right? Just removing elements, moving elements, changing the, the size and structure of things for my preferences. And again, not, most people do not do this, but I am someone that wants it to work and feel the way I want it to work and feel.

so it was very liberating, and that made me realize like, oh, local-first software is actually much more about the user having more agency and control over the software. They can like write their own hacks around it in a way that's just not possible with cloud based apps.

Yeah. And I think this is another way to think about the, the affordances that enable the Barefoot developer movement, is that also for the experienced folks who build, much more sophisticated products, they have now much more capacity that they don't need to put into running massive Kubernetes backend systems.

if they want to go a little bit more ambitious about the products they're building, they could now put those resources, that capacity into facilitating more end user programming inside of that software.

I think unfortunately, it's like more the exception, than the norm that software facilitates that, because it is quite difficult to find the, what is the, the right interface, the right modalities, If there's a plugin system or those sorts of things, you need to be very intentionable of like, how far do we go? How flexible do we want to make this?

It was like, if you want to go even more flexibility, you might as well just like throw up your hands and say, okay, you built this as a web app and we only give you an SDK. and so I think there's an interesting spectrum there. And, I think. Building things local-first can free up capacity that can be reinvested into making more software end user programmable.

So I love those, um, those use cases and like your recent success stories that you found with, sort of the local-first mindset, bringing that into the tools for thought space. Is there, any other thing in regards to local-first where you wish or you hope that local-first enables a certain thing. what is like on your local-first wishlist?

Maggie's local-first wishlist

Ooh, I mean, I definitely want the quick spin up an app. I mean, I know this is like, we mentioned like things like Jazz and DxOS are trying to do this, just develop a tooling that makes building a local-first app easy. Does not exist. I tried. I tried to build a local-first app a couple of times. And it was just that the, the developer experience is not quite there yet. So I think there's a lot to do around DX and UX of just people being able to build these kind of apps.

in terms of things they enable, I don't know if they have that many more.

I mean, I certainly have specific examples where I'm like, there's lots of personal things that I would want to build my own little apps for and I just want easy ways to do that and that's like I mentioned things like, I always want to do trips with people like, you know, like groups of like a dozen or even more but it's so hard to just do all these small things in the middle that like software so far doesn't enable in these weird ways like Find out when everyone's free during the same week

in an entire year and then figure out all the flights and all the like finances and the cooking and find like an airbnb somewhere that would fit everyone You It's just like a big ops and logistics problem. And there's tons of these examples in everyone's personal lives.

it's the kind of thing that like, if it was local-first, who knows if you're going to have like phone signal out in the middle of wherever you're going, and you're still going to want to have access to all your like timetables and finance sheets and who's cooking dinner that night. that's just the kind of smaller examples that I think I'd, I'd like pull on is there's always those for personal stuff.

So let me say what, once we are reaching that point where it is super easy for front end developers to build local-first, home cooked software, I think your close friends can be very happy to and very much looking forward to be traded to some locally cooked software from you. Yeah, I will host a local-first software retreat if we ever manage to get those apps working.

If you could just make that easier, I'd just be like, great, we're just getting whole groups of people together to do these weird camping weeks where we all just build home cooking software together. I think that's a, that's a nice goal to aspire to. And luckily there's many, many smart folks like some of the ones that you've mentioned who are working towards that.

It's just, yeah, to, to absorb as much complexity as possible and to build it in a way that developer experience is nice and where it's not a leaky abstraction. That is quite the undertaking and takes a little bit of time, but I think it's on, on its way. Maybe as a last question.

Given that you've come to Berlin to the local-first conference and there were so many interesting people there, I'm wondering whether besides kind of opening the eyes for you, in regards to local-first software and not local-first software and ruining some non local-first software for you, where there's some other takeaways, some other insights from conversations with people?

Maggie's takeaways from Local- First Conference

I was impressed at how much work had been done. I mean, we had a few people speak who had been part of like the offline first movement before local-first got coined as a term, who said like, this has been around since, I want to forget the earliest year, what, 2008, 2009 or something, people started trying to do this. I was impressed by how much like previous art there was, but also how it hadn't progressed that much.

Like maybe other things became popular in the tech space at the time, or it didn't have this same like cultural energy behind it that it kind of does now. But it was both like, wow, this has been going on for ages, and we haven't actually gotten to a place where it's, like, standardized or easy to do yet, But then all the people who presented at the conference, it made me get this sense of like, Oh, things are picking up. People are working things out.

Like a bunch of these like wonderfully smart people have solved a bunch of complex problems over the last couple of years. Like, great. We are like hitting inflection points, you know, CRDTs and like Automerge and things like this are like actually making a huge difference. so I think I was just kind of blown away by how much sophisticated, hard technical work had already been invested into this. philosophy or dream, that made me go, Oh, this has to happen now.

Like this has to, this has to pan out. Like we've hit the apex, we're over the hump. Yeah, this was certainly the goal with the conference to just bring together all the people. There's so much. Momentum already happening, but a lot of it is like mostly felt on a given day on someone's solitary desk and like they're working on something and think, Oh my gosh, this is so cool, but like, does anyone else care? And then bring all of those people together.

The momentum compounds, and then you go even further and show like how this can have like a massive global impact. this is sweet. We certainly met all of those goals and exceeded them for ourselves. And thank you so much for contributing in such a meaningful way to, to that event. Yeah, no, I loved it.

And I'll also add on that I think I was also impressed by, everyone in this community is like, maybe, maybe by nature of being at a conference like this, which is trying to say, let's build software differently, like, let's do a radical change to the way software works, was, you know, Then the kind of person who was also thinking very creatively out of the box, like out of the norm about how we should build software, what software is, like who builds software.

it was a, it's a very like holistic, I think is the word I want to use, approach to understanding what. Software and programming is, which is what I always love at the right conferences. It's like, okay, we are not just showing each other like how to do API calls with some new framework, like React on the screen. Like, please God, no, not anymore.

But if someone could please talk about like how this fits into like developer culture or wider culture, I felt like there was a lot of that at the conference that I really appreciated. Yeah, that's what I think makes it such an inclusive and wide space, since at the end of the day, the, also the local-first essay was not very prescriptive in terms of like, you ought to use CRDTs, but laid out those ideals of like, of things that I think most people can get behind.

and some might see it as like a nice to have bonus and some others say like, Absolutely, I won't touch any software that doesn't respect all of those ideals, but I think this, kind of spans a very wide open tent. Yeah, I feel like it's sort of. Like the older people who have been in software a while sort of already knew this. They're like, yeah, you don't trust random companies with your data. Like we've seen enough of them die. Like they're very, like, I keep everything locally.

I make it all myself. And then I feel like, you know, younger people, let's say people like born after like 1985 or something, you know, we just, we Didn't live through that, that period of everything dying off as much.

And so a little bit more naive, a little bit more like, yeah, of course, all my data lives in the cloud at some random person's server, of course I don't own it, of course I don't have the ability to edit my apps, the sort of, blinkered by what we think is possible and what we think we're allowed to do in software. And this is kind of like unblinkering people being like, okay, you've been living in this paradigm, but this is not the way things have to be. We could change this.

This is just like how things unfolded because of market like forces. But. What if, what if you actually had control over your software? Like crazy idea.

Outro

I love it. Maggie, thank you so much for this wonderful conversation. Thank you so much again for contributing in such a great way to the conference, coining a whole new term and inspiring many, many developers and barefoot developers, soon to be barefoot developers. So thank you so much for taking the time today. Yeah, I really loved it. Thanks so much for having me chat. Thank you for listening to the local-first FM podcast.

If you've enjoyed this episode and haven't done so already, please subscribe and leave a review wherever you're listening. Please also share this episode with others. Spreading the word about the podcast is a great way to support it and to keep it going. A special thanks again to Rocicorp and Expo for supporting this podcast. See you next time.

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android