Andreas Kling, Creator of SerenityOS and the Ladybird Browser
Hello. Welcome to the Tuple podcast. Today, I'm talking to Andreas Kling. Andreas is the author of, believe it or not, an operating system that he wrote from scratch called Serenity OS. It started as a solo project for him but now has hundreds of contributors.
Ben Orenstein:He's also a bit of a YouTube phenom. He's got more than a 1000 videos on YouTube, tons of subscribers. He has more or less built a movement around this fascinating project of building an OS from scratch. Now he's also embarked on a browser from scratch. He's a man of ambition.
Ben Orenstein:He is a really fun person to talk to about code, but also personal things. I really enjoy this conversation. I hope you enjoy listening to it. So I thought it would be interesting to start with something that I saw in the frequently asked questions on the Serenity OS's, GitHub. And the question was, will Serenity OS support this thing?
Ben Orenstein:And the answer was maybe, maybe not, there is no plan. And the next question is, will you implement this thing? And it says, maybe someday, maybe never. If you wanna see something happen, you can do it yourself. And the thing that popped into my mind when I saw these responses, was actually that there's sort of a parallel between this, I think, and the term, lifestyle business.
Ben Orenstein:So as compared to a VC business which is supposed to get, you know, a VC backed business, which needs to get as big as possible, as fast as possible, a lifestyle business is maybe more optimized around the happiness of its founders and its employees, and it seeks profit, but it considers those things as part of it. And the phrase that came to me was kind of like it's almost like it feels a little bit like lifestyle software to some extent, where it's being done for the love of the people that are making it. Does that sound right?
Andreas Kling:That's absolutely right. Yeah. Those, those FAQs are pretty old by now. They're some of the very earliest things that we put in, because they they were so frequent in the beginning. People did not understand why we were doing what we were doing or, they were really interested in, like, asking us to add features for them.
Andreas Kling:And that every time that would happen, it would always turn into a discussion of, us trying to make them understand that they have to do it. Right? And it's, it's worked out really well, I would say. We've been doing this for 5 plus years now, and, we still get people coming in and they ask us to implement something, And we just point them at the FAQ and say, no. No.
Andreas Kling:You do it. But come on. It'll be fun. Right? And maybe half of people actually leave at that point, but the half that stick around, they, they have a lot of fun, and they stick around for a long time.
Andreas Kling:So it it is very much a a lifestyle software kinda thing. It started just for myself to have something to do, and I kind of I hoped when I opened it up to the world that it would invite others to use it in the same way that I was. I never thought we would make a product out of it or try to, like, formalize a release process or anything like that. I I really just wanted sort of a a a Zen garden or a Zen kindergarten for developers, if you will, where you could just go and chill and have fun with programming.
Ben Orenstein:Yeah. I like that. And it seemed like a core tenant for you was that you should be able to get to the source of everything up and down the stack, all the way. And so it's not it's it's like not even just a zen garden, but it's like a zen garden all the way down. Like, have fun playing at the lowest levels if that's what you want.
Andreas Kling:Oh, yeah. Oh, yeah. Yeah. I I came from, the last tech job last big tech job I had before making Serenity was, working at Apple for many years. And, I was so used to having control of the whole stack, because Apple makes well, they make all the hardware as well.
Andreas Kling:But they make all the software, like, every layer of the stack from from the bootloader to the printer software to the graphic, graphical interfaces and stuff. And being in that world, it just felt so weird when I left Apple that the rest of the world of software didn't function that way, especially coming back to Linux, which I used to, I used to use in the past. And it was just a very, very distributed, patchwork of software from different sources made by different people in different ways and super different from Apple. So I I wanted to sort of just get back to that Apple way of doing things. And the logical way to get there, I figured, was to just make it myself.
Ben Orenstein:Yeah. And, like, Linux is nominally open source and hackable all the way down. Oh yeah. Like in theory that is all doable but in practice there are so many different teams and stakeholders, and all of the bits are spread out all over. And to, like, upstream a patch is quite a process.
Andreas Kling:Right. Yeah. And and there, you know, there are many programming languages at play. You have different companies or stakeholders, as you say. That the real the the real pain when you try to do anything in Linux that isn't, trivial or localized to a single software package like, if you try to do cross cutting sort of vertical and vertically integrated, changes in the Linux desktop, The level of coordination required is prohibitively, cumbersome, let's say.
Andreas Kling:And at Apple, it was just so easy because you have all the people making the entire stack, within the same company, and you can go find the expert at everything. And it just seemed kinda sad to me that, the world of open source hadn't copied that from Apple because, you know, they like to copy things that the, big tech companies make. You know, like, in the nineties, Linux used to copy the way Windows would look, and then, they started copying the way macOS would look. But they never copied the way the software was made. So that was my my contribution, I guess, to the open source community.
Ben Orenstein:Yeah. And and it seemed like the it seems like a really key thing here actually is that maybe there's 2 things and tell me if there's more is like one is that it's a monorepo. So all the pieces are all in one place. You could land you could do one PR to change some sort of cross layer concern that goes like high to low and all the pieces are there to be seen And so one approver can get this patch landed across this this whole stack. And also that, there's one language.
Ben Orenstein:So you're not bouncing between a bunch of different, yeah, architectures or languages.
Andreas Kling:Yeah. Yeah. And, the we were able to make progress really, really fast. We were able to stand up, you know, recent reasonably capable GUI desktop, in just 2 years originally. And then, you know, development pace has slowed down as as people sort of found their focus areas that they wanted to, go deeper on.
Andreas Kling:But as a way of building software, I think we definitely showed that the monorepo approach, where you have everything unified, centralized, It's a very, very efficient way of building software. So, yeah, we're we're very happy with that. And even to this day, you know, now nowadays, people do specialize more in the project, so we see less new apps and new frameworks and stuff like that. We're more like, we're maturing our existing stack. But even even still, the monorepo still makes it easy to do this type of development as well, because, as you refactor APIs, for example, or you change the way that some components interact, the fact that you have to, like, commit the change to every piece of software in the system at the same time just forces you to make it compile at the very least.
Andreas Kling:It has to pass tasks tests everywhere. So it it just facilitates the development of a large system, I think. And it would be really interesting to see, other operating systems developed in this way. I think the the BSDs come a little bit closer because, you know, Linux is a huge patchwork of of random software. But, freeBSD, NetBSD, and OpenBSD, and and those kind of systems, they, have sort of a core, which has their kernel and all the command line utilities and drivers and a bunch of stuff is part of sort of the core.
Andreas Kling:And then they still layer, GUI software on top of that. But, they are a little bit closer to to what we were doing at Apple and what we're now doing in Serenity OS.
Ben Orenstein:It's really I'm struck because I watched I watched your most recent, update videos Mhmm. Of where you're doing I think it's a weekly or a monthly update of the of the projects. And one of the things you demoed was someone added the, like, interactive flag with the dash I to this copy command, the CP command. And the thing that really stood out to me was I think in a project that's 5 ish years old, let's say, you're probably the thing the new thing adding a new thing is probably quite challenging because all the easy stuff has been picked up. And so if you're adding a new thing, it's probably relatively difficult.
Ben Orenstein:I imagine this particular thing to add in interactive mode was not very hard. And the the the thing about building such a thing with so much scope is there's lots of places for people to make small contributions and gives this so you give an open source contributor an easy path in that makes it probably helps the project a ton because there's, like, there's just a lot of surface area where they can contribute.
Andreas Kling:Oh, absolutely. Yes. Another project of of the same age would have run out of easy first issues a long time ago, as you say. But given our ridiculous scope, I I sometimes wonder if we are the sort of the the largest scope project on GitHub. I don't know.
Andreas Kling:It's possible.
Ben Orenstein:Yeah. I don't know how you how you could add much more to it. Or, like, what what is bigger than this?
Andreas Kling:I don't know. We could start adding a website to it, maybe. Mhmm. But, yeah. The it's definitely still easy for new people to come in.
Andreas Kling:And, traditionally we've we've traditionally had this approach to onboarding new people where instead of giving them a list of issues that we think they should attack, we tell everybody, hey. Why don't you just build the system, boot up, and then mess around until you find something that doesn't work, or something you think could be better, and then try to work on that. And this simple little, thing has made it so that everybody who comes in just has their own perspective on what they think should be done. And they they sort of hit the ground running in their own direction, instead of everybody joining in sort of the shared direction. And that has been super healthy over a long period of time for the project.
Ben Orenstein:How do you are you saying no a lot? Do you just let people Not much. Swallow their hearts on this? No? Okay.
Andreas Kling:I'm you know, it's strange how little I've had to say no. There have been a handful of times when there's almost a theme to the things I've said no to. It's whenever somebody wanted to fragment, the sort of desktop paradigm that we were building. So they were like, oh, I think it should be configurable so that it could have a Mac OS dock instead of a Windows 2000 start menu bar. And then I should be able to select the GUI paradigm with a checkbox.
Andreas Kling:We've had that a couple of times. People try to do that. And I always just said, no, no. Let's just build, like, a single paradigm system because it's much easier to understand and reason about. But for the most part, somebody comes along, with some random change, it's gonna get in.
Andreas Kling:I mean, it might need a little polish, but for the most part, it gets in. I think there's a second part to that though is that I've been pretty good at just, communicating and broadcasting I have, you know, I think over a 1000 videos on YouTube of me just working on the system and talking about it. So everybody who came in that way, they were very well aware of of what the whole thing was about. So they just came in, and they just continued based on their understanding of that.
Ben Orenstein:So so powerful. That's that's so interesting. I was just thinking, like, well, imagine if your company had a 1,000 YouTube videos talking about its values and its culture. And someone had watched some even some meaningful subset of that. You come in and just and you have so much context and you sort of it's going to lead to actions that are gonna be congruent with what's already happening.
Andreas Kling:Yeah. I think so. Although, I mean, if if you put that in the context of a business, it starts to get a little bit weird at some point, I think, because it's hard to ask, you know, a new hire to watch a 1,000 videos about company culture.
Ben Orenstein:Yeah. But even even 5, even 3, I feel like I mean, I feel like I have a taste of it after a couple. And it's like you you've you've done a great job of distilling the and and this is like classic business advice for companies. It's just like as you get going, you start adding more people to the team, it becomes hard to individually shape their contributions to, to to align with everyone else's. And so the the sort of standard advice is develop your company values so that people can make local decisions and have them end up congruent with everything else.
Ben Orenstein:And you have you are, like, your your values are out there, and that helps new people show up and contribute.
Andreas Kling:Yeah. Yeah. It has been very, very powerful indeed. And I think I had no idea that that would happen when I started it. It sort of just, turned into a really good outcome.
Andreas Kling:I was just making videos because it made me uncomfortable. And, I thought, wow. This is really, really unpleasant. Why is this so scary to me? I need to do more of it.
Andreas Kling:And over time, I I grew more comfortable, and then it has had all these interesting side effects. But, it is it is very interesting what you say about, sort of transferring culture. And I think I've learned through this project that video is an amazing medium for that, especially the type of sort of unedited raw video that I've put out, which it I guess it can be very scary to put out because you're not editing, you're not filtering, you're just kind of sitting and absorbing my workflow. But at the same time, that's a lot of what I did when I worked at, the companies where I worked. So I I spent so much time at Apple just just sitting with senior engineers, watching them work and, commenting on what they were doing, or we would have a conversation about what they're changing.
Andreas Kling:And then they would come and sit with me, and we would do this for hours. And, I guess pair programming, in a way,
Ben Orenstein:actually Yeah. I would definitely call that pairing, for sure.
Andreas Kling:Yeah. Yeah. It was pairing. It was pairing.
Ben Orenstein:2 engineers looking at the same set of code is pairing.
Andreas Kling:Yeah. True. True. Yeah. It's strange.
Andreas Kling:I've my concept of pair programming has changed so much since everything became remote that now I think of it as, like, 2 people, on the screen sharing software. But Yeah. Yeah. No. The the the original pairing, of course, was just sitting at the same computer.
Andreas Kling:And, my YouTube videos became a way for me to invite people to pair with me, at a scalable level. So, it is asynchronous because they can only leave comments that I can't see live, but, even so, I was able to sort of pass on a lot of the stuff that I learned while pairing at my various jobs. So that was pretty wholesome. And, yeah, people liked it.
Ben Orenstein:Yeah. So is there no live chat then when you're coding on
Andreas Kling:these streams? For the most part, I've done, prerecorded videos and uploaded those. I've streamed a whole bunch, but I get so distracted by the chat, that, my streams were just, like, me talking to chat for an hour or 2 hours. And I tried a couple of times to do coding tasks, but it always fell apart because somebody would say something and I would feel like, oh, I have to talk about that. So, yeah, I I couldn't couldn't hack it.
Ben Orenstein:It's interesting how much hunger there is for raw video of people coding things with all the mistakes and delays and confusion and all that Like you you might sort of think that a polished version is better and yet it seems like the actual experience in real time is what people want. And I feel like it's actually still undersupplied. I think like people I think there's there's a hunger for it, and there could be way more of it than there is.
Andreas Kling:I I totally agree. And the sneaky thing about that is that I I edited I tried editing one of my videos once, and I liked it so much better when it was edited. I was like, oh, wow. They don't have to see my stupid mistakes. And I look like I just figure everything out right away.
Andreas Kling:This is fantastic.
Ben Orenstein:Yeah. Your your ego liked it.
Andreas Kling:Yeah. My ego liked it. Right. But it it was just a worse product in the end, because I think, I don't know if this is unique to programmers, but I would say we definitely, as as a community, have a high degree of imposter syndrome and, like, people just, struggling with, their sort of self perception and perception of their own skills. And just watching somebody more experienced struggle a little bit can be so helpful in releasing you from that prison.
Andreas Kling:Right?
Ben Orenstein:Yep. I think not even just helping with impostor syndrome, although I totally agree that is a big benefit. I think another is learning how someone who's experienced figures out gets unstuck. Like, what are the tools they reach for? How do they how do they debug things?
Ben Orenstein:I think is is that's part of the, some of that knowledge, I think, is the harder to come by bits of becoming a good programmer is is dealing with problems and developing an intuition for when a certain approach is likely to yield results.
Andreas Kling:For sure. Yeah. And that and that's also what I love about pairing is that, when you pair with somebody, then you're sort of just absorbing all of this, stuff passively that the other person has spent their career, picking up from a 1000000 places. And you pair with somebody, and you're just sharing all this stuff. You make a sort of sort of a soup of your combined experiences, and you drink from it together.
Andreas Kling:It's a strange process. But, I have, I have 2 employees nowadays, and we pair every week. And it's so much fun because they just work in different ways than I do. Although there's some overlap because they watched a lot of my videos. But, but still, it's it's great to just watch them work through stuff, and and I get to pick up, new things from them as well.
Ben Orenstein:Yeah. I think that is actually still a bit underappreciated is I think if you pair with someone for half an hour, you will learn something almost guaranteed. Yeah. For sure. There's even if you're in an area of the code base you're totally familiar with, if you're solving a rote boilerplate kind of problem, something about the way they're ready commit message or some little utility that they reach for to solve something, it's it's so dense.
Ben Orenstein:It's so rich with information. It's really hard not to learn something. Where if I'm programming by myself, even solving interesting problems, I might not be learn I I don't feel like I'm I'm learning new things at the same rate.
Andreas Kling:Yeah. For sure. And the the and there's another thing that happens also, which is that, I don't I can only speak for myself, but I I do some stupid things sometimes, where I do something in a really, really cumbersome and, overly complicated way that could be simplified. I just haven't bothered to learn how to simplify this. And when you pair with somebody, then they can call you out.
Andreas Kling:Like, hey. Why are you going through these 10 steps to do something that you can do with one command? And very often, it's something you do with Git, that somebody who's learned about Git can give you, like, the incantation to achieve the same thing in in one command instead of 4. And, that has been very helpful as well.
Ben Orenstein:Yeah. That that's and, like, that subtle pressure of someone else being there I think pushes code quality up too. You're like I don't want to do the hacky version because you're sitting right here like what's how do we do this the better way again? Let's let's look at the docs and figure it out.
Andreas Kling:Yeah. And it's whenever I pair with somebody and then, we don't get to the point where there's gonna be a pull request from what we worked on, but, a pull request is sort of uploaded, like, an hour we finished pairing or something like that. It is so much easier to review it when I've been there through the whole process, obviously. And I feel sometimes, like, if you could pair on all code, that would probably make it better. And it's just not practical, but it probably would make all code better.
Ben Orenstein:I yeah. I think it's a hard argument to argue against. That that feels right to me. Like, I think it pushes the code quality up for the code itself for sure. Yeah.
Ben Orenstein:Like, I think people people it seems like as an industry we have basically accepted like oh you have to review code before you merge it. We've also accepted code reviews. Yes. They're annoying, they take time, they block work, but they're worth it because they increase quality, they prevent bugs, they spread knowledge. I think most of what people want from code reviews you get more of from pairing.
Andreas Kling:Right. Yeah. Code reviews, it's just pair programming light. You know, it's like a more scalable form of pair programming. Mhmm.
Ben Orenstein:Yeah. And I wouldn't make the argument that, like, there is no trade offs here. Like, pairing is more exhausting, and you're, like, you're more limited. You could review a bunch of PRs in a day doing a lot of pairing a day can be tough. But I think in practice a lot of code review is like trends towards a fairly light cursory review of something and there's a strong social pressure to not be too nitpicky or especially not push back on like architectural decisions in a big way.
Ben Orenstein:Like when someone lands a big PR and you're like I really wouldn't have done it like this. I think there's, like, a much better way to do this, but it's already done. Am I really gonna, like, ask this person to go back and redo this and, like, or, like, reject this as is? But if you're pairing with this person, you can get that input in early before it's so hard to undo. And those little nitpicky things are just you kinda, like, keeping an eye out as you code.
Ben Orenstein:And, like, you'd be like, oh, we forgot this thing. Oh, maybe we should change this name a little bit or, like, oh, do we have a test for this? It's easier to push back, I think, on the big and the small when it's happening in real time with pairing.
Andreas Kling:Yeah. Very much so.
Ben Orenstein:How did you how do you think about intimidation when starting monumental things like like you have? Because it seems like Intimidation. Yeah. My my read from the outside is that when you started the OS, you didn't really think it was gonna go anywhere. So you you maybe didn't think, I'm gonna build an entire operating system.
Ben Orenstein:That's really scary. How do I even get going? You were just thinking, I wanna spend some time programming and have an outlet and and find something kind of fun to do, was sort of my impression. And so maybe that works for that. You sort of tricked yourself.
Ben Orenstein:Or like you just sort of didn't anticipate. I did. You didn't know where it was going. And so it was like you didn't have like you didn't need to have that freak out. But now it seems like you're picking bigger projects and stating fairly ambitious goals for them upfront.
Ben Orenstein:Like, we're gonna make a browser, and it's gonna be cross platform. Or, like, we're gonna make a programming language and eventually rewrite everything in it. So it seems to me like you have figured out a way to somehow live with this this fear, and I'm curious how you did it.
Andreas Kling:Yeah. I think the thing that I discovered was that if I just, set goals that are far out enough in the future, that makes it a lot easier. Because if I just say that, oh, I'm going to build a browser, it will be cross platform and you can browse the entire web. If I don't say a time frame, I feel like I have to hurry up. But if I say that, this is gonna take a couple of years, then it sort of becomes more, I don't know, doable to me.
Andreas Kling:Because I know that, if I have a couple of years, it's just a matter of grinding every day on my task list and showing up every day, making a little progress, getting a little bit better every day, and over time, that builds up. So setting these long scopes and being comfortable with them, at least, is what helped me become totally fine with, making these sort of grand schemes. And it's working so far, at least. But that's might also be because we didn't hit any of the those long time frame endpoints yet.
Ben Orenstein:No. I I think yeah. No. To me, the fear is worst at the beginning before you're starting to make some progress. And the progress because the progress feels, exciting and and probably provides motivation.
Ben Orenstein:So I I guess I'm most impressed that you would be willing to, like, get going when it's sort of the hardest and the the boulder isn't rolling at all yet.
Andreas Kling:Okay. Well, that I always found that pretty easy. Like, just, you know, kicking the stone so it starts rolling, that part is easy for me. And, I think it's easy for a lot of people, but then they give up when they realize how much work there is gonna be to it. Mhmm.
Ben Orenstein:Yeah. Yeah. That sounds right.
Andreas Kling:So maybe maybe I'm a type of developer that has a easy time starting new projects. And in the past, I also had a very easy time giving up on those projects once I started realizing, oh, my goodness. This is gonna take forever. And at least the key hack in my brain was to just say, well, this is gonna take forever, so let's do it. Yeah.
Andreas Kling:Just admitting that from from the get go. But I think, it can be very it's true that you can make a lot of progress early on, and it can be sort of intoxicating almost that, oh, my goodness. Look at all this progress. Right? But over time, you start to make smaller incremental progress.
Andreas Kling:That's just the nature of, software projects, is that as they mature, incremental day to day progress is smaller as a percentage of your total progress. And that's also something that you have to be comfortable with. And I think I I became comfortable with that in my, career working at Nokia and Apple and companies where we had huge software stacks already. And there was no way for me to contribute, like, radical changes to the software stack. It just was not possible because it was gigantic.
Andreas Kling:Mhmm. So I learned to be comfortable with that sort of slow incremental progress where I I knew I could contribute 1% performance improvement to Safari in a week, for example. If I focused, I could do that. And I learned to appreciate that as, like, a worthy goal, a worthy piece of progress. And that has helped me a lot now because now our software has gotten, to the point where we have to do these, like, smaller pieces of progress and accept that they are now, normal for us to to do smaller things.
Andreas Kling:Yeah. And yeah. It it hasn't been I think, some people have sort of disappeared from the project over the years because they enjoyed that rate of progress we had in the beginning. But for me, it always seemed like a temporary thing. Like, yeah, it's gonna be fast paced and fun while we're standing all this new architecture up.
Andreas Kling:But once it's in place, we're gonna have to paint. Painting is gonna take time. Mhmm.
Ben Orenstein:Yeah. It's I think I saw somewhere I don't remember which project it was, but I think you laid out something like a 10 year plan, or you said, like, this might take 10 years. I'm not sure. Right. And, like, I could see how thinking at that scale and kind of pre committing, like, yeah.
Ben Orenstein:10 years, I'll be working on this still. And so, like, let me the the scope of what we could get done in in that huge chunk of time is pretty large, so we're fine to, like, go after this.
Andreas Kling:Yeah. Indeed. Indeed. I think that's something that a lot of people found surprising when they first found me and and the project that I was talking about it at in sort of those scale terms. And, yeah, and, you know, it's now 5 years later, and we are further along in many ways than I thought we would be after 5 years.
Andreas Kling:Focus has changed a lot in ways I didn't predict, but, my goodness. We got a lot of stuff done, So that's cool.
Ben Orenstein:I interviewed a founder friend of mine about his company, and he was saying he said something and the context was well if I'm gonna be working on this for the rest of my life dot dot dot and It was interesting to see how that would change your thinking so radically. Where it's like instead of like this is a 2 or 3 year thing, it's like what if what if this were a 30 year thing? How would you what kind of pace would you be okay with, or what kind of ambition would you be okay having?
Andreas Kling:Oh, that's such a good question. Yeah. Exactly. If you start asking yourself that question, like, what if I do this for the rest of my life? What what should the ambition level be?
Andreas Kling:I think your answer says a lot about you as a person. Right? And what should the pace be? So I I enjoy learning about video game programming. I don't actually do it.
Andreas Kling:I think many programmers are like this. We sort of get into programming because we're gonna make games. It's gonna be awesome. But then it turns out we just like playing games. I don't know.
Andreas Kling:I was like that. And, but I liked learning about how games are made. And I think one of the weird things to me about how games are made is that you make a game. Well, at least in the past, you would make a game, and then you're finished. You sell it, and then you move on to a new game.
Andreas Kling:Nowadays, it's a little murky because, you know, you have DLC and updates and and whatnot. But, it seems very much like you sort of burst develop something, and you make 90% of the profit, in one big chunk. And that type of software development is totally foreign to me. I like this long, drawn out, large scale, stuff, and that's definitely what, what we're doing. And the the types of projects I've chosen to build also are just there's no way to finish an operating system or a web browser, or a programming language.
Ben Orenstein:You have a lot of people contributing now, but I still notice you at the sort of the top of the contributor list even this week. Like, you have you're more commits this week than any of the contributors to the project. So you're still cranking, obviously. How are you you seem to have a lot of output. You seem to be very fast.
Ben Orenstein:Like, when I watch you type, it is quick. You seem to have a pretty high clock speed. How how do you how are you so prolific? Was this a thing you trained? Did it happen pretty fast, and this is kind of just a natural state of you?
Ben Orenstein:Or is this the result of lots and lots of trying to get a little better with various techniques?
Andreas Kling:I think, lots and lots of incremental progress. I definitely got better over time. I think I still do. I try to get better all the time. And, I guess, one of the things that I try to always be conscious of is looking for ways to improve.
Andreas Kling:And maybe the best example of this in recent times, is AI, and LLMs. And, there is a large group of people that just refuse to use them for programming because they think that it is silly or, they see something wrong with it, or they feel like this isn't right to do this. And me, I was all over it immediately because here is a way to improve as a programmer, I thought, like, a better tool. Right? What could be better in this life than a better tool than what I already have?
Andreas Kling:And just I I try to always remember that there's always gonna be better tools, and I can I have to, like, learn the new tools and find the new tools and try them, get comfortable with them? That's the way to to stay on top.
Ben Orenstein:Yeah. That makes sense. Like, I think I sort of I noticed in my programming career,
Andreas Kling:and I think
Ben Orenstein:this is fairly common I had a ton of appetite for new tools when I was relatively new. I was like I was ready to learn all the things and try all the approaches And then maybe 5 ish years into my programming journey, I started I now have a toolkit that I'm very comfortable with and is very familiar. And I started to notice a little less interest in fresh tools or trying new approaches. And now 10 or 15 years in, I have I think even less and I'm a little bit more like, I'm sticking with Vim. I don't care.
Ben Orenstein:You know, like there's if there's something better, that's fine. But I'm a Vim guy. I just decided. But it seems like you have maintained that appetite of, like, give me the latest, give me the best, I wanna get better at all costs more
Andreas Kling:or less. Yeah. I mean, within reason, let's say. I think in web development, for example, which I know that you're you're a bit more in that space, there are so many tools all the time coming out that Yeah. It's not really feasible to stay on top of all the new tools in web development.
Andreas Kling:Mhmm. Mhmm. And I've been in more low level development where tools tend to come out a little bit more, manageable pace. But when new languages come out, for example, I like to spend some time to learn them. Even, even I I don't become proficient in them, but I I like to see sort of what are the ideas and, what's what can I learn from this?
Andreas Kling:And that's perhaps the one thing that has been bad for me about these projects that I started, is that I get way less exposure to other programming projects these days because I spend so much time in this sort of cinematic universe that I spawned here, that I don't know what's going on in in other programming projects so much anymore. I have this outdated knowledge of, what other projects look like.
Ben Orenstein:Mhmm.
Andreas Kling:But yeah. No. I I think it definitely helps me to try to learn new things and also, like, always stay programming. Try to write some code every day, you know. I think that's probably where a lot of people start to fall off a little bit is if you get comfortable not writing code.
Andreas Kling:That's something that has has actually become a challenge for me in in the last year because, I got a bunch of larger sponsorships, which allowed me to, take on some employees. And then I had a bunch of administrative stuff around that and a bunch of other, things that crept into my weekly calendar. And suddenly, there's all this other stuff I have to do. And some days, I have to make myself program, which is new to me, because I've never been a a manager in the past, and now I'm managing a little bit. So I totally see that what what can happen to somebody if you Yeah.
Andreas Kling:Let it slip away from you.
Ben Orenstein:Yep. Yeah. I can tell you from experience you will you'll have to fight for the programming eventually. 2 employees, not so hard. If it keeps as if it keeps going, you can kind of it can kinda slip away from you.
Ben Orenstein:I I did it intentionally, and I was okay with it, but it's the the burden of management and non coding tasks as your organization expands is is very real.
Andreas Kling:Yeah. But at the same time, I I really enjoy the sort of almost, like, leveraged programming that you can do with Absolutely. People. Right?
Ben Orenstein:Yep.
Andreas Kling:It is amazing to be able to just, talk to another person and sort of agree on something, and then they go and do it.
Ben Orenstein:Oh, yes. Yeah.
Andreas Kling:It's amazing.
Ben Orenstein:Yeah. The first time I really started experiencing that for real was incredible. And, and this was a Yeah, it's like someone else is working on our business. And it's it feels so good. And we're trading money for it.
Ben Orenstein:You know, everyone no one's everyone's winning here basically. And we're paying this coordination cost of having a person here. But yeah, when PRs start landing and changes start getting pushed and and now Tuple improves in ways that I didn't even know it was improving. Like I it's like that the project just happened and like, you know, goes out the door and it's like, wow. That's sort of the next level thing.
Ben Orenstein:A founder friend told me one time this experience of, refreshing the the landing site landing page for his product, and it looked newer and better. And he was like, I didn't even know we're doing that. That's incredible. I get it now.
Andreas Kling:Yeah. That's beautiful.
Ben Orenstein:It is pretty wonderful overall. There's there's trade offs, of course, but it's it is awesome to see.
Andreas Kling:Yeah. How big is your company now? Is it like 10, 12,
Ben Orenstein:something like that? Yeah. About about 12,
Andreas Kling:maybe 13. Okay.
Ben Orenstein:Yeah. Yeah. You know so, people don't know this, but you know Spencer. You've actually been, coaching Spencer for for a long time, since the early days.
Andreas Kling:Yes. For a very long time. I don't even remember how long. For years.
Ben Orenstein:Probably 6 years at this point. We started about 6 years ago, and I think I I feel like you and he started pretty quickly.
Andreas Kling:It's pretty early. Maybe 4 years ago or something like that.
Ben Orenstein:Yes. Yes. Yeah. Spencer is very good at figuring out what he needs to find in order to accomplish something and, like, doing that thing and, like, seeking out coaching is totally part of that package that he does. And so as as we realized, hey.
Ben Orenstein:We're we're all web programmers who wrote a lot of Ruby, and now we have this real time communication thing written in c plus plus He was like, I need a coach that knows knows what he's doing. And so Right. You probably know more about Tuple than almost anybody outside the team, at least architecturally. At least tech technically.
Andreas Kling:That's possible. Yeah. Given that you're not open source. Yeah.
Ben Orenstein:Yeah.
Andreas Kling:Yeah. No. I've known Spencer for a long time now. He came to me because he wanted to get better at low level programming very quickly. Mhmm.
Andreas Kling:And I hadn't done anything like that before, but I had, mentored people at at my jobs. So I figured it was similar to that. And then I we just I gave him a whole bunch of low level programming projects. And he was he was, like, a real trooper, like, just churning through all kinds of things I was giving him. Like, we wrote emulators and video games and whatnot.
Andreas Kling:It was a good time. And, I thought for a while that I wanted to do more coaching, but it is very time consuming, and, I ended up not pursuing that any further. But, we still have an an ongoing, relationship. So it's just evolved beyond coaching because now Spencer does other things.
Ben Orenstein:Yes.
Andreas Kling:I guess you know that.
Ben Orenstein:Oh, yeah. Oh, yeah. Sure. But yeah. That's that's understating it, I would say.
Ben Orenstein:But, yeah, I but thank you for, for your role in, like, Tupelo's technical success. Like, Spencer did did the work, but having a good coach is was very helpful, and I am sort of the indirect benefit of of your coaching. So thank you.
Andreas Kling:Oh, sure. Yeah. No. It was it was awesome to see just how that injection of confidence in somebody can lead to so much productivity. Especially if you have somebody who has who's, like, very talented.
Andreas Kling:They just need a little confidence boost, like, to to feel more competent, more confident, and then they can go and do amazing things very quickly.
Ben Orenstein:That's that's interesting that you're you're that's interesting that that's the thing that you flag and, like, less like, oh, I needed to teach him about pointers or something. And more that, like it sounds like more like the lesson was these things are not scary or magic, and you can if you go build a few, you'll sort of lose that fear around it and gain the confidence.
Andreas Kling:Yeah. That's exactly it. So I tell people all the time that the easiest way to understand how something big and complicated works is to make a tiny little model of it, in in software at least, but probably in other things as well. I imagine in the physical space, you know, if you can build a scale model of anything, it'll help you understand it better. Mhmm.
Andreas Kling:So, my go to piece of advice for people, because a lot of people have been asking me, like, how do I build a web browser? I want to make my own browser. Well, you just start by making a tiny little thing that can parse HTML, and then you start from there, the little miniature. Right?
Ben Orenstein:Yeah.
Andreas Kling:And it's super helpful.
Ben Orenstein:That's so funny to hear you say that because I've seen this behavior from the other side. And I would say this is actually a really core part of Tuple engineering culture is that we build a lot of little prototypes. Mhmm. And so it's like, oh, we wanna we wanna figure out this interaction and how it should feel. And so and we almost never build it right in the actual app at first.
Ben Orenstein:Instead, it's like a little playground app that just has that interaction until we agree that that feels nice, and then we start putting it in in the real thing. And I I feel like a lot of our larger projects start with that thing that then gets thrown away.
Andreas Kling:Yeah. Yeah. And build 1 to throw away is a key thing I learned from from one of my old mentors at Apple, old coworker of mine there. He would always start every complicated project by building a piece of crap version of it, and hack on it until it worked, and then just delete it and start over. And the first time I saw this, I was shocked.
Andreas Kling:This is like, what on earth are you doing? That's 2 weeks wasted. But, of course, I saw over time that once he had done that, he was able to rebuild it again in 2 days, and it was twice as good or even better. And
Ben Orenstein:Right. Just Yeah. I love that. It's Yeah. So you you you gain the wisdom with the first version, and you try a lot of things, and you could move fast and not sort of not worry about quality.
Ben Orenstein:And then when you delete it, you you now get the joy of greenfield development and, you know, a pristine start. But, also, you have this wisdom that you got the hard way that will inform the thing you're going to build.
Andreas Kling:Exactly. And and, oftentimes, it doesn't come out exactly the same way the second time Yeah. Which is the the real benefit of throwing it away, of course, is that, sort of when you revisit, the process again and and you go through the the steps of building up the architecture, you notice that, oh, this could actually be done in a easier way or simpler way or whatever. And just as you were saying about, poll requests where you don't really want to nitpick about architectural decisions.
Ben Orenstein:Yep.
Andreas Kling:You have the same sort of problem here where, you accumulate architectural mistakes in that first version. And by deleting it, you can correct them. And probably otherwise, you might not do that. You Right. Just get comfortable and say, like, it's fine.
Ben Orenstein:Yep. Exactly. All the inertia the inertia shows up because it's it's good enough. It's already there. It's already working.
Ben Orenstein:I'm getting close to this. I could just polish this where it is. And I I think I think the challenge with spikes like that is actually throwing it away. I think there's this moment where, like, am I really gonna delete this? It's, like, it really is pretty close.
Ben Orenstein:I could just but that is and I think that's where you really have to, like, exercise, like, the psychological power. Because the magic comes when you do delete it and you start over from scratch. But I think there will probably be a moment of hesitation.
Andreas Kling:Yeah. And, you know, I I definitely have been too weak sometimes, and I gave in and I kept the first version even though I shouldn't have, and then I had to iterate on it later to make it better. So it's it's sort of an ideal scenario that you have the the fortitude or the the strength to throw it away. But, sometimes you just wanna make progress also. That's understandable.
Andreas Kling:But, yeah, I I think building a lot of miniatures and throwing away the first version of stuff, Super useful techniques.
Ben Orenstein:Mhmm. Yeah. Those feel like like a really good programmer wisdom lessons that show up in pair programming or this kind of thing, coaching and Yeah. Interactions.
Andreas Kling:Yeah. It's it's tough in pair programming, though, to tell the the other person that, okay. So now it's the part where we throw everything away.
Ben Orenstein:Yeah. Well, yeah, I think it yeah. It's you mentioned watching more senior engineers do this, and that that's probably the easier version where it's like, hey. You're in charge if you say this is how we do it. Alright.
Ben Orenstein:If there's a little bit of
Andreas Kling:Right.
Ben Orenstein:Power there maybe.
Andreas Kling:Yeah. Yeah. Yeah. True. No.
Andreas Kling:That that was by far my favorite thing about working with senior engineers was just getting to watch them work for any reason. It was so helpful. I think I learned more from that than any of the work I did by myself.
Ben Orenstein:Yeah. Yeah. Same. And and when people ask me how to improve as a programmer, my answer always is pair with someone that's more experienced. Like, sit next to them, plug your keyboard into their computer so you can type 2, and just work as closely to them as possible.
Ben Orenstein:I had this sort of, like, miracle 3 months of, like, programming development where I sat next to someone. I was I was learning Rails for the first time and Ruby. And I was sat next to someone who was much more experienced, and we just paired, like, many hours every day. And my rate of progress stood for the that time was higher than it has ever been.
Andreas Kling:Yeah. I bet. I bet.
Ben Orenstein:Before I forget, I wanna you mentioned that you have really leaned into AI and LLMs for writing code. What specific tools are you using there that you that you could recommend for folks?
Andreas Kling:Well, at the moment, I lean very heavily on the GitHub Copilot. Okay. And I have ongoing conversations with Chat GPT all day, every day, basically. Just, like bouncing ideas and pasting code. And, but but, one of the most nicest things that has happened to me is that I have become a very proficient Python programmer in the last few months, despite not writing much Python myself.
Andreas Kling:It's just, I realized that, oh, I want to, like, process this big data that I have. I have some, like, JSON that I've printed out from my program, and now I want to get a bunch of statistics from it or something, or I wanna shape it somehow. And in the past, that would be, like, sitting and writing a bunch of, I don't know, I would do PHP or Perl or something, whatever language I would use to to do that. And nowadays, I can just explain to chat gpt what I want to do with this data. I paste in some of the data, and then I say, hey.
Andreas Kling:Can you, draw me a graph of this data or whatever? And it just writes me a Python program. And I love that, because I have enough programming experience that I understand how Python, sort of what Python is capable of. But I haven't spent the time with it to feel comfortable writing Python. So this is sort of the perfect, perfect tool here is, like, I have a proxy that allows me to write Python without learning Python.
Andreas Kling:And I I love that. I use it so much. And, at Copilot, I use just as a very nice, autocomplete, I guess. I mean, it it is what it is. But I've used it so much and that I've built an intuition for how to sort of provoke it into doing what I want.
Andreas Kling:So I learned, for example, that, if you structure your comments in a certain way, then it will follow from your comments and sort of pick up what it is that you're trying to do and then sketch out the code just the way you like it. And it's it's like a whole art form to that if, like, prompting it via comments and putting all of your data structures nearby. And there are all these little things that you you discover sort of intuitively by just using it a lot. Right? And I think, many people say, oh, I tried Copilot, and it doesn't I don't get the the big charm or the big deal about it.
Andreas Kling:But, really, the big deal about Copilot, you'd only discover once you've spent, I don't know, a week aggressively using it, I think. And I I uploaded a video to YouTube. It was October last year, I think, where I wrote a JIT compiler for JavaScript in I don't know. It was, like, an hour and a half or something using Copilot. And 100 of people, reached out to me about it saying, like, what the heck?
Andreas Kling:I did not realize Copilot could do this. Because Copilot was, like, doing so much of the heavy lifting. I was just sort of commenting what I wanted it to do, and it went way faster than I could have ever done. That same thing would have taken me, like, 8 plus hours in the past because I would have had to look up a bunch of things and test and cross reference. And the speed was just,
Ben Orenstein:that's awesome. We'll have to link to that. That sounds really useful. Yeah.
Andreas Kling:Yeah. That video did really well.
Ben Orenstein:Yeah. That's that's the beauty of recording what you're doing and publishing it is I don't have I don't have to not prompt you for all of your copilot tips. We can send people to, like, you know, pair with you virtually to see how you're doing it.
Andreas Kling:True. True. And even that was, like what is that? Like, almost half a year ago now, 4 months at least. And I've still used Copilot every day since then.
Andreas Kling:So I've gotten way better at using it. And the only part that I don't love about this is that I'm not sure why I got better at using it or how or what it is that I'm doing.
Ben Orenstein:Interesting.
Andreas Kling:Because you have to kinda actively think about what it is that you're doing to almost, lead Copilot to doing what you want. Yeah. And I think a lot of it is subconscious or unconscious that you're sort of discovering these things that don't work, and then you see them not work a couple of times.
Ben Orenstein:Mhmm.
Andreas Kling:And then you start doing something a little bit differently, and that works. And now you Mhmm. Feel more inclined to do that. And
Ben Orenstein:Yeah. You're training your own neural net to use this other one.
Andreas Kling:Very much. Right? Yeah. You you're just sort of synchronizing with Copilot.
Ben Orenstein:Right. Yeah. It's interesting that this is a new this is a new skill for programmers to learn.
Andreas Kling:Yeah. Like,
Ben Orenstein:I guess tool use is always a skill, but this is sort of a new new class of tools.
Andreas Kling:Right. Yeah. It attaches to you in a very different way. And, we lost Internet access here at home for a while.
Ben Orenstein:Mhmm.
Andreas Kling:And my goodness. That was unpleasant because now I didn't have Copilot. And Yeah. I was not prepared for how much harder it was to just go back to not having it. Yeah.
Andreas Kling:It felt really weird. Like, I felt naked. It's it was a bit like, how you feel when you I guess, when you lose Internet connection in general. It just felt like I had lost this capability to go fast, and I have to write everything myself again.
Ben Orenstein:This, this feels like exactly the kind of subtle knowledge, workflow knowledge that is maybe hard to write down or distill. And you even just said, like, it's hard you're not even sure what it is. Yeah. But by watching someone do it well, you can see the examples and kind of pick it up on it. And maybe you can't define all the rules yourself, but you can start to imitate that that good use.
Andreas Kling:Totally. Totally. And I think, the thing that scares me, I guess, about it is that, somebody will put out a new LLM or Copilot will get an upgrade. And then a lot of the stuff that I learned, all these subconscious cues and and triggers and whatnot, they no longer work or they don't apply anymore. They suddenly work differently.
Andreas Kling:I don't know if that's going to be jarring or sort of uncanny or how's that gonna feel? Because I've tried some other AI products to program with, but none of them feel right in the way that Copilot does, but that's probably mostly habit. Right? I've learned Copilot at this point. Mhmm.
Ben Orenstein:Yeah. Or it could be better. It might be that no one has has gotten to that level. They might just actually be better at it.
Andreas Kling:Yeah. I guess. We'll we'll see what happens with that. Yeah. But it's exciting.
Andreas Kling:I think this is super exciting stuff.
Ben Orenstein:It's really cool. I've been I've been out of the coding game for a little bit, and this is hearing you talk about this and other people saying similar things is, like, one of the strongest things pulling me back in. Where it's like, I I could not just get back into programming, but get back into programming significantly faster than before, that's pretty appealing.
Andreas Kling:Oh, yeah. Oh, yeah. Yeah. Yeah. Once you get good at it, it's, like, at the very least, the 3 x multiplier, I would say.
Ben Orenstein:That's crazy.
Andreas Kling:Yeah. And just in terms of, like, churning out code. Not even doing thought work where you're figuring out architecture or anything, but just doing the work of, like I had no code. I know what I wanna do, but I have to type it all out. Yes.
Andreas Kling:It makes that so much faster.
Ben Orenstein:Yeah. Like,
Andreas Kling:if you know what you wanna do, you can do it much, much faster with Copilot.
Ben Orenstein:Totally. That makes sense. And I remember advocating for people to learn their editor really well and to get fast at piping. Not be like, because the the time between I know what I want to be there and the code is there is all cost. Right?
Ben Orenstein:There's no you want that as small as possible. There's nothing good about that once you know what you want and what it should look like.
Andreas Kling:Sure. Yeah.
Ben Orenstein:And so the fact that there's a thing there to speed up that to shrink that that time is without even having to really learn well, I guess you're learning a new skill to do it, but still, the fact that there's an an accelerant there is is very appealing.
Andreas Kling:Yeah. And I think one thing that perhaps isn't talked about as much is that it's a great accelerant if you know what you're doing. I don't know what effect it might have on somebody who doesn't know what they're doing, somebody who's, like, relatively new to programming right. Is this helpful to them or is it, sort of just helping them shoot themselves on the foot faster or harder? Right?
Andreas Kling:I don't know because I I don't have that experience. I haven't talked to I mean, I have heard from a lot of people who say that they don't like it. They don't, understand what's so good about Copilot. Maybe this is part of that, that they're they would benefit more if they had more experience programming.
Ben Orenstein:Yeah. That sounds plausible to me.
Andreas Kling:Yeah. But I I think over time, these tools will get better, and they will get better at servicing the needs of less experienced programmers as well.
Ben Orenstein:That seems right.
Andreas Kling:But I'm I'm curious, actually, about sort of the utility of LLMs in pair programming because, at the moment, it one of the complaints that I got on my video where I was using an l m for the first time programming, I got a 100 people, saying, oh, this is awesome. But some people said, I can't follow along with what you're doing anymore. In your past videos, you would explain what you were doing and sort of type it out while you were explaining, and I could learn. But now you just type a little bit, a lot of code shows up, and you look at it and you say, oh, that's right. And then you move on to the next thing, and I can't follow.
Andreas Kling:And I feel a bit like when you're using this in a pair programming context, if you're sitting with a senior engineer and he presses a few keys and, like, a huge block of code shows up and he just says, oh, that's exactly what I wanted to do, like, autocomplete, continue with the next thing, That's probably harder to learn from as as the junior sitting sitting along. Right? That sounds right. Yeah. So what do you do with that?
Andreas Kling:I don't know.
Ben Orenstein:I mean, I think probably a core skill of programming is a probably good measure of your, like, familiarity and skill of programming is how fast you can read code and understand it and grok it. Mhmm. So in a way the junior person should be trying to get better at looking at the big chunk of code that just got inserted and going, yep, that's what we wanted. And so there might be some benefit in the, like, trying to keep up with the slightly more experienced person and sort of like try to read it as fast as they are and take it in.
Andreas Kling:Oh, you think it's like a 4 minute mile kind of thing?
Ben Orenstein:Maybe. Yeah. Like, do you get better at reading code quickly if you don't try to read it faster sometimes? Maybe
Andreas Kling:not. Yeah. And, also, like, well, once we start doing this, then we'll realize that, oh, juniors are perfectly capable of going faster. We just never pushed them before.
Ben Orenstein:Yeah. Yeah. I think I'll yeah. I also imagine it's not just I imagine you are probably not always reading every little symbol that comes as you insert it and more like the shape is right. I'm not seeing any red flags immediately in here.
Ben Orenstein:This is roughly what I expected. And learning that kind of ability to kinda glance at a block of code and go like, yeah. I think that's right ish, is probably also a thing you're training here, and that seems useful too.
Andreas Kling:Yeah. True. True. Yeah. But so but that's that's one aspect of LLM and sort of how it affects pairing.
Andreas Kling:Yeah. And I think there's another thing also where can you use LLMs to pair with you, sort of organize it in that way somehow. And GitHub is definitely trying to have this copilot chat thing that you can talk to, but I feel like the real pair experience requires, like, unprovoked random comments coming from
Ben Orenstein:Yeah.
Andreas Kling:From somebody. Right?
Ben Orenstein:Right. Yeah. That sounds right.
Andreas Kling:There's a killer product. Yeah.
Ben Orenstein:Yeah. That does sound really good. Right? I think as long as yeah. Depends I mean, it's all the details.
Ben Orenstein:Are the suggestions good?
Andreas Kling:Right. Yeah. Like, just you get a pop up suggesting you rename all the variables every now and then.
Ben Orenstein:Sure. Yeah. Yeah. But that that does that is interesting. I was also thinking it's not just the random comments, but it's also the, like and then sometimes it's typing.
Ben Orenstein:It'll do the typing for you. So it's like, hey. Like, should we maybe add a test for this? Do we want I'll do it. Sure.
Ben Orenstein:Boom. There's the test. Like, that that's there's some nice things to that, I think.
Andreas Kling:That capability feels very, very close.
Ben Orenstein:Yeah. That sounds right. Sounds right to me. It's more
Andreas Kling:like the the discussion
Ben Orenstein:sort of,
Andreas Kling:not just local, but, like, architectural discussion about the whole project and, like, oh, where does this fit in? How do we evolve? And so on.
Ben Orenstein:Totally. Yeah. I think folks are probably pushing on that real actively. Getting bigger context windows to understand the whole project to make that kind of
Andreas Kling:advice. Yeah. Do you think there's, future in DuPle for a tool like that to be integrated in in your product?
Ben Orenstein:Possibly. It's it's so different than the world we've been in so far, that it feels it'd be like a pretty big new frontier for us. I'd say maybe.
Andreas Kling:Yeah. It's a little buzzwordy.
Ben Orenstein:That doesn't bother me with the buzzwordy bit. It's, I guess, the question of, like, is this our lane? Do our customers want this? There's there's I think there is some value in simple tools, and like we are mostly about connecting humans to humans and people tell us sometimes like please don't add anything else to this. Like I like the small footprint.
Ben Orenstein:I like the simplicity.
Andreas Kling:That's fair.
Ben Orenstein:Yeah. I, one of our employees had this great analogy that I really liked, which is, thinking about software as being having different food groups in it. And new features are like carbs. Like, they give you energy to work on. They're exciting, but they also kinda like bloat you a little bit.
Ben Orenstein:They add a lot of they can add a lot of calories, and so you don't wanna, like, eat too many of them. Make sure you're you're eating your vegetables first of, like, quality and reliability and that sort of thing. So a an LLM pairing assistance is a lot of carbs. So I wanna make sure we've we've eaten a lot of protein and veggies before we we add that.
Andreas Kling:Yeah. Fair enough. Fair enough. Yeah.
Ben Orenstein:Cool. Well, maybe we leave it there. We're we're right at an hour. This has been this has been great.
Andreas Kling:Sure. Yeah. This is great indeed. Very interesting. So many things to talk about.
Ben Orenstein:Totally. Is there anything we didn't cover that you're is on top of mind, or you think would be fun to chat about?
Andreas Kling:Nothing comes to mind immediately. It's it's your show. You're you pick the topics.
Ben Orenstein:Fair enough.
Andreas Kling:It's it's really fun to just talk about these random things like this because it sort of just reactivates these neural pathways that have been dormant for a while.
Ben Orenstein:Nice. Yeah. I like it too. Actually, there's maybe one more thing that I'll I'll ask you about before we wrap. You're now operating a much more mature open source ecosystem, basically, at this point, series of projects.
Andreas Kling:Yeah.
Ben Orenstein:Like, I just I glanced at this week's stats, and there were 73 PRs merged from 29 authors across a 180 zip commits, which is substantial. And there's, I think, a 1,000 plus contributors now across these projects. So different than your early days. How how are you handling I guess, you have some employees now. Is that your answer to how you handle this, like, much greater volume?
Andreas Kling:Not really. So my employees are specifically tasked with working on the browser only. So, the greater Serenity OS project just keeps running in the same way that it always has. I have a bunch of co maintainers that I've appointed to help, sort of move the PRQ along and help people, polish their changes until they're good. But the whole thing has grown organically, very much just based on what we need at the moment.
Andreas Kling:I'm Just trying to figure out what is the smallest incremental step that we can do to keep everything working the way we like it, but just improve it a little bit so that it, it's easier for everybody. And for the longest time, the first couple of years, I was the only one who could merge a PR. But at some point, I realized that the PR number keeps going up, and I can't get it to go down anymore. So I had to appoint some more maintainers. And, I did that, and then eventually, it started going up faster than they could bring it down.
Andreas Kling:So we had to get more maintainers. And it's it's been like this organic growth of of, infrastructure around around that. But
Ben Orenstein:somehow,
Andreas Kling:I don't fully understand this myself, but, we've managed to build a community that, takes care of itself, that regulates itself and polices itself, and produces consistently high quality code. And people help each other do that, and it works beautifully. And I, you know, I can say that I started the project. I seeded the culture, and, I did my best to set it up in a way that I thought would be nice for everybody, but it's very much a living organism on its own at this point. Like, I go, days in a row without merging code.
Andreas Kling:Okay.
Ben Orenstein:And there are areas of the code base that you know nothing about? You're just you've just
Andreas Kling:yeah. For sure. Yeah. And I was talking to somebody. I think it was just this morning.
Andreas Kling:Somebody who came into our Discord for the first time, a new user, and he said that he feels very intimidated by this huge code base because there's all this stuff. And, like, I feel like I can't learn all this, and I I really have to learn all this to work on it. And I told him that I don't know how all this works anymore. And he said that that was a relief. So Nice.
Andreas Kling:I think that's good. Good to good to know for people that nobody knows how everything works anymore. But we've have a distributed network of experts and enthusiasts. And I think, really, that's the biggest thing you can hope for when you start an open source project is that one day, it will be maintained by a network of experts rather than by just you. Right?
Andreas Kling:And you have all these people around the world who know how part of it works. And all those experts overlap, and they cooperate, and it's it's beautiful. It's, like, the best it can be.
Ben Orenstein:That is beautiful. And I think I've seen you write you're sort of thinking about what happens to this project when I'm gone or like how how it will outlive you and what it will be. And it's that long time horizon again where
Andreas Kling:Yeah.
Ben Orenstein:If you think about that being the goal that it should live on, then you have to release control. You have to delegate. You have to establish this network and this self healing, self policing kinda community around something.
Andreas Kling:Indeed. Indeed. Because you can't always be there to to steer things. So, it's the same thing with, like, community behavior, that, when we started our Discord server, we had a very small set of rules that we started with. I just put made a list of things I thought, oh, this is probably a good set of rules.
Andreas Kling:And then a few situations have come up over the years where we had to add a new rule because somebody discovered a new way to to annoy everybody. Mhmm. But, it was interesting to sort of evolve a set of rules for community behavior. Instead of, I know it's very, very popular to sort of take these ready made set of rules.
Ben Orenstein:Right. Grab the code of conduct from somewhere and throw it in
Andreas Kling:your Right. And that never seemed right to me that you would just, like, take somebody else's rule list and say, okay. Now the community is gonna conform to this set of rules that come from somewhere else. It has nothing to do with us, and has no sort of relationship with sort of social issues that we've had in our community. Yeah.
Andreas Kling:So yeah. We we grew our code of conduct, if you will, organically, and it has worked beautifully.
Ben Orenstein:Very nice. Cool. And if someone wants, they could take that and start their own project with it and ignore all your advice.
Andreas Kling:Yeah. I guess so. No. I I know that at least one other project has, sort of adapted, not adopted, but adapted our Yeah. Rules.
Andreas Kling:But, really, I would if I were to give any advice about this, I would say, like, just make your own list of rules, and then be willing to iterate on it. Because, every every community is different. And if you think that your software community is like just a generic, one size fits all software community, that can have a generic set of rules, I think it's more complicated than that. You have to be willing to experiment a little bit.
Ben Orenstein:Well, I've this seems to be the theme of you of start from scratch, make your own thing, iterate on it, spin that loop.
Andreas Kling:Yeah. Yeah. Yeah. True. We do that for everything.
Ben Orenstein:Yeah. Well, it seems to be working. Thanks so much for coming on. This was, like, such a nice chat. I really enjoyed it.
Andreas Kling:Likewise. I really enjoyed it as well. Thank you for having me.
Ben Orenstein:Yeah. And thank you for all the help you've, fairly directly given to 2 people through Spencer over the years. Sure. Yeah. Alright.
