Transcript

00:00:00 - Speaker 1: Building my own tools, when I type a character in or hit save, I know exactly where the bits are going, and I think that changes the relationship that you have with your software. There’s kind of a power dynamic where if you don’t know what the company that’s providing you some software products is doing with your data, they have the power, whereas if you build your own thing, you understand exactly what’s going on, you’re in control.

00:00:25 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad. This podcast isn’t about Muse product, it’s about Muse the company, the small team behind it. My name is Adam Wiggins. I’m here with Mark McGranaghan. Hey, Adam, joined today by Linus Lee. Hello, hello. And Linus, before the call you were showing me on video chat here, you have a fun new gadget in the audience would like to hear about that one.

00:00:50 - Speaker 1: Yeah, this is always good audio podcast materials when you have to show something off visually, but I semi recently got this thing called the Surface Duo, which is an Android phone from Microsoft, but the Android part’s not super interesting. What’s interesting is it folds out like a book. It’s about the size of a passport, and if you imagine. Passport, but it folds out and there’s screens on both sides of the book, and there’s like a stylus you can use on it and it’s meant to be sort of like a multitasking, multi-screen, note taking on the go productivity kind of phone, and the screen there is continuous, it’s using the folding screen technology is there a scene there.

00:01:24 - Speaker 1: There’s a solid theme there, it’s two separate screens, but it’s like if you imagine like a Nintendo DS from way back when, tilted on side.

00:01:33 - Speaker 2: Or yeah, maybe a shrunk down multi-monitor set up.

00:01:36 - Speaker 1: Yeah, exactly, and it’s great for reading, great for like general kind of content consumption, taking notes, things like that, not so. For like watching videos or like Instagram’s really struggles to fit on that screen because it’s basically square. But yeah, I’ve been enjoying using actually, one of the perks of living in New York, where I live is that all the tech stores are just lined up right down 5th Avenue so I can go visit them when I go running. Microsoft came up with a new one, I think just last week or something like that, and I went down yesterday to visit it and they didn’t quite have it on the shelf yet, but maybe soon, maybe I’ll upgrade.

00:02:08 - Speaker 2: Microsoft’s Surface line has continued to impress me. We did a quite a bit of prototyping on one of the Surface tablets from a few years back, and just in general, what they’ve done there, kind of going into hardware and doing such a good job at it, is really quite impressive for, especially such an established, you know, company which are not known for that kind of innovation or moving into brand new markets and doing a good job.

00:02:32 - Speaker 1: Yeah, definitely, it seems like they sort of see their responsibilities of doing things that are weird. They’re very reluctantly did like a classic laptop form factor. So yeah, I like it.

00:02:42 - Speaker 2: And could you tell the audience a little bit about your background and interests?

00:02:47 - Speaker 1: Yes, so my name is Linus. I say I grew up in Indiana, which is where I spent most of my childhood, before that, I spent the first half of my childhood in Korea, just where my family is from, but I grew up in Indiana, like normal kind of public high school towards the end of that high school experience, I kind of self taught myself how to code JavaScript backbone, react kind of stuff.

And then got a little job over the summer at a software startup in the area called Spencer. We did agriculture, precision agricultural software, so basically using some hardware in the field.

Indiana is a farming state, so hardware in the field plus some weather data and satellite imagery and other things like that to try to Improve efficiency and ease of producing food for humans or for cattle and and so forth.

And so I was there for about that summer and then ended up taking a year off after high school to work there, learning Django and JavaScript and all that good stuff, and that was my first kind of real programming gig.

I learned a lot there for about 2 years and then after that, the company itself ended up getting bought, then I had a few extra months to travel and things like that, and then went to UC Berkeley, where I studied computer science for a few years just in California, so went to Silicon Valley, did some other startup stuff, was briefly part of things like relate, which is online IDE. Oh yeah, they’re doing some pretty cool stuff, and a couple other projects, and then recently I moved to New York, just where I am now working at uh another software startup doing sort of tools for thought space things called idea flow, and then all through that time sort of off on the side I’ve also been doing random other. Experiments, building my own various side projects and writing a little bit and things like that, which I’m sure we’ll get more into.

00:04:32 - Speaker 2: Yeah, well, I would think looking over your homepage and your Twitter account and your blog posts that these what you call side projects appear to me like they could easily be a full-time worth of output. So doing that on the side from your regular work as opposed to, I don’t know, a retired gentleman who can spend his full day building interesting tools that certainly speaks impressively to your output or maybe passion for building these tools.

00:04:59 - Speaker 1: Yeah, that’s a misconception that I’ve gotten a couple other times. I think it’s actually interesting to think about, like, having to work a normal job, like not being completely free on your own to follow all your whimsical ideas and having a bit of constraint on not only your time but also like having to use normal note taking tools and having to like use notion and talk to people and slack and things like that I think is a good kind of way to ground yourself.

00:05:25 - Speaker 2: Yeah, we actually see this dichotomy in the we call it the research world, or even in like a classic software company that has maybe like an R&D arm with sort of mad scientists thinking big ivory tower thoughts versus the more kind of production like please our customers, keep our systems running thing and you typically have If you’re too much in the research, free floating, just have big ideas, you’re not constrained by the realities of the market, or customers or anything else, you’re just out of touch, and it’s hard to like, make things that are meaningful.

But of course, on the other side of the equation, if you’re really deep in the trenches of doing an atlas holding up the world kind of thing with production systems, and you’re thinking about tomorrow and next week, and you just can’t have big open, out of the box thoughts or, like you said, explore weird whims or unusual directions. So it’s a difficult dichotomy, seems like you’re walking that line though.

Yes, yes, definitely. So our topic today is self-made tools, and of course, Linus, your work is a stellar example that I’ll link to some posts here, maybe Moocle is an interesting one here. You have a post explaining your motivation for that, and there’s a few other posts we can reference here, or other folks I know who are really prolific self-made tool makers. But yeah, what does that mean for you? What are self-made tools? Why do you do it? And is it something you recommend others explore, or is it only for a certain kind of person, maybe?

00:06:51 - Speaker 1: Yeah, so the way that I look at my tools is a lot of the software that I rely on to function as a working human day to day are things that I built myself to varying degrees.

I have notes apps that I built that I used to keep sort of my personal information in, in general, a little bit. I have obviously things like my website and other kinds of public presence things, but also like a contacts app, CRM.

Your typical productivity suite kind of stuff, and then because these are just sort of like things that I imagine and then I go build, there’s also things that sort of don’t exist as general purpose things in the market that I’ve built out, like a personal search engine, which is the monocle that you referenced earlier, where I have all my data sort of shoveled into a search index and then I can search for anything across any of my sort of bank of data from people that I’ve met to conversations that I’ve had to websites that I’ve bookmarked and things like that.

So some of them are sort of what you would normally imagine as side projects, so like off the shelf libraries and frameworks and things combined into things that I put on the cloud, and other ones are more involved.

Monacle, I think is a good example where the search index that I use for that is one that I built myself. It was originally a project to learn how kind of full text search worked and then that is then written in a programming language that I wrote called Inc and this that kind of goes very deep into that.

Yeah, things that I built myself to fix my own problems or solve my own solutions, or solve my own problems, I guess, and really for myself only, nobody else, I mean I guess if you wanted to, you could go to get up and clone those down and deploy yourself, but a vanishingly small number of people do that and so it’s mostly just for me to use.

00:08:29 - Speaker 2: As you sit there and describe, writing your own full text search engine, writing your own programming language, sort of not just the end application, but really going down the stack.

I’m reminded of this, it’s basically a meme now, but I think it’s like an excerpt from a movie where there’s a guy that wants to change a light bulb, so then he goes to get the light bulb out of the cabinet, but then it turns out that the cabinet’s got a Loose things that he’s going to get the screwdriver, but then the screwdriver turns out that it’s in the squeaky drawer. And at the end, I think like his wife comes home, what are you doing? He’s like, I’m changing the light bulb, obviously.

So it feels like with technology and software systems today, I mean, the stack goes very, very deep. How do you decide when to like stop diving down. I guess another way to put it was, how much is the decision to say, for example, write your own full text search is that a pragmatic decision versus following your curiosity. You want to learn how this works.

00:09:21 - Speaker 1: Yeah, I mean, to the question of when do I stop, it’s really when my curiosity stops being strong enough to get me through learning whatever I have to learn.

Back months and months ago when I was more naive, I mean this is all endless yak shaving, right? Like I needed note taking app and then I realized I need a front end library and then I realized I need a language.

And there was a point in time when I was sort of made to myself the argument that ultimately this is sort of a more productive way to work because in the end, the little time that I take to build my own tools is gonna kind of come back because it’s sort of so fit to the way that I think and things like that. And I think to some degree that’s still true in that.

When I’m really in the flow, I’m more productive with the tools that I built, but I think really the argument that building your own kind of software ecosystem is more productive may be a little flawed, but I think the change of mindset that I’ve had is, I mean, I still do it and so there still has to be a good reason that I do it, and I think for me that reason is that it just changes the relationship that I have to the software that I use.

And that if it’s my own tools that I built on top of my own stack, running on it runs on the cloud, I use digital lotion, so I don’t want to control everything, but to a large extent running on sort of things that I understand, I can trust it more. It feels more personal. I mean, I made it sort of handmade it obviously and so.

I think it changes the relationship that I have with the software that I use, and the data that I get to keep on it and trust it a little more and makes it feel more little more personal and durable.

And so I think that’s the benefit and along the side, I get to kind of learn a lot, right? A lot of my side projects are motivated by just encountering some new piece of technology that I don’t understand, and then I use. Building a kind of prototype clone of whatever I’m trying to learn how something works. I use that as the excuse to build another tool like the search engine or I have like a toy assembler that I made which I don’t need to assemble X86 code very often, so I don’t use that as much, but it was a cool learning project.

00:11:20 - Speaker 2: Yeah, I really like the personalization angle. I think there’s also this element of agency or self-actualization or something like that, that fits into the same theme.

You know, we had Wei Wei Xu on the podcast, for example, we talked about the fact that you have this homogenizing effect of now that most technology is made by these absolutely massive companies that are practically nation states, and of course, they’re appealing to the widest possible audience, and that fits into the kind of software.

Yeah, basically, the wider an audience you can reach with your software, you know, the more you can become one of these huge empires, but then very much lost in that is not just sort of niche software, but also just things that are weird, different, appealing to a smaller audience, and in a way, the personalization side is, you know, when you’re making something just for yourself or just for yourself in a small group, that’s about as personal as it gets. It’s a nice antithesis or palate cleanser or something from Let’s say the mass produced software that honestly is what rules our lives now.

00:12:23 - Speaker 1: Right, definitely the phenomenon of like every fast website looking like Stripe, but a little bit worse.

We were talking about something related right before the show about how there’s sort of two bifurcating kind of classes of software, the one that you just referenced the kind of big company one. is things that are meant to be sort of lines of business, things that companies sell to other companies or other people, and they sort of have a tendency to grow indefinitely, like you build a prototype, you start selling it, people need more things and so kind of grows unboundedly both in terms of like feature setting complexity. Technical debt, but also in terms of just codeba complexity.

It’s just easier to add things when you need the product to do newer things and more things, whereas the idea of situated software where you have a very finite group of people you’re building for and a very finite use case you’re building for, which is frequently what I think my tools are, I just needed to do these three things. Take my notes, save them, I want to be able to read them, I want to be able to send it to these places or receive some notes from these places. And I know exactly what I want, maybe I’ll want to add one or two things there, but it’s definitely not going to grow unboundedly. It’s definitely meant for only me or only the small group of people, and I don’t really care if that many people use it. It’s sort of an underrated group of software, but I think there’s places where it’s the right thing.

00:13:41 - Speaker 3: Yeah, and just to riff on this piece a little bit, so I agree with all of the sort of first order reasons we gave around, it can be more fun, you get to learn, you have the potential for it to be more fit for purpose for you personally, but there’s also interesting second order effects with this focusing.

So you talked about how the general purpose tools they have all these. Layers that are built up over time, because they need to serve a lot of use cases, right? And with all those layers, even if you have a very focused use case for the software, you’re kind of stuck with those because the layers, they end up coupled with each other and you have all these weird linkages, so you can’t just boot out some piece of it.

So for example, if you want to make a very basic static site, well, OK, now you need the static site generator, and now you need a library system, you need a package manager, you need a way to install the package manager. Need a way to check for security vulnerabilities and all the packages, need a web server, you need a place to run the app, it’s the whole thing, right? And even if you have a very basic site, you’re kind of stuck with all that. And so what I like about these very simple projects is you have a possibility to do what I call stack fusion, based on the similar idea from algorithms of stream fusion, which is kind of looking at the whole thing and what you’re actually trying to do and like compacting it down to the minimal possible stack.

The example that I like to give is these web pages I’ve done. Where my stock is like, I open up index. HTML type, type, type, save, that’s the website, and that’s a very basic and almost contrived example, right? But it just shows how much stuff you could potentially get rid of if you are able to do this sort of stack fusion.

00:15:11 - Speaker 1: Yeah, I like that a lot.

I think one of the questions that I get about, I guess at this point, my personal infrastructure is what you call it, is, for example, authentication, you’ll ask how I do authentication because there’s no kind of authentication related code in any of the open source code that I’ve released.

And the reason is because at the app level I don’t do any authentication because all my stuff lives on a single Linux server and I just have one giant authentication layer at the top, um, at the kind of reverse proxy layer and then once any request goes through that layer for anything that needs to be authenticated, I can assume that it’s me and then I have all the permissions that I want and I like the idea of what you call fusion of just if you know. A lot about the environment that you’re deploying on who’s going to be using it and things like that. You can make a lot of assumptions that let you not need a bunch of those abstractions instead of when you kind of collect samples when you need to deploy a search engine, you don’t have to start with I’m going to start up a web crawler, I’m going to start up a database. I statically regenerate my search index every once in a while. It goes into a file, the file is loaded to the browser and then the browser does a search. I don’t need any kind of sophisticated database or ingestion algorithm or anything like that.

00:16:19 - Speaker 3: And this leads to further 3 order benefits because if you successfully do this stack fusion, you have much more ability to understand all the pieces work and you potentially have more durability, because a lot of the complexity is often to support like dynamism and change, which is a direct liability in terms of erosion of the stack. But if you have files on a Linux server, there’s fewer ways that can go wrong then a whole dynamic database is doing authentication and so on. Adam, you might be able to speak to this because I know this was a motivation for you with Broku.

00:16:50 - Speaker 2: Yeah, for sure, and the bit rot or software erosion, the idea that a piece of software that worked at one time doesn’t work anymore even though nothing changed with it, which always seems weird because a software is digital, why should it not work the same every time? And the answer is that the world changes around it.

Sometimes in small ways, you have an operating system upgrade, some things were changed and I don’t know how paths are parsed or something like that, but often in big ways, for me, one of the biggest disruptions in my personal tooling was I used to write a lot of things with little Ruby scripts that ran at the command line, that worked great when the only kind of computer I used was what we call a desktop class computer. Once the phone became a huge part of my computing life, now that doesn’t fit in, or the world has changed in a way that those pieces of software don’t fit into it as well as they once did.

But one of my motivations at Hiroku, yeah, for sure was I felt like hobby projects and interesting side projects, and even at a company, what you might call, yeah, we should talk more about the situated software label, but you often have this case where I did this at companies I worked for companies I consulted for, and you also see it often as spreadsheets or filemerro things, or whatever, but sometimes also web apps, would be something where one person would build a custom tool for just that team, whether it’s 5 people or 10 people or 20 people, and they would set it up and it would be running over time. As a web app, so often it would stop working database goes down, server needs a reboot, the file system is full, because the log rotation thing wasn’t set properly. And so one of the things we strive for with Roy was to make these more explicit contracts with the underlying system, so that you could more easily upgrade things and have the platform do a lot more of that maintenance kind of automatically, and then hopefully the app could keep running over the long term. I think there’s no perfect way to ever do that. I think we did make some good strides there in terms of reducing the likelihood of that software erosion. I’ll link out to the article we did about that.

00:18:51 - Speaker 1: Yeah, I want to also dig a little more into the kind of dynamism, ease of making changes thing because I think there’s actually two ways to look at the ease of making changes when you solve a problem with software. One way is to make the software sufficiently sophisticated, so that you can swap any arbitrary part out and you can keep making changes. The other is to make the software so simple that it’s easy to rewrite, and you can just rewrite it when the constraints change.

Yeah. And the way you do that is you make your data layer more portable, use a lot of my data is stored in.

New line to JSON, just lines of JSON packed into a single file or text files are marked on files or something like that where like basically any tool that I pull in is going to be able to talk to it or if I really need to structure something like SQL, you know, you can plug that into basically any language and it makes things like backup really easy because you just copy the file.

And things like flat dependency trees. So if you don’t depend on a lot of things, it’s easy to rebuild things and you make sure that the earth doesn’t shift under you quite as much.

If you write relatively small things that do one or two jobs only, then if the constraints change a little bit, maybe you can just modify the software a little bit, but if the world changes a lot, it’s not the end of the world and you can scrap it and rewrite it or something like that.

I try not to rewrite things too much. I try to make most of my things last a while, but I’ve rewritten some of the older pieces of the things I’ve been using the note tap and things like that, which I wrote at this 0.56 years ago. I’ve rewritten those a couple times just because the world changed and some of the packages that I used to use aged out and so it didn’t take too long.

00:20:26 - Speaker 2: Yeah, some other stuff on the durability that I think we talked about a bit before. I know, Mark, you were maybe one of the ones who opened my eyes to the value of the go and static linking, so the sort of dynamically linked libraries, whether it’s DLLs on Windows or the dotSO files on Linux. You think of it as being sort of a necessity for modern software, but go just as screw all that, it’s too complicated, it’s likely to break, now you’re like tying things together, let’s just package it all together and, you know, computers are fast and we have storage, so it’s fine.

00:20:57 - Speaker 3: Yeah, exactly, I like that aesthetic.

00:21:00 - Speaker 1: Yeah, I like go and some kind of philosophies and the tools that I used for the same reason where it’s as someone who maintains a few dozen different things that are sort of concurrently running online, it’s very difficult to think about doing that while running on an ecosystem like node. I love node, JavaScript fee, it’s great, but one of the faults it has is like every project has a million dependencies and by the time you’re done with the next project, the old projects so about a date.

And so it’s difficult to think about operating in the style of like many, many different small projects with an ecosystem like that, whereas with Go or, you know, one of the benefits of writing your own language is that the language only makes breaking changes when you decide to make breaking changes on your own terms and so using languages that prioritize long term durability of software I think helps a lot and things like static thinking, I think is a reflection of that value.

00:21:49 - Speaker 3: Yeah. And by the way, this Go discussion reminds me of a generalization of the personally built software question, which is, if you are a company or organization, should you use something off the shelf or should you build it yourself? I don’t think we want to go into that whole discussion, but I’ll just know that there are a lot of echoes in that analysis and that calculus between an individual and Corporate. And I was thinking about with Go because in the same way that people will often tell you, you should always just use a library off the shelf. I’m sure at one point everyone said, why would you ever write a programming language? Well, it turns out it was the correct thing to do. It does important things that no language had correctly brought altogether. And so I think there’s a similar dynamic playing out with personal software and with corporate choice to use libraries versus build.

00:22:34 - Speaker 1: Definitely one thing that you touched on there is the idea of like leverage and building your own tools, the various levels in the stack where at some level of like operational scale or software development scale, if in your own programming language makes sense because it gives a greater leverage over the things that make your shop easy or hard, yeah, and I think.

That doesn’t just apply at the programming language level, it also applies to your life at the tool level. So, let’s say like a lot of your work is about remembering people and keeping relationships with people, maybe designing your own CRM or context app gives you that extra leverage, or maybe if your job is about taking a lot of notes and learning a lot, building notes app for yourself actually does give you that leverage and so.

There’s a whole thing with not a hair syndrome which we don’t have to get into, but I think that’s one way to think about it is in the long term will it pay off for me to have this sort of deep understanding and control over what I use and depend on, yeah.

00:23:23 - Speaker 3: I do also think there’s another side to this, which is our now of the calculus has been very focused on the I, you know, the durability, the flexibility, the understandability, and that’s all important that goes into the calculus.

But I also think there’s an artistic element of sometimes to make a statement about how you think the world should work, the only way to do it is you just Do it all yourself top to bottom.

And I do think that comes through sometimes with these personal software projects and even some of these libraries and other software endeavors that initially seemed like a weird thing to try to go out and do. But ultimately, you see that not only are they providing ilities, but they end up making a statement about the world, which I think is cool. And I think people underestimate how important that is.

00:24:02 - Speaker 1: Yes, definitely, that reminds me of one of my favorite others sort of self-made software people is this couple of people called 100 Rabbits. I don’t know if you’ve come across them, but, oh yeah, yeah, they have a little boat, I think called the Pino, and they sail down from Vancouver down to Australia up to Japan, and they’re just open source hackers. On a boat and they also have their own sort of homebrew software stack basically from the like language virtual machine up for various things, a lot of C99 old school software things, things that don’t break things that don’t consume a lot of energy, certainly no electron apps. I think actually they’ve publicly said that running instances of Chrome is untenable for them because they only have a limited amount of energy from those solar powered things on their bone and they have to be really efficient with it. But I think that’s a great example of building your own tools or building your own software stack, not purely for the utility that it provides in your life, but as a demonstration of this is possible, or these are the values that I believe in, which I think is, as you said, also important.

00:25:04 - Speaker 2: Uh, the one that comes to mind for me on that, and these are publicly available, but a fellow named Jordan Singer has little apps. It’s just a calculator, a draw tool, browser, and these are all things that come by default on modern smartphones or whatever, but he has a particular aesthetic and a particular just kind of minimalist. Just does the littlest thing possible, hence little, and yeah, it just has a particular style to express. It’s not that those tools provide utility you can’t get elsewhere, it’s more like they express something about how their creator sees the world.

00:25:37 - Speaker 1: Speaking of little, one of the nice things about building your own thing is computers are very fast these days.

I don’t think most people realize how fast computers are these days, and the reason that software is slow is because it turns out we write a lot of code and we make computers execute a lot of code.

A modern desktop computer can run 2 to 4 billion instructions per second on a single core, and if you’re slack or if you’re whatever app takes up a second to start up, what is it doing with all those billing instructions? Like you just have to show a rectangle on the screen. It’s wild. And fortunately if you write your own thing, there’s only so many lines of code that I can pack into my little project as a single person hacking on it over a weekend, and so. By virtue of that and very little else, all my things are really fast, like my notes have loads faster than it takes for notion to start showing its spinner to load the rest of the page, and those things about building little things are also nice things like performance and sort of consistent design aesthetics and things like that you get for free.

00:26:39 - Speaker 2: Now, we’ve talked about these are sort of personal tools, personalization, you’re building for yourself, sort of your target audience of one, and that person is the same person making it.

And that also makes me think of a fellow I’ve worked with closely named Simon Kalinsky, who does a lot of personal tracking tools and things like that. He’s also a musician, and he makes a lot of music tools. I’ll link out to his portfolio, so he’s maybe in the same category as you in terms of making for himself, and that’s it.

Most of the time. But then you have something like, in a lot of my experiences with this more like situated software is often creating for a small group. It’s either a group of friends, or family, can also be obviously very much in the corporate, call it enterprise environments, you know, just a small team that has a need, and I’m thinking there of Robin Sloan’s concept of home cooked. An app can be like a home cooked meal. He’s got a little kind of messaging app for his family that he wrote about, I’ll like that in the show notes as well. So how often do you find either of you are writing when you’re doing this sort of work? Are you writing for just yourself versus a very small group?

00:27:45 - Speaker 1: Yeah, that’s an interesting question. I think in my experience, most of the things that I end up building are for just myself. Almost all my work is online just because, you know, there’s no reason to keep it to myself if other people want to look at it, yeah, and you can look at it and I like writing a little. and things like that.

00:28:02 - Speaker 2: Well, out of curiosity, what happens in that case when someone submits a bug report, a pull request, a feature request, you say, no, you got the wrong idea. This is for me, not you.

00:28:12 - Speaker 1: Or yeah, I mean, sometimes it depends.

A good example is my programming language. A lot of the reasons that I have it is, well, it’s not at all because I have this grand vision of like, I think this is how programming should work and these are the features that it shouldn’t it’s just, I did a university project once where I built like a Lip interpreter, which I think is like a common college project and I was like, oh this is cool. Maybe I should be able to build a whole language like this, and I can decide what all The keywords are, and that will be the thing or instead of saying function, because I like to keep it short. And so it’s a reflection of just my tastes for those things, if other people want to come in and kind of speak their opinions, I say things for your opinions, but this is my language you can fork it and I’ll help you fork and understand the code base, but for my thing, I want to keep it to my tastes and it’s totally fine. But for some other things, for example, I have a little Twitter client that I use, like a Twitter reader that just talks to the Twitter API but gives me my own kind of chronological timeline and a few other kind of search niceties and for things like that, other people have come along and they’ve contributed things like a Docker file for people to more easily clone it and use it on their own setting and things like that.

And sometimes, actually the. Twitter thing is really interesting because it’s designed to be sort of in one very specific way and user customizable, which is that you can add these tabs that correspond to searches instead of just having your own timeline, your home timeline is just one of the many tweet deck style, one of the many tabs that you can have open and you can have another tab that’s like people talking about tools for thought or you can have another tab that’s like Taylor Swift content or whatever because I’m a big fan. And maybe that means that other people don’t have to contribute patches or get put in pull requests because it’s like end user programmable, throwing a buzzword there, but it’s end user programmable and so in that way maybe people don’t have to modify the software itself for the thing to suit their needs. But yeah, pull requests come in if it doesn’t really change the way that I use it, I’m open to it a lot of times because it is an improvement, but if it impacts the way that I use it, then, you know. Yeah, I built it for myself, and so you can fork it, fork it, yeah.

00:30:20 - Speaker 1: Build your own version that matches your own taste, yeah, definitely, and I’m actually a huge fan of that. You can fork it and the winner will get the masses kind of approach to open source.

00:30:28 - Speaker 3: And I think by the way, that aligns well with having artistic goals because in that world, the actual code repository is not so much the output as the instigation that you’ve admitted into the world. This I think was a success of go by example, where I don’t think anyone has used the actual code base, but people have used the X by example idea and layout a lot and that’s propagated, which is great.

00:30:52 - Speaker 1: Certainly, I think this is true of Monaco as well the search engine thing where just building that, I think it’s one of those ideas where you tweet it out and then the thread is a bunch of people who are like I’ve been thinking about building a personal searching for and for the last 5 years and why haven’t you done it? It’s because there isn’t that instigator. To say this is doable and these are the ways that you could do it.

And one of the pure joy moments of building my own tools and then putting it out in the world like this is seeing other people take those ideas and either take the codebase or just take the idea and go and build their own tools because it’s really lovely to see against the kind of tsunami of these like corporate mass market tools, these little small islands of personal tools that are reflections of the maker’s values and tastes kind of come into play.

00:31:38 - Speaker 3: Yeah, I think as an empirical observation, there’s a very big step function and like difficulty and effort when you go from one person to end users, especially in our classic SAS model of client server where the server is multi-tenanted. There’s all kinds of complications. You have two code base, you have multi-tenancy, you have security, you have upgrades, you have different versions across the client, the server. It’s a whole idea.

So I think in practice that stops a lot of people and and equals one, they say, you know, just basically go fork it and do whatever you want. I do think there’s a world where this step function is decreased a lot, and this goes back to our discussion of local first software. If you can have something more like spreadsheets where you can just send someone one file, and that’s basically all they need to be able to participate in this home cooked meal, I think it could be much more successful.

In fact, we see this with spreadsheets often there’s groups of friends or groups of colleagues at a company where they’re sort of sending around or linking around or forking a spreadsheet and it sort of spreads as a meme within a company. I could see the same thing with local for software if you didn’t need a server and if all the data was either stored directly on the clients or you could bring your own server and so the originator of the software didn’t need to worry about multi-tenant hosting your data.

00:32:49 - Speaker 2: Yeah, the authentication, the identity generally, of course, is just kind of this huge unsolved problem. Throw in the multi-tenancy, you throw in the Partitioning by users, even if you leave out the security thing, assume that all your users are, yeah, friends or family members are in the same company or something like that. It just quickly gets very, very complicated compared to the, maybe the world of software that I sort of grew up in, which is something where when you write a program, maybe it saves data persists data to disk by writing a file, which is incredibly simple, as you said earlier, there, like, you can copy it, you can delete it, you have a lot of agency over it without needing to build that into the tool, the app.

And yeah, the concept of user just doesn’t really exist or it’s implicit in, for example, your local Unix user or something like that. The permissions are all handled by the operating system, the location and the file system is handled by the operating system. You just write the program, and all the rest can go around it.

That’s kind of not where we’re at.

In a way, modern operating systems, whether they be on the desktop or mobile, do way, way more, or even the web has way more APIs, way more capabilities, accessing hardware, all these different things you can do, but in a way, some of these simpler things like Just knowing who the user is, you could do that in a Unix program. There’s a who am I, you know, function, and you can kind of inherit that from the operating system or file permissions you can inherit from the operating system.

Basically, every app is reimplementing all of that from scratch in the modern world.

00:34:21 - Speaker 3: Now that we’re talking about it, I have another example.

So longtime listeners of the podcast will know that there’s often two examples we drawn. One is spreadsheets and one is games as areas that have in many ways at the frontier of computing.

So now I’m thinking about sort of situated or home cooked software in a context of games. And there I do think you see it with the like scripting and modeling community. So you have these games where there’s an existing infrastructure for players and accounts and identities and server hosting and everything, and People can contribute their own programs in the form of different skins or different map scripts. And that is very successful. So again, you just need to basically put your code, if you will, out there. People can share it around and copy it around and link it around, and that’s all you need. You don’t need to run your own map hosting server or whatever. That’s been very successful. It makes me think even more that if you could have a similar substrate in the world of personal knowledge management or more traditional SAS apps, you could see the same success.

00:35:17 - Speaker 1: Yeah, definitely, I think, Mark, what you’ve been talking about sort of made me go on a train of thought about software packaging, because a lot of this is about how do you take something that works on my computer and make it so that other people can just take it and run it and it works the same on their computer and In a similar way to what we’re kind of talking about, I think the advent of GitHub as the de facto way that people share code, I think is kind of one of those step function changes right about, yeah, instead of sending me a zip archive or sending me patches, you can just send me a link and then I can download it and include and oftentimes there’s instructions in the repo of how to run it and presumably there’s more that we can go. Down that road about instead of having to copy a whole bunch of files down and then set all these things up and things like deploy AWBS with all the scripts and stuff, maybe you can just give me a file and I can run it and it’ll just work.

And I think that, yeah, there’s a lot that we can still improve on on the packaging side, I think, for just being able to share sort of single user single instance piece of software.

00:36:11 - Speaker 2: Yeah. In a way I’m nostalgic for the Windows era of download an EXC. And run it, and I know why in the world of malware and so on, that maybe doesn’t work anymore, but there was something quite simple and elegant about it, and because Microsoft did work so hard at kind of keeping backwards compatibility in the operating system, you typically knew that, yeah, someone wrote compiled an EXC 10 years ago, and you could still run it on a Windows computer today.

And the closest thing we have to that now, or the best thing I would say, is the web, where typing a URL into your URL bar is essentially downloading and running a program on the fly in a safe sandbox, which is frankly, a miracle when I start to think about how that works, but it has these limitations of things you can’t do, it’s not personal.

If you want to do anything with, you know, it’s gonna have some kind of persistence that really needs to have a back end, and now you’re into this whole crazy world of different tools, and you need to know 5 different programming languages, just to make the most basic thing, you know, shared to do list or something work, and yeah, a world of local first apps or something where you could download a piece of software, expect to run, have it be in a security sandbox so it’s safe, but not necessarily to go through some kind of Gatekeeping review system, and then be able to do persistence and other things that you would do in the local environment, or even add in some of the collaboration side of things.

I would be very disappointed if we don’t end up in a world there sometime in the coming years, but I also don’t know the path that gets us from there because the companies with the most resources and software engineers to throw at the problem, are pretty motivated to keep their walled gardens and keep you logging into their system and keep you on their servers rather than empower local, more powerful local apps.

00:38:04 - Speaker 1: Speaking of being able to download an EXC and run it through, I think there is momentum in that direction.

I think one example that has been quite a big source of inspiration as I work on my own program language kind of tooling and ecosystem is Dano. Do you know? There’s no JS and then Dano is sort of the typescript run time, I think is the way they talk about it, but it’s all of the same underlying technology as node, but it runs.

Sort of TypeScript natively has built in Tyscript compiler and some other nice things in the language and that’s all fine, but the really interesting thing is Dano inherits kind of big focus on developer experience and toling quality from other languages like go and rust and so I think in the kind of intervening 15 years, they’ve learned a lot about how to distribute andacket software, like, a lot of the big focus of Noja was just like, let’s get a synchronous eventsa. Yeah, it’s really good. Like they got that, but everything else is kind of a mess.

And then you know, I think a lot of the right choices have been made for kind of software your ability.

So you can do things like deno compile, which gets you an executable binary, so you can write things with typescript and build it with Deno and package it up so that I can give you an EXE and you can run it on any Linux thing, right? And I think things like that sort of being built into the language tool chain are pushing us. I think in the right direction.

The other thing that Dano does that’s really interesting is instead of having a package registry, the packages that you can import are just kind of URLs and so you say import X from this URL string and it’ll download and cache that thing at that URL, but then there’s no intermediator that has to be up all the time or that has to be correct all the time, you’re just downloading things from the web, which I think is about as futureproof as you could get.

00:39:39 - Speaker 2: Yeah, another interesting thing about Teno, and that’s a smaller point, but I think it’s an important one, which is this sandboxing thing is so important for making it possible to, I can give my friend a piece of software that I’ve written, and they can just run it, and we don’t need to go through some onerous review process, but we obviously also need to protect from the now huge world of malware, and so sandboxing, and good sandboxing is a potential technical solution to at least some elements of that.

And the browser obviously does an incredible job at that, but if you want to run a command line program, no, the demo actually does a lot of that, where by default, any demo program you run at the command line has no permissions essentially to the core operating system, but you can pass.

It switches to say, I wanted to be able to, for example, make an outbound HTTP request to this host, or I want to give it full network access or something like that.

So you have a lot of that kind of control that I associate with, for example, cueSOS. So that sandboxing gives you a lot of control over the individual programs, how they’re accessing the network or the file system, that sort of thing, while at the same time just giving you the incredible simplicity, which I still love that you had from Ruby and Python, and of course, Go and Rust nowadays, and leading back to the C days, which is, you just have the file and you type, run this file at the command line or you double click it, or whatever it is. The thing just runs, and you compare that to, you know, what it takes to sort of run a web app, particularly a database back web app, that’s just incredible simplicity that I think can do the job in a lot of cases, especially for these kind of self-made or situated apps.

00:41:15 - Speaker 1: Yeah, actually, one thing that people say around software packaging is that the modern analog of the EXC is like the Docker container, and I think sort of aspirationally that’s in the right direction where instead of having a single battery that you can run a Docker is sort of the representation of a thing that you can put in a machine and it’ll run and if you need an entire system set up then you can have. Whatever confirmation YAL or whatever, you can just throw it to a cloud provider and it’ll spin up the whole thing. And I think that’s aspirational in the right direction, like that’s where we want to get to and I think if the dreams are fulfilled, that’s that’s a really interesting world where you can, you know, give your friend a confirmation YAL and they’ll just spin up their own little thing. But in practice, just quality of experience wise, it’s much easier to execute an EC than to throw it up on a web service. Maybe there’s a gap that we can fill there. But yeah, it’s interesting to think about sort of in this world of having a backend service and databases and then users and things like that in a web app, what that equivalent to executing the binary experience looks like.

00:42:16 - Speaker 2: I think in my ideal world you would somehow put together, I guess the client side version of the Docker cubeSOS virtualization sandbox thing would be, imagine a launch an application launch screen that’s like the iPad home screen.

Basically, I could drop a Docker file essentially on there and become an app icon, and when I tap the app icon, it fetches whatever it needs to fetch to run it, spins up a virtual machine and runs it, and gives it to the computer full screen until I exit.

Something like that that just makes it very, very easy, in fact, standard, totally standardized to just spin it a virtual machine and run it. And maybe there’s a server side. version of that as well and certainly some I think platform services have attempted this, certainly some we have services have stats at this, something where you really do just have maybe Hiokku, the Hioku button was the equivalent of that drop a little link onto your GitHub read me and you click this button and it kind of spins you up a virtual instance of whatever this application is. So we’ve had some good stabs at it to try to at least package up the complexity, if not remove it or simplify it. We haven’t quite maybe got that perfect. There’s still no .exe equivalent basically. Yeah.

00:43:27 - Speaker 3: Yeah, and I think there’s a couple of things missing here. I think on the one hand, there’s additional platform primitives that are needed for things like identity and data if you’re really gonna do this without having your whole full blown client server thing, which is necessarily a lot of hassle.

But also these things like Docker and virtualization and so forth, they are sort of the opposite of Stack fusion. It’s like we’re gonna run any stack you want, you know, any language, you know, 10,000 files in your node modules or whatever, you know, go for it. And that’s awesome because it gives you a way to better manage all its existing complexity that’s out in the world.

A lot people needn’t want that, but it might be that if You want a really nice double click experience that you need to do a bunch of stack fusion and say, OK, these are the APIs. They’re much, much narrower than all our stuff.

Maybe it’s only one programming language. Maybe you don’t have your full suite of wild just calls or whatever. Maybe you can’t contact any address in the network, you know, you figure out what’s a very narrow interface, but by accepting that narrowness, accepting that fusion, you can give a much more powerful experience to the Home Cook app developer.

00:44:26 - Speaker 1: Yeah, one thing that’s come to mind is we have this conversation is the metaphor of the app as a thing that you can hold and move around as opposed to a thing that you install on a system.

I used to be a Windows user and then these days I kind of use Mac and Linux and one of the really interesting things with the Macs, like, not the underlying software model of applications installed the system, but just the end user model of how the Mac works with applications is that there’s like a dot app file.

And there’s like the safari. app and that’s the safari app and if you want to get rid of it, you just take that file and you move it to the trash. And if you want to open it, you just open it, you can move it to a different part of the folder or something like that, compared to in Windows, for example, where you have an installer.

00:45:09 - Speaker 1: I mean you can have an EXC too, but and it’s just spraying files everywhere like messes with the registry and like put some weird stuff in weird places that can do a bunch of stuff to your computer and yeah, I’m just realizing how clean and that’s just so much more and user friendly the Mac model is of here’s a thing you can click on it to run it and it’ll do the thing that you expect and if you don’t like it, you can get rid of it as opposed to like, it’s now fused with the operating system, you can never remove it completely.

00:45:32 - Speaker 2: And I do think that, you know, mobile operating systems do that even better, and they even package the data with it, so it sort of all goes together. When I delete it, it’s deleted, that’s it, it’s gone.

Now, of course, mobile restricts you and limits you in so many other ways.

That basic idea of, first of all, the user’s mental model, I think of, OK, an application, I’ve installed it, or I have it now, and it’s a tile on my home screen until I decide I don’t want it anymore, and then I press it and tap delete and the tile goes away, and there’s this 1 to 1 association between the icon that lives in a particular place in this mildly spatial interface.

The application code and data, and then I can basically manipulate it as one unit. And that’s where I certainly feel like there’s a very big lost opportunity for end user programming system customizability, whatever, particularly on the iPad, where I guess you can make shortcuts and stuff like that, but again, because of the review process, because of the heavyweight tooling doesn’t even run on that same platform. The idea of, yeah, you know, I’d love everyone to do a little apps style thing on their iPad, you know, they’re making it themselves in place, and they type up their little program and they turn it into a tile that’s on their home screen, and data gets stored there, and if they wanna send it to someone else, they can, if they wanna move it to another device, they can, if they want to delete it, they can. I think there’s something very powerful about the simplicity of that model, but then we haven’t quite connected that together with the more programmability side of the equation.

00:47:03 - Speaker 1: Right? I mean, it goes back to what Mark was saying about to have that quality of experience of stack fusion, you need some constraints, and I guess I’s platform is providing some of those constraints so that you can have that simplicity, just better API contracts for the era.

Another example more on the website that comes to mind is Relate. Which I’m a little biased because I worked there for a little bit, but one of the things that you can do with a rep, a repel is a running environment, right? It’s like code plus an execution environment, and you can click a button and the software and it’s not perfect. There’s some bit rod for like old things won’t run because like some MPM package has gone out of date or something, but by and large, the promise of it is a repel is like that, that packaged up thing. With all the configuration, there’s a little database that you can talk to inside of Apple and things like that, and you hit run, and if you see someone else that has the thing that you want to run, you can fork it, put it into your own account, and then you can hit run and now you have your own running instance. And maybe the right solution kind of looks like that where you just abstract the whole thing, even at a higher level than like a docker container or a Docker file and you just say, here’s an environment plus some code, and you can look inside if you want, but really it’s just a click run and it runs kind of experience.

00:48:15 - Speaker 2: Yeah, definitely put Repole in the same continuum of, I don’t know if they think of themselves as a kind of platform of service or serverless kind of environment, but I think it is in the same continuum with Roku, for example, and the idea of, yeah, wrapping it all up and then putting it on the web, which there’s pros and cons to essentially running it on someone else’s computer, but certainly for the use case of learning and getting started, I think that’s sort of a no-brainer, and of course over time that is becoming more and more.

Powerful. Yeah, that also makes me think of Code pen, which obviously is a much simpler use case because it’s just some CSS and JavaScript, it’s all client side, etc. but it has a lot of that vibe and it creates a lot of that sharing dynamic, which is you search on there for, you know, find me a pen for, I don’t know, doing parallax scrolling with a whatever, whatever, you find a couple of good examples, you find the one you want, you fork it, you make some changes. Maybe that has a little bit of some of the same vibe of the skinning modding gaming community you talked about earlier there, Mark.

00:49:13 - Speaker 1: Yeah, exactly. And then once you have something like replic containers or environments that you can spin up and sort of give to people, then it’s really interesting to think about, well, what does an app store that’s built on that model look like, where instead of downloading things to your machine and running it there, you have sort of web software. Where there’s like a ret store or whatever and instead of downloading a to do app you hit run and it clones that thing to your account and then it spins up a little bit of backing code and a little bit of client code and you have your own web app but it’s running just with your account and just with your data and you can look at your data and you own all of that.

Stuff until you have the cloud provider, but that I think is also really interesting to think about where you have sort of single user web apps and a way to distribute them, and then you can get people to have their little cloud environment with their little web apps, instead of having your own computer, you just have your own little cloud garden of things. That sounds amazing.

The last interesting thing that I wanted to touch on was the idea of transparency in the transparency down the stack and down your tool. One thing that I found that’s really kind of gratifying is my own tools, especially not just at the top but down to the language layer, is just being able to understand what’s happening.

I think if you use a tool like notion, which I think is great, but it’s very opaque. I type something in and it shows up on screen and I load that same page up on a different computer and it shows up on screen, but I have no idea how they’re saving it, how they’re transforming it, where it’s going, who owns it, whether it’s in another continent, and that’s nice in one way that it’s packaged and kind of hidden away, but building my own tools, I think an interesting benefit has been when I type a character in or hit save, I know exactly where the bits are going. I know almost down to the CPU instruction, what’s happening with that data. And I think that going back to the first thing that I mentioned, it changes the relationship that you have with your software where it’s there’s kind of a power dynamic where if you don’t know what the company that’s providing you some software products is doing with your data, or what’s happening behind the scenes, they kind of have the power and you’re paying them so they let you use the thing, whereas if you build your own thing, you understand exactly what’s going on that you’re in control and you can understand. Even just the concept of like, the things that you use to run your day to day life, you have the power to understand fully, I think is kind of a radical idea.

00:51:29 - Speaker 2: It comes back to this agency and this sense of, yeah, as we live in a world where there’s more and more complexity to the technology and it becomes indistinguishable from magic, and that’s good in the sense that magic is great and powers more and more things in our lives, but then it’s bad in the sense that we lose that understanding of it that actually is important in the long run.

I feel there may have been a, it’s a Star Trek The Next Generation episode where they encounter, and if there were some humans or an alien race, I can’t remember where, kind of they had forgotten how to service the technology or how it worked, you know, in generations past, because it works so well and it’s kind of self-maintaining and that sort of thing, but then the whole civilization was in a state of Not decay, but let’s call it stasis or mild decay as a result of this, I kind of explored philosophically that concept which that shows was very good at doing.

00:52:25 - Speaker 1: Yeah, maybe maybe we’re not so far away from that kind of thing where there’s another exec CD of like, you know, all of modern software depends on this one little piece that’s maintained by some lonesome developer in the middle of nowhere Arkansas or something. Yeah, these things are hugely complex and there’s a lot of parts that are sort of under service.

My favorite variation of that joke is in the tools without space. One of the table stakes thing that you have to build when you build like a note taking or knowledge management app is you need a good rich text editing experience to be able to do things like bullet lists and things like that and basically.

Everybody that I know uses this library called Prosemir, which is amazing and excellent and really well designed, and also quite complex just conceptually, and it’s just this one dude, Maran working on the library, and he’s like holding up an entire kind of burgeoning venture backed industry, which is sort of frightening and interesting to think about.

00:53:18 - Speaker 2: was a place to end. I thought it’d be interesting to talk about software as kind of an ever evolving thing versus something that you finish.

We talked about this in the filmmaking podcast with Max Bacht where he basically said films, you finish it, it’s printed, that’s it, it’s done. You don’t get. iterate on it, any feedback you get and you think, oh man, I should have done that differently. Too bad, you know, if it’s a TV series, you could incorporated the next season or whatever.

And I’ve also tweeted about kind of this is part of why the subscription model actually does make sense for software is that it’s sort of never done. The tweet that I quoted there was the curl maintainer speaking a little bit about the 23 years he spent working on that piece of software, and it’s still very active, new features, bug fixes for what’s basically a very simple tool. So, how do you see that, especially in the context of self-made tools where you can’t maintain them full time, particularly if you have a whole suite of them, how much can you build them as something that’s finished versus now you’ve created for yourself a huge open-ended maintenance job?

00:54:22 - Speaker 1: Right, right, I think this goes back to what I spoke on earlier around if you have a software product that is in the line of business for some company or that a lot of people depend on like Curl is a great example where it does nominally does one thing, which is talk to some server on the web, but it’s used like virtually every piece of electronics out there, but like, I’m sure my car, I don’t have a car, but if I had a car, my car would use it in my fridge probably uses it or something like that.

And in those things where these things sort of grow in an unbounded way just because of user needs changing and the world changing.

I think it’s difficult to be done with software and I’m sure most my side projects if I really think about it, if you know something about Linux changed or something about the HTP protocol changed or something like that, I have to rebuild it occasionally and fix some bugs, but by and large I think the benefit of having a single user and a very constrained well defined use case is that you can kind of be done with software, like at least a single piece of software.

Like my notes app, it does a very constrained set of things. I can write some text in it in a markdown format. I can save it. I can load it up and look at another device, and maybe there’s some things that I want to add to it and occasionally I can go back and add to it, but when I initially came up with that, I had a set of things that I wanted to do with it, and it does those things and I’ve mostly been fine with it, and it’s sort of done until something breaks, and I think if you build on stable foundations, as we talked about like go and The Linux user space and things like that, things don’t break as much.

So I think in that way when you constrain those things a lot and kind of build for yourself, I do think it’s possible to finish a piece of software.

00:55:55 - Speaker 3: Yeah, I feel like in today’s world it needs to be a very deliberate act to create software that you expect to be finished because of the political economy, the software ecosystem, if you kind of write down what Google or Stack Overflow tells you to do, this thing is not gonna last a year before you have some package update advisory or something.

But you can, if you are very deliberate, build it in a way such that it might last 35, even 10 years before it needs serious operations.

Again, it kind of comes back to the idea of artistic software and today even saying I want this thing to be running in 10 years without me being heavily involved with it is a major artistic statement to make.

00:56:31 - Speaker 1: Right. Another thing that plays into this I think is also building many small things versus a single large thing.

At this point, you know, I have a whole suite of these things I’ve no top CRMs and. Twitter clients and whatever, and they’re all quite independent.

Some of them rely on the same kinds of languages and frameworks and things like that.

Like if one goes down, it doesn’t matter for the other ones. And if you structure your sort of software ecosystem like that, then it’s possible to like finish one piece and then if it needs to be improved and you can just replace that piece and that way the whole system is kind of evolving continuously as the world changes.

Maybe I need, you know, but no. or context app that functions differently, but each little atom of that ecosystem is sort of finished, which I think just as a matter of fact like a person working on these things while holding a full-time job is also kind of a necessity because being able to chunk these things up to atoms means that you can fit it into weekends, you can fit it into these little breaks rather than having to work on them continuously. It’s just a good conceptual model to work on these as well, to have.

An ecosystem of these atoms rather than a single sprawling kind of software grid.

00:57:39 - Speaker 2: Let’s wrap it there. Thanks everyone for listening. If you have feedback, write us on Twitter at EAHQ or on email, hello at newsapp.com, and it helps us if you leave a review on Apple Podcasts. So Linus, thank you so much for being a role model, inspiring us to maybe creating that spark or that sense of it’s doable for the thing we all want to do, whether it’s that personal CRM or personal search tool, and I look forward to continuing to read your posts about whatever you’re making next.

00:58:09 - Speaker 1: Thank you. Thanks for having me on the show.