The Changelog: Software Development, Open Source - Building software for yourself (Interview)

Episode Date: August 23, 2021

Today we're talking to Linus Lee about the practice of building software for yourself. Linus has several side projects we could talk about, but today's show is focused on Linus' dynamically typed functional programming language called Ink that he used to write his full text personal search engine called Monocle. Linus is focused on writing software that solves his own needs, all of which is open source, to help him learn more deeply and organize the knowledge of his life.

What's up? Welcome back. I'm Adam Stachowiak, and you are listening to The Change Log. On this show, Jared and I talk with the hackers, leaders, and the innovators from all areas of the software world. We face our imposter syndrome, so you don't have to. Today, we're talking with Linus Lee about the practice of building software for yourself. Linus has several side projects we can talk about, but today's show is focused on Linus' dynamically typed, functional programming language called Ink that he used to write his full-text personal search engine called Monocle. Linus is focused on writing software that solves his own needs, all of which is open source, to help him learn more deeply and organize the knowledge of his life. Today, we dig into all that. Big thanks to our partners Linodely, and LaunchDarkly.

We love Linode. They keep it fast and simple. Get $100 in credit at linode.com slash changelog. Our bandwidth is provided by Fastly. Learn more at fastly.com. And get your feature flags, Powered by LaunchDarkly. Get a demo at launchdarkly.com. This episode is brought to you by Gitpod. Gitpod lets you spin up fresh, ephemeral, automated dev environments in the cloud in seconds. And I'm here with Johannes Landgraf, co-founder of Gitpod.

Johannes, you recently opened up your free tier to every developer with a GitLab, GitHub, or Bitbucket account. What are your goals with that? Thanks, Adam. As you know, everything we do at Gitpod centers around eliminating friction from the workflow of developers. We work towards a future where ephemeral cloud-based development environments are the standard in modern engineering teams.

Just think about it. It's 2021 and we use automation everywhere. We automate infrastructure, CI-CD build pipelines, and even writing code. The only thing we have not automated are developer environments. They are still brittle, tied to local machines and a constant source of friction during onboarding and ongoing development.

With Gitpod, this stops. Our free plan gives devs access to cloud-based developer environments for 50 hours per month. Companies such as Google, Facebook, and most recently GitHub have internally built solutions and moved software development to the cloud. I know I'm biased, but I can fully relate. Once you experience the productivity boost and peace of mind that automation offers, you never want to go back. Gitpod is open source and with our free tier, we want to make cloud-based development available for everyone. Very cool. All right, if this gets you excited, learn more and get started for free at getpod.io.

Again, getpod.io. So we're joined by linus lee you may know him as thesophist or t-h-e-s-e-p-h-i-s-t i think it's thesophist linus how do you say that the sephist as in the english article and then sephist the sephist i might submit to you an underscore or maybe a hyphen. Take out the ambiguity. I like to keep the symbols out of the word. Just keep it. And there's some fun in the ambiguity. That is true.

What is a Cephas? I don't even know what that is. When I was much younger in high school, I was very into linguistics. And at one point, I took on this kind of fun type project of trying to invent myself my own language. So the word Cephasist means something in that language. The exact meaning, I'll keep off the record.

Nothing shady, just fun. Mysterious. Yeah, I'll keep the mystery, but it's just a word from that language. And actually it's funny because since then I've gotten into programming languages and other kinds of languages. But yeah, it's a remnant of that. And then it's a unique enough handle that no one else has taken it in any social media sites, so I'm just going to keep on with it. a remnant of that. And then it's a unique enough handle that no one else has taken it in any social media sites.

So I just keep on with it. That is nice to have. So I found you by way of Monocle, which is your personal universal search engine. And when I found that, I was reading about it and you said, this is written in ink. And I was like, what's ink? And it's your own programming language.

And then you have your own UI framework. I started to check you out a little bit more, and you just have all these side projects. Tons of side projects. Tell us about, first of all, before we get into the particulars of these projects, Inc. is very interesting. I think Monocle is very interesting as well. What's up with all the side projects, man? It's how I learn to program, and it's still how I learn new things. I think the way that I think about side projects is kind of how I, it's how I learned to program and it's still kind of how I learn new things. I think the way that I think about side projects is pretty different from sort of the way most people or like the hackathon crowd or like the industry likes to think about side projects.

My side projects are never really monetized. They're not, they're not really for other people. I just kind of make them for me to use it myself. Even the language is mostly for myself, I make them to learn about something, to understand how something works. Like I've built assemblers and compilers before to understand how those things work

as kind of learning tools. Often I'll build them to fill a need that I have in my life, like note-taking apps or things like that. And I try to keep them pretty small and tight scoped. So I make them in a few days and just kind of maintain them over time and once you do that over you know kind of over and over over a few years you accumulate a lot of them and so i think there's 120 something on the big list on my website now but um a lot of

them are still running a lot of them i use day-to-day personally as opposed to being sort of side hustles or anything like that so So do you have a primary hustle? Do you not need a side hustle? I have a primary hustle. I work at a company called Ideaflow, one of the companies building tools for thought. As they say, no taking out that tries to be a lot smarter without being a lot more complicated. Okay. So the side projects usually come out of or intertwine what you're thinking of during

your nine to five, or are they usually completely separate things? Because it seems like tools for thought, as we get into monocles, kind of related to that to a certain degree. They are related. The causality actually goes backwards. So I actually, I'm fortunate, I'd say, to try to run into people and find companies

I could work at where I can still think about the things that I'm interested in during my day job. But my general interest is in building better tools, better creative tools, better thinking tools, community and things like that. And so I tend to gravitate towards other people working on those things. But my side projects are where those interests start. In your day job, do you get to do a lot of the same things? Is there any crossover in terms of when you do things for yourself, it crossover in terms of like, you know, when you do things for yourself,

it's a lot of autonomy, right? You can do things that you want to do. Yeah, definitely. Whereas maybe in a day job you sort of have to concern yourself

with the revenue or customers. There's quite a bit of crossover. I'd say there's actually a lot of knowledge transfer. So a lot of the things that I've been messing

around with on my side projects around search and sort of semantically grouping ideas together and surfacing them, a lot of those things carry over into building a better note-taking app. And so I'll sometimes use side projects as kind of a way to sort of consequence-free

experiment with these ideas and then bring some of them to the table at work and be like, hey, maybe we can bring some of these elements to the thing that we're making for other people. One of the cons of my side projects is I don't really put a lot of effort into making them usable for other people. And other people always complain about it. They're like, why isn't there a commercial version? So I try to bring some of those ideas over when I can. And sometimes when I can do that, it's great. But it's not a must.

Do you think your side projects will always be make for yourself? Or do you think you'll eventually get to a point where it's like, you know what, I've made this for myself and I can see the usefulness to other people and you sort of maybe begin the true side hustle. True side hustle. Well, you said you're not doing it right. Yeah, yeah.

I don't think I'll really ever turn any of them into jobs per se. I mean, the thing that I really like about the way that I do my side projects is I have no obligation to any of them. I build something and if I grow out of it or if I build the next version, I can just scrap the old one. I can literally just shut it down on my server and never touch it again.

And if there's a bug or something weird that's happening that I never hit, I don't have to worry about it again. And that kind of stuff is really liberating for just being able to iterate quickly and build stuff and experiment without a lot of consequences. Once you start running a service for other people, one, it turns into a job where you have to listen to other people and what they want. And two, there's a lot of consequences. Once you start running a service for other people, one, it turns into a job where you have to listen to other people and what they want.

And two, there's a lot more liability. You have to be liable for their data, for their security. And I think that then it starts turning into a job. Maybe I'll turn one of my projects into a job, but then it'll definitely be a job and it won't be a side project. And I think there's a pretty clear boundary for me where inside projects there's a lot of freedom

for me to build what I want and experiment and importantly, underratedly, to be able to shut things down and change things when I think they should change. Yeah, that's pretty liberating for sure because you're in full control if it's like, you know what, I'm just sort of done with that thing or that bug doesn't matter to me. You can literally never pay attention to it again and it won't upset anybody. Yeah, and I think there's also a lot of shortcuts

you can take when you build a tool just for yourself as opposed to for everybody. The way on how you store your data, how you make some things scalable or not scalable and not having to worry about those things, how you do authentication, things like that. You can kind of duct tape things together nicely, but duct tape things together

as opposed to having the perfect solution. And I think that also makes it very easy to build a lot more things a lot more quickly. Yeah, I have a lot of code that never leaves my hard disk. It's not for other people. I just wrote it. I don't want it to scale. I don't want to refactor it so that it's a nice example of code. But it scratches my itch, and I'm fine with that. So the question for me becomes, for you, why publish then?

Why not just keep them to yourself? Yeah, that's a good question. me becomes for you, why publish then? Why not just keep them to yourself? Yeah, that's a good question. I mean, for a few reasons. I think that the main one that's come to mind more recently, even if other people can't use the code directly, I think a lot of the effects of me publishing my code is other people looking at it and either seeing that something that they thought was complicated is actually not that complicated. Like, so Inc., the programming language, which we can talk about more later,

that's actually only a few thousand lines of pretty readable Go. And I think programming languages and compilers is one of those things where people look at the general kind of space and say, oh, that's way too complicated, I can't possibly understand all of it. And it is complicated, but I think one of the things I started learning when I started building tools like that is, if you actually study it, it's logical. You can follow it. These are understandable things. And I think one of the benefits of putting it out there is for other people to look at it and kind of have the same realization.

Of course, these things are actually, you can build them. Anyone who can code can build them. I think the other effect that it has is to get people to build little things of their own, especially since I can't make them available for everyone to use. A lot of people will come to me and say, oh, I looked at what you built and it inspired me to go build a clone of it

or a similar kind of thing that scratches a similar itch in my life myself. And I think that's really cool. Well, let's dive into Ink since you teed it up. Let's hit the ball off the tee here. It's your personal programming language inspired by Go, JavaScript, and Lua. it up, let's hit the ball off the tee here. It's your personal programming language, inspired by Go, JavaScript, and Lua.

My first question is, I think you've already answered this, but maybe I'll give you another chance. Why not just use Go, JavaScript, or Lua? You apparently like those languages. You have a language inspired by it. Why put all the work in? You wrote a language in Go, you could have just wrote

your tools in Go. You could ask the same thing about every one of my side projects. Why build anything the work in? I mean, you wrote a language in Go, you could have just wrote your tools in Go. Yes, I mean, so you could ask the same thing about every one of my side projects. Why build anything then, right? The story of how it came about, I was taking one of the introductory kind of computer science courses at my university, and one of the really fun projects we got to do at the end of the semester

was build a really simple Lisp interpreter, which is kind of a pretty common undergrad kind of CS project. And it was one of those things where they had 80% of the code templated and you fill in the blanks and fill in the few functions to make it work. But I got to see the internals of a pretty real programming language working on my computer that I could type code into, and it would do things that I told it to do. And that was really interesting because I hadn't thought of programming language and interpreters before as something

that I could understand and mess with and play with. But here I was making this project work. That project was pretty, there was a lot of hand-holding and I only filled in the blanks, but that inspired me to then build on top of it and say, hey, what if I could build a language completely from the ground up

that worked in a similar way? And I think everyone at the start of their career sort of has this wish of like, oh, you know, I really like this language, but if I could only change this bit of syntax, or if I could only change this thing that I don't like. And so I basically took all those complaints that I had about all these languages that I liked and tried to build something that I think looked kind of nice and worked kind of nicely and wasn't too complicated. And so I started hacking on it, and it eventually turned into something that worked. And then once it worked,

I started using it to build little programs like a Mandelbrot set renderer or a game or things like that. And then it eventually sort of ballooned into, well, if you start writing programs in it, you need like a syntax highlighter because otherwise it's difficult. So you write a syntax highlighter

and then you write like a code formatter and then you're like, oh, I want to run my encode in the browser. So you write like a compiler and then it sort of balloons from there. But all of it was very iterative. I realized that I could do this thing, and I built a small version and then added onto it. And now I'm here. But it wasn't really anything calculated from the start. It wasn't even really designed to build projects, and I just kind of built it because I thought it was cool to be able to

build a language. How far back does Ink go then? So how many iterations, how many years or months? So I built it the summer of 2019. So it's been a little over two years. The language itself, I think, took a couple months on and off to build. And then after that, all of it is just all the rest of the efforts just adding to the ecosystem, the one man ecosystem. And you never intend for anybody else to use ink. They could use it, but you're not designing it. You're not doing it for the consumption of others.

Jared might be able to use it, or somebody else might be able to use it, but you're not trying to make it be useful to others. Yeah, that's not really a goal. Because it was my first programming language project, and I was a wee lad, there's a lot of little design mistakes and regrets that are now baked into the language and baked into these projects and code bases and can't make a lot of breaking changes

because I like to keep those projects working. Partly for that and partly because I don't think it's a great language. It's my baby, so I use it. If someone's like, is Ink better or JavaScript better? I'm like, clearly JavaScript is a better language. I use it because I like using it. But if other people use it,

and some people use it to build little things, I think that's great, and I'm super happy to see that whenever that happens. But I don't put pressure on myself to make it something that other people can use. What if they start using it? What if they start opening up feature requests and bug reports, and I love this thing,

and I built this little startup on it. That would be a nightmare. Do not build a startup on it. My startup is doing great, but I just can't get Ink to do X, Y, or Z. Yeah, I mean, that would be pretty crazy. I mean, you do so at your own risk. And if you run into problems, if people run into problems, I try to be helpful and point them to the right resources

or help them make a patch or something. And if you're into problems, if people run into problems, I try to be helpful and point them to the right resources or help them make a patch or something. And if you're running a startup on Ink and you're not completely crazy, talk to me. But yeah, you just take your own risk. And this is with any of my side projects. I have a couple of other projects that people have rolled their own versions of. I have a Twitter client, I have a search engine that people have tried to spin up. I'm always excited to get other people to help them out, to get them spun up for their own data or for their own accounts, but I don't really ever put pressure on myself to make it work for them. I help them out when I can. I'm super excited for people to contribute back Docker files and other things

to help other people get set up. So tell us about the language. You designed this thing, you pulled in parts from other languages that you like. How is it like JavaScript? How is it like Go? How is it like Lua? Just some of the aspects of this language that you designed. Yeah, so I would say syntactically it's pretty close to JavaScript. It's sort of arrow functions

and primitive values without classes and prototype inheritance. If those words mean things to you. So there's no inheritance then? There's no inheritance. It's very lispy, actually. So there's functions and there's prunative values and there's objects, and that's about it. It's also kind of a lot like Lua in that way. It's very simple. And the reason for the simplicity is not anything ideological. It was just like, I didn't know how to implement inheritance when I built Ink, so it's not there.

Same thing with a lot of other features around clever optimizations and things like that. A lot of it, it's simple, because I had to build the simplest thing. I didn't want to spend extra time learning how to do inheritance and operator overloading and things like that. Are there any other code reuse mechanisms aside from a function? Are there other ways?

Are there mixins or modules or any way you could get shared utility without? Not really. It's really functions and objects. And I think that actually takes you pretty far. I remember before JavaScript got all these fancy features, you had functions and objects that you could attach. You had kind of an inheritance thing,

but really just had functions and objects. You could do a lot with it. And I think one of the things that writing a lot of in-code has made me appreciate is that you can actually, a lot of clean code isn't about using a lot of these fancy abstractions. It's just structuring your functions and objects and basic data flow to make sense to be simple. And if you do that, you can still write pretty clean code. So what about tooling for ink? Surely Monocle has some sort of storage engine or a place that you put your data.

It's a universal knowledge base kind of a thing. So does Ink have, how does it interact with the world? Does it have database hooks or file system hooks? Built into the interpreter, there's a couple different ways the language can talk to the outside world. There's a file system kind of interface. There's a basic sort of HTTP networking interface and things like that to be able to run servers and save files. There isn't a database driver

or anything like that. I've thought about building something like it, but Monocle and a lot of other apps that I use, I mean, one of the things about building personal tools is the scale of data is so small and the computers these days are so fast that you can kind of store things in like normal files. All of Monocle's search data lives inside a big 50 megabyte JSON. It's kind of large for JSON, but it can totally chew through it and be pretty quick with it. And so I wrote a little JSON parser and serializer in Ink, and it's like 50 lines of Ink code.

And I use that to do most of data storage. So I love that you're still using ink to this day, even though, like you said, you have regrets. It's a bit of a pet project or a toy project. A lot of people will try to advance in their programming skills in languages that are viable, for lack of a better word. I'm investing in the Python community, or I'm investing in go my personal time

i'm not saying i jared but these are like the way people think do you have any concern that you're you're spending your years writing a language that only you use and maybe you could be getting better maybe you could be getting better at javascript or maybe you could be getting better at other things yeah nobody's gonna hire me to write in code for their company right i haven't really ever thought about i mean so the main reason that I haven't thought about it is because at my day job, I write React-type scripts, which is quite popular. And that's going to put the food on the table. Over time, I think this is a general kind of software engineering realization,

but certainly I've realized most of the hard parts of programming isn't learning how to use a particular language. It's learning how to, it's going to sound a little cliche, but it's learning how to organize abstractions and deal with complexity. And I think a lot of that isn't actually on the keyboard. It's actually in your mind. It's like, where do you put things? How do you group things together? How do you know when abstractions are too large or too small? And I think a lot of those skills transfer over to any language that you use. The other reason it hasn't really concerned me is that a lot of those skills kind of transfer over to any language that you use. The other sort of reason it hasn't really concerned me is that a lot of the projects that I've built with Ink are sort of

learning projects. So I built an assembler with Ink to learn how kind of assembly and linking worked. The code there isn't super reusable in other projects, but a lot of that knowledge is reusable. Like if someone told me to make an assembler now, I can carry over that extra knowledge. I built a full-text search engine in Ink, and a lot of that knowledge about how a full-text search system works, I can carry over even if the code isn't reusable. So I think there's a lot more transferable knowledge in building these things than you realize.

You're still showing up to practice. Even if you're not throwing a football, you may be just doing drills, you're running, you understand the philosophy. I'm just using football as an example here, but you're still showing up to practice basically. Yeah, or even if you're not using a football, throwing something. Right. You're still involved in the process

and the practice of maybe doing things that excel at programming, but not necessarily like the Jair's question was, why not use Go or JavaScript that is a viable project? Your knowledge, as you said, still carries over, which I think is pretty interesting.

What about your editor of choice? Did you have to do anything special to code in Vim or code in VS Code or whatever you've chosen? What did you choose? What kind of specifics did you have to do to make it syntax-halable? How is coding in Ink different in your editor? Yeah, so there's actually quite a bit

of personal infrastructure associated with building Ink projects. And this is probably my favorite thing in your editor? Yeah, so there's actually quite a bit of personal infrastructure associated with building Ink projects. And this is probably my favorite thing to talk about with Ink because I think it's so sort of math science-y. So my editor of choice is Vim. And I keep it pretty bare-bones, pretty simple. Not a lot of plugins, just sort of basic color themes and little helpers here and there to work with Git.

And the only really Vim thing that I have for Ink is a syntax highlighter, just to be able to read my code a little better. And I can do sort of like code folding within functions and things like that to like collapse functions down to one line. And beyond that, I don't have a lot in Vim itself. I'm pretty proficient with Vim,

so I can move around my code easily. It's fast, it's simple, it works. Outside of Vim though, I have quite a bit of tooling. So I have InkFormat or InkFumpt, depending on how you say it. That's a code formatter for Ink. So once in a while, I have quite a bit of tooling. So I have InkFormat or InkFoamt, depending on how you say it. That's a code formatter for Ink. So once in a while I'll save the code, I'll run the code formatter over it, and it'll format all my Ink code for me so I don't have to have anything special in Vim to do it

around auto-indent or things like that. Wait a second, wait a second. You're the only one that writes Ink. I mean, isn't just however you write it, that's the format, isn't it? It is, but you want your code to... What if he changes it? He iterates his day-to-day. He can always have the...

I love this. You have a formatter tool for yourself. So actually, this is one of the rough edges, is Vim's auto-indent strategy doesn't understand ink syntax. So frequently it'll mess up. And I don't want to have to manually go and untab and tab all these things.

So I just write kind of messy code around the formatter, and then it's pristine again. And it helps with all the standard benefits that apply to code formatters around standard formatting and automating code rewrites and refactors and things like that. I think a lot of them still apply here. So it's a little overkill, but it's actually really, really nice. So there's ink format. There's also color pre-printed printers. I actually also have a proxy on top of GitHub

that'll syntax highlight ink code called Ken. That's because to add your language to GitHub's registry of languages that knows how to syntax highlight in its interface, one of the requirements is that it has to be reasonably popular. Ink is not reasonably popular. It's very unpopular. But I wanted to read syntax highlighted code

without having to open it up in Vim. And so I wrote a little proxy in front of GitHub's files where if it recognizes an Ink file, it'll run my syntax highlighter, which is also written in Ink, over it and show me a syntax highlighted version, which is nice. And then I have compilers and a few other tools. I think we need to find a way of getting Ink to be an official GitHub recognized language.

I think that would be awesome, wouldn't it? Yeah, if you're working at GitHub on the language tooling side and want to get Ink in, also let me know. That would be fantastic. I think after this show, you're going to have a lot of, maybe not immediate, but ongoing attention. Hey, I listen to this show you're going to have a lot of maybe not immediate but ongoing attention hey I listened to this show, I loved your ideas I know it's open code but not open to contribution because based on at least on Inc I see a couple pull requests where you've slightly declined integration

just because the ideas didn't align but I can imagine after this show you're going to have more attention let's just say I don't really have a great way of thinking about how i should um deal with it for lack of a better word i mean i it's it's kind of my baby so there's like especially for ink because i use it personally so much i want to kind of keep it the way it is but i also recognize other people wanting to move in and suggest ideas yeah we'll we'll see. And like Andrew Healy, for example, September 3rd last year,

did a great write-up as an issue and was like, here's some concerns around declaring types as a number and the utility and all this different stuff. And your response was like, hey, that's intended behavior, you know, et cetera, et cetera, et cetera. And there's a couple other issues I've seen as well, where it's like, there was a pull request.

And, you know, I think the way we had a conversation with with Ben Johnson around this and I think it's just being clear. Like, hey, this is my personal project. It's not meant to be used by everybody else. It's open code because I want to share and share ideas, but it's not necessarily open to contribution. You're welcome to contribute a pull request, but don't be offended when it's declined because this is meant to be useful for me and no one else, and I'm not trying to hurt anybody's feelings. I think if you were just clear, that's the easiest way, because I think what you're doing is respectable. It's just a matter of the expected behavior when sharing code is that it can be contributed to. But if you're clear that it can't be, or that

you're just not as flexible because you have your own specific uses, then it's like, well, I can't be upset with Linus because he's like this. It's how it works. Yeah, definitely. I think the other thing is the beauty of open source, you can always fork it. If you like ink, but you don't like these things, then you can fork ink and implement these things differently. Actually, Andrew, I've spoken with a few times, and he's built his own ink interpreter in Rust. And so if he wants to, he can implement his own version of ink that fixes all these problems that he has with ink. And I think that would actually be amazing to see.

And so, yeah, I think the forking model of open source, I think I'm a huge fan of, rather than this, a lot of governance and decision-making and things like that going into it. If it's written in Rust, you should call it Rink. Or you can write it in F Sharp and call it Fink. So I'm actually, this is sort of the coming out of this project that I have under works

but I've lately been working on sort of like an ink 2.0 which fixes essentially every complaint I've ever had about ink not sure if it's ever going to be super useful or public or things like that but I just making it as a hobby project like anything else

and you know it's surprisingly difficult to find a name for a programming language because all the good ones are taken. All the single letters are taken. A lot of the double letters are taken. You don't want it to be too long. You want the file extension to match up with a name. My girlfriend suggested, why don't you call it Oak because it's like ink, but it's like a generation.

It turns out there is an Oak programming language. It was the original name for the Java programming language or a predecessor to it. So it's surprisingly hard to find a good name. This episode is brought to you by our friends at LaunchDarkly, feature management for the modern enterprise, power testing in production at any scale. Here's how it works.

LaunchDarkly enables development teams and operation teams to deploy code at any time, even if a feature isn't ready to be released to users. Wrapping code with feature flags gives you the safety to test new features and infrastructure in your production environments without impacting the wrong end users. When you're ready to release more widely, update the flag status,

and the changes are made instantaneously by the real-time streaming architecture. Eliminate risk, deliver value, get started for free today at LaunchDarkly.com. Again, LaunchDarkly.com. Let's assume there's some FOMO out there. Jared mentioned non-viable in terms of your language. You mentioned his response with that may be true, you know, and maybe not yet. You know, maybe at some point it will be, but at least right now, ink is intended to be, you know, a Linus-only language.

And you're, you know, you're open to hearing ideas, but you're not necessarily looking for contributions, et cetera, et cetera. But to that fact, you know, some of the knowledge you've gained while doing the interpreter or syntax highlighting, you know, you've learned a lot of things that transcend simply the language,

but I'm sure you've got friends in the industry and they're doing cool things or whatever. Have you had any FOMO? How do you translate your choices to other choices? And are you looking over shoulders and thinking, man, that's kind of cool? Yeah, that's a great question. So when I started out building these personal side projects,

that was actually the legitimate concern that I had. I look around and there's all these cool people that are spending their time without working outside of work building these more legitimate, feeling legitimate looking production level services that are scalable and watered and distributed and all this kind of stuff. And I'm over here saving my data to these JSON files and working on these personal projects that only really I use.

And for a while I looked at that and I was like well, maybe I'm practicing skills that aren't actually useful. But I think over time, that fear sort of went away for a couple of reasons. One is people started finding my work interesting, which I think just say what you will about looking for external validation. But I think I needed some degree of that validation to be like, hey, maybe the thing that I'm doing is actually not a waste of time. Maybe there is value in it, even if it's not the same value as creating these production-level services. There's value in other people looking at my projects and being inspired to go build their own versions, or there's value in people thinking it's interesting,

getting interesting ideas off of it. The second realization that I had was there was more than one way to practice software engineering and building had was there was more than one way to practice software engineering and building things. There's more than one way that programming can be valuable. One of them is to build these kind of large scale distributed services that work really well at scale. Another way is to just like build personal tools and kind of present ideas. A lot of my projects are about, I had this idea of how this should work and here it is and it works for me and look at how it works for me. Maybe you can take that idea and build something else. And so I think I realized there's a lot of different ways that writing code can be valuable.

A lot of different ways to practice being a good software engineer. I think I have sort of a different skill chart than a lot of traditional software engineers just because I'm very well practiced on certain things like rapid prototyping and certain kinds of domains, whereas I'm not as practiced on working large amounts of data or analytics or things like that. And I think that's okay. You've got to fit into a team and to build a good team, you need people that are good at different things.

So I think in the end, there's a lot of different ways to be good at your craft. And I think I'm becoming a lot more comfortable in my skin in the particular way that I try to become better at what I do. Well, if we're speaking career, and if you're talking hiring versus starting something itself, really you're trying to impress somebody that you are worthy of a role, right?

And whether you spent your time doing production scale large data distributed systems or working on personal projects I think when it comes down to impressing upon somebody that you are good at what you do and that you can learn is the fact that you've learned all these things enough so to create your own programming language and then your own tooling for all these different aspects of your life.

And so does it really matter that you know TypeScript in and out? Even though you probably do because you work nine to five doing TypeScript. But let's take Rust. Does it really matter that you haven't spent the last five years learning Rust

when you've learned enough about programming to be able to write a language that you write all your projects on? So I think there's, yeah, it probably works. Yeah, it definitely does. So I think that probably works. Yeah, it definitely does. I think it's actually funny. I talk about this with some friends who are more traditionally in the industry.

It's actually very hard to impress people doing the thing that everyone else is doing. It takes a lot more effort. Whereas if you're doing the thing that only a few other people are doing, like building a bunch of personal projects, it's actually way easier to be more noticeable and especially be more noticeable to the people that you probably want to work with working on the same things. So a lot of the people that I get to talk to building these projects are building products or building companies that are working on the same kinds of problems

like search and personal tooling and community, which is great because I love to work on these problems outside of my side projects even at work. You're the purple cow. Purple cow. How dare you? Explain the purple cow. Yeah.

Seth Godin wrote a book called Purple Cow. And essentially it's be remarkable. If you're like everybody else, you're invisible. Stand out, you know, be different in those ways. And so in a world of cows, using Seth Godin's language at least, his lingo, I didn't make this up. He did. You know, in the world of cows, be the purple one.

If all cows are white and brown and black, but mostly white, I guess except for some bulls or whatnot, but those are a different breed. Lots of exceptions in this metaphor. The point is, in the world of just a cow, you know what a cow is like okay you find a child right that learns you know animals and sounds you show them a cow they're gonna go moo right that's right you show them a purple cow they may go i don't know what to say about that one because it's purple right you know so be the purple cow stand out yeah i like that i can buy with that okay you got him he's on board be the purple cow well it's true. I mean, if you do the typical path, then you get the typical results, right?

And maybe you're after atypical results. If you want a non-normal life, then you have to take non-normal routes, I think. And it seems like that's what you're doing. You're not, I mean, how many people have written their own programming language? Probably hundreds, maybe thousands. Definitely not hundreds of thousands. It is getting easier,

and I would like to push more people to do it because it is a really fun experience. But I've definitely put more time into it. So if you're starting today to write your own language and someone's like, all right, I want to be a purple cow. I can't believe we're taking this on. I want to be like Linus. Linus Lee.

And just to specify, there's a namespace conflict online. I want to write my own programming language. How would you advise them to start today? Where would they go? Who would they learn from? Would they just fork ink and write Fink? What would they do? There's a bunch of different ways. I think the way that I would recommend

that's closest to the way that I went into it was start with something simple. That's useless advice, out of context, but I think, I mean, start with something more complicated. No, start with something simple. But specifically, I think it's really hard to know what's simple to implement. Like classes and inheritance seems pretty simple on the outside.

Certain kinds of optimizations seem pretty simple on the outside, but it's actually not trivial to implement compared to other kinds of features like closures and things like that. And closures actually is another example of something that's quite difficult to implement depending on what level you're working at. I think Lisp kinds of languages are quite easy. A lot of beginning programming language tutorials will start with this

just because of its semantic and syntax simplicity. Start with something simple and slowly add pieces on. There's specifically a lot of great sort of resources and books out there that could help. The ones that come to mind, I actually have a blog about building your own programming language too. If you build, if you search my name and how to build a programming language on Google, you'll find it. But outside of that, the resources that were really helpful to me were specifically, there is a great book that actually just came out in physical copy this week by Bob Nystrom called Crafting Interpreters. It's probably the single best piece of literature online. It's free, although you can get a physical

copy too, about how to build an interpreter. And it goes sort of from the basics all the way up to building something that's rather sophisticated. So Crafting Interpreters, there's another book called, I think like Building a Compiler and Go or Building an Interpreter and Go or something like that. Writing an Interpreter and Go, that one's by Thorsten Ball. We've had him on Go Time episode 28 way back in the day. He's been on the show a few times. I haven't read that one, but I've heard a lot of people also vouch for it.

I've looked at some projects that other people have built following the book and that also looks amazing. And those are quite easy to follow. If you know the base language for those books, it's Go. You can follow it like any other programming tutorial and it'll teach you the basic concepts you need to know. And then once you build something like that following instructions, it's like Legos, right?

You follow instructions and then you can start adding pieces or customizing things to your liking. I think the great thing about programming languages as a project is there's so many things to customize. You can customize the keywords, customize the syntax, you can change how different built-in functions act. And so follow one of these great guides

that exist already and then sort of hack away at it to your liking. So you've made mistakes with Ink and you now have brought forth Ink 2.0 or this new thing, the unnamed project. What are some of the things that you decided to change or what motivated you to go ahead and write a second new programming language

that's at least I assume similar to Ink but different? So it's similar in that it's keeping all the things that I actually like about Ink around its simplicity and focus on first-class functions and closures and callback-based asynchrony. I would not say I'm bringing it forth. It's still kind of under wraps, but I can talk about it a little bit. The reason that I started working on it

actually was a little bit embarrassing. I got this great chance to give a talk about Ink in this year's Go for Con, happening later this year. The organizers asked me to talk about the process of building your own programming language in Go. I was like, that year, the organizers asked me to talk about the process of building your own programming language in Go. And I was like, that sounds great, I'd love to talk about it.

But the in-code base, because it was one of my first major Go projects and because it was my first programming language, is kind of hideous. The code is not, what I would say, super clean. It's not organized in the way that I would do it now if I did it. And so for that kind of talk, rather than rewriting significant parts of Ink and spending a lot of my time doing it, it's a few thousand lines ago. So while I'm rewriting the interpreter, I'll also fix all the things

that I think is wrong with Ink currently, and that ended up being kind of a different language. Ink is callback-based, event loop-based, a lot like JavaScript, which is where it's a lot like JavaScript. A lot of the syntax is staying, but I'm introducing a few more keywords. Ink is very heavy on sigils, like symbols. That's nice from it makes me feel warm and fuzzy inside

that there's no English keywords in the language, but it's a little hard to use. So I'm introducing some symbols and keywords. I'm making certain kinds of built-in functions a little more pragmatic, a little less sort of like ideological and axiomatic. Like in Ink, there is a read function that reads from a file

and a write function that writes to a file. And one of the things I found difficult while building more sophisticated projects with Ink was like sometimes you want to keep a handle to a file and read from it over and over and over again. Sometimes you want to truncate a file, sometimes you want to append to a file without writing over it.

And those things are kind of hard when you're limited to those APIs. So I'm fixing some of those APIs. I'm adding a pipe operator to make chaining function calls easy because we don't have objects and methods. So you can't do array.map. So you have to do map and then pass in the array. But with a methods. So you can't do array.map.

So you have to do map and then pass in the array. But with a pipe operator, you can do array, pipe, map something, pipe, filter something. So just making it a little more ergonomic. Basically, in my head, there's a mental list of all the things that are like, I wish it worked a little differently from all the projects that I've built with Ink. And I'm trying to add them in without succumbing to the pressure of trying to do too many things originally.

So you should have that done plus your talk in time for GopherCon, right? Like October. I think sometime in December. December, that's right. No pressure. It's sort of in the back of my mind, working on it when I have time. Going back to career and what you said before when Jared asked you in the first part of the show, I think you said it was kind of backwards.

Like you're not – you're trying to not take what you've learned at a job back to your side project. You're sort of taking your side projects to your job. So back to the career part, you're not like mapping out your career based upon like, oh, I'm going to do these things to get hired somewhere. You're sort of choosing your career in a way based upon – at least you're a five, based upon what you are learning now in your side projects, so you can use them there. Is that correct? Yeah, that sounds right. Just because I've worked on a lot of things on my side, a lot of the people that I get to meet and talk to about the people

that I might work with in the future, things like that, a lot of that ends up being related to what I'm thinking about on the side. So when you keep layering on Ink 2.0 or things like that, you're not necessarily doing it so that you can get that FOMO job, your friend or whatever, like purple cow momenting yourself essentially. You're just trying to keep doing what you do on the side.

Sounds like that's what you're optimizing for. Like you're optimizing for the joy of your side work more so than the joy of your primary work. Yeah, and I think if you're working on things, at least for me, I found that if I work on things that most fascinate me or intellectually excite me on my side, it's always going to lead to me talking to people that are working on similar things. So with Monocle, it's like a personal search engine. That introduced me to a lot of problems

and cracked open this wide world of search as a general computer science problem space, natural language search, text search. And it turns out there to a lot of problems in this sort of like cracked up in this wide world of search as like a general computer science problem space natural language search text search and it turns out there's a lot of people working on search as a problem even outside of you know google and bing it's a huge space and i think just building something in it and talking to people about it has opened up a lot of really interesting doors to other people that are they're working on similar things and potentially some people that I might work with in the future. This episode is brought to you by our friends at Square. For our listeners out there building applications with Square, if you haven't yet, you need to check out their API Explorer. It's an interactive interface you can use to build, view, and send HTTP requests that call Square APIs.

API Explorer lets you test your requests using actual sandbox or production resources inside your account, such as customers, orders, and catalog objects. You can use the API Explorer to quickly populate sandbox or production resources in your account such as customers, orders, and catalog objects. You can use the API Explorer to quickly populate sandbox or production resources in your account. Then you can interact with those new resources inside the seller dashboard. For example, if you use API Explorer to create a custom in your production or sandbox environment, the customer is displayed in the production or sandbox seller dashboard. This tool is so powerful and will likely become your best friend when interacting with, testing, or playing with your applications inside Square. Check the show notes for links to the docs,

the API Explorer, and the developer account signup page, or head to developer.squareup.com slash explore slash square to jump right in. Again, check for links in the show notes or head to developer.squareup.com slash explore slash square to play right now. So let's turn to Monocle then. We've talked around it.

Let's talk about it. Personal universal search. I like this idea of a personal knowledge base. Not just the things that you put out in the public, but all the things. Because I feel like my data is spread about different apps and different locations. Lots of times Adam asks me things like, where is that?

Or how did you know that? Or how did you know that? Or where did you document that? And the answer is almost always different, Adam, isn't it? Like, well, that's in my notes app, or that's in HackMD, or, oh, I wrote about it on Change Talk News two months ago. It's always, we're going to get into, I think, sharing at some point, because I think

with knowledge, it goes beyond the personal, and you want to collaborate or share knowledge. But just my personal knowledge feels like it's just like uh i can't clean my room so i like that you're tackling this problem and we will talk about how it has inspired other people because i found another project that's directly inspired by monocle trying to do it in a slightly different way so tell us about your ideas around personal search and why you decided to try to tackle that problem. Monocle is a personal search engine.

What it does is it indexes a bunch of data sources that I have in my life, my notes, my contacts, all of my blog entries, all the bookmarks that I have and the text inside them, all my tweets, all my journal entries over the last few years, and basically makes it all searchable in a full-text search setting. So I can go to Monocle and I could type in, for example, productivity workflows or changelog, and it'll give me all the references to those things that I've had in any of these data sources over time.

It started, like a lot of my projects, it started as a learning project. So Monocle was actually spun off of this bit of code that I was experimenting with to figure out how full-text search engines worked and search indexes worked. But once I had that search index working, I was like, well, what do I want to search with this? And so I added my blog. And I was like, well, it turns out it's actually not that difficult to add incrementally all these little pieces of data to this thing.

And then I built a UI around it. And now I sort of use it day to day. I think search is interesting from a personal tool. There's a lot of companies working on search from an enterprise perspective, of search for your team's documents, or search your Google Docs and Notion in one place. But I think from a personal perspective, it's really interesting, because as you said, Jared,

there's a lot of personal data that's just distributed across all these different places. And we almost sort of trained ourselves to think in terms of information, think about information in terms of these products. So oftentimes when someone asks you about a person, the first thing that jumps to your mind is, do I talk to them on SMS or do I talk to them on Twitter

or email? If you think about it, it's kind of silly that you have to ask that question. The computer has all this information. You should just be able to ask, what do I know about this person and bring it all up. I think there's a lot of still kind of creative thinking to be done there and low-hanging fruits for making it easy to just find information. Like Jean-Luc Picard, he just says to the computer, tell me about this person.

And then it just tells him. He doesn't have to go stand at the holodeck or the bridge wherever he is he just says computer you don't have to look in the right folder or look in the right app or search for the exact right keywords or time or something and I totally do that I'm like is that in my notes app? is that in a text file on my desktop? is that in a database somewhere? is that in my notes app is that in a text file on my desktop is that in a database somewhere is that in

my bank account you know just searching all the things i wonder if it's because everybody's at odds really i think about with siri for example i have to be specific siri play x on spotify yeah for example like there's there's all these at odds within the tech sphere. It's almost like this space doesn't get better because there's so much money at stake that everything has to be secret or hush-hush and there's so much competition and good things don't get built because they have to be monetizable and there has to be some sort of financial tie to it or some sort of incentive that really is about riches and money and wealth and materials

and power, it seems like the things we want to search are really at odds. And it's not for the user. It's for the companies that provide the things so that the users can use them, less the other way. We're not in charge of the tools we own or use. Jared, you're barely in charge of Notes app. If Apple tomorrow canceled it. Cancel my notes?

You know what I mean? What could you do? You could do nothing, you can move notes but i mean like you might have history gone you know who knows like we're i'm not trying to say that you're literally not in control but yeah the balance of power is really in the giant's hands for the most part i have a good friend who actually had a note disappear this was a couple years ago back before was it cloudKit that came out? There's a point where iOS got significantly more reliable on notes.

Messages got better, contact sync got better, and notes just generally got better. Maybe three years ago. Prior to that, they had terrible cloud things. No offense, Apple engineers who are listening. But they did. They just had bad cloud things. And he just had this note that just disappeared

and it was gone. And who do you call? You can't call Apple. You're just gone. A month or two back, I said that I messed up. I lost my son. Deleted this whole entire thread of this army buddy I had. My best buddy. My battle buddy in the army. And we go back 10 years.

Whenever I got the iPhone, the history's been there. Talking about people we've known in the military that have either passed away or something happened or 10 years or you know whenever i got the iphone like the history has been there and talking about you know people we've known in the military that have either passed away or something happened you know or somebody had a baby you know like just history essentially that's gone i'm not in charge of my message even like it's on my phone i can back it up but like i can't restore that single thread we're just not in charge of our tools is the point i'm trying to make yeah yeah even if we think we are linus is linus has all of his tools right there on his laptop. You actually hit on something that I've been thinking about a lot recently

as a driving philosophy for building all my tools and also search is so much over workflows around our data and our information and just our digital tools are product-focused and company-focused instead of problem-focused, which I think is a really eloquent way of putting it. So a great example that I cited earlier is, I want to look up this person and see what I know about this person. I have to search through all of these products and these tools instead of just looking up

the person. This happens in general because companies want to keep users to their product. Apple doesn't really want to think about how they integrate with every other thing they use in your life to keep information organized. And I think one of the benefits of building my own tools is I can think about these things from a problem perspective and not from a product perspective. I don't have to care about the success of any one particular thing that I use. I just care about my information and how I can find them. And so there's a lot more incentive aligned there. And I think I can build tools that actually solve my problem first and foremost instead of solving your problem

as an incidental kind of benefit to making me use whatever these companies are building. So I think that's a good benefit to building your own tools as well. It lets you go out in the world and do your thing too. You can go out and tweet and you can go out and blog, you can do whatever and you can determine a source point, I'm sure, to bring back into Monocle for searching later. It lets you just be who you want to be wherever you want to do it at and you just index it based upon that. And if you stop using that blog, you stop going to Twitter and tweeting, well then, the index ends.

When I first started looking into Monocle more and just this idea that you said you have a decade of journals, I'm starting to think about people of the past like Albert Einstein or super smart people that have impacted the idea of relativity, for example. The way we think about physics, the way we think about space travel and time travel or whatever it might be. If those kind of people had this kind of tool that could index it. Should a tool like this eventually be overturned to the public? Could they elect, okay, my monocle, let's just say, I'm going to be dedicated to this practice for years, and monocle is going to make it easy because it's so problem-focused and not product-focused.

How can I take an Albert Einstein-type person, and 25 years from now or 30 years from now, Elon Musk had a monocle? Could that become public? Could it become public domain, so to speak? Not because we want to know his secrets, but because we want to know his knowledge. How can we transcend the idea of humanity through knowledge and knowledge share, problem sharing essentially, by this idea, this practice of indexing our contacts and our ideas and our tweets? Is that something that you've thought about as regards to Monocle? Definitely.

So there's a lot to it. This is getting into sharing knowledge tools space. So at a basic level, you can take all of Albert Einstein's notes or Elon Musk's notes or Mercury's notes or whatever and just make it public. There's a lot of that data already out there. A lot of documents are public

and you can look through them. But the problem there is none of them are really searchable or annotated in a useful way for people to look through it. And then you can index it and you can make it searchable, but then people don't know what to search for. Maybe there's some note about some interesting thing that Einstein thought about that people don't know to look for, so it doesn't surface. And then you can go to the next level and say, okay, maybe there should be a suggestion system

or a thing that shows, maybe I'm browsing the web and it can show me relevant things from not only my stuff, but also notes from other people from your team or from other people that have lived before. There's a hierarchy of features that you can add to make people's minds and graphs of ideas gel better together. I think the hard thing about sharing ideas is

what I call by one label is not necessarily going to be exactly what you call by another label. So there's kind of a labeling problem. A lot of companies are tackling this these days, but I think there's some kinks to work out and a lot of exciting things that we can do once I can take my Monocle database and merge it with yours and have us search both, or things like that. One thing that I've thought about as an extension to Monocle, or maybe a project that someone else can work on,

is what if there was Monocle for my entire team? If I've ever talked to a customer, or if I've ever worked on this problem, it's in the database. And if someone else searches for how to solve this particular problem or how to fix this bug, they can look at my notes on how I did it. The problem there again is, they don't know that it's in there. They don't know what to search for. You get into more machine learning-driven ways to recommend things.

In general, I think when you share these databases, there's a lot of potential. There's a lot of human problems in there as well around privacy and agency and consent. Because maybe Albert Einstein doesn't want us to have his monocle, but he's dead and he can't speak for himself. Right. I think in this case, my example, to be clear, was like if he elected.

I know it was. Yeah, if the person elected to, because they thought, well, when I'm gone. Who cares? I want to give my knowledge to the public. Yeah, I know you meant that. I'm just saying like even in the real time, like if we just talk about sharing amongst a small organization, knowledge sharing, it's very difficult

because there's a lot of little nuances. I think Basecamp does a pretty good job of this with a client and a service provider relationship where you can have private conversations and it makes it very clear who's getting this email or who has access to this thread because there are things that you want to say not trying to hide it from your client because it's shady but because it's just like either noise or it's meta or maybe it is shady but the point is is like i want to share this with adam but not linus for example i want to share this

with everybody in this team but except for George, because there's reasons. Maybe they're good or bad. But you know what I'm saying? It gets very, very... It's too loud. Yeah, George is too loud. Be quiet, George. He's getting upset.

Yeah. It gets really difficult to actually navigate those paths well. Monocle is, I think, a great example of the type of thing that would be very difficult to build for the general public because of the privacy reason. I have all my journals in there, I have all my private notes in there, in addition to all my public data, and I would never give that data to any company

that wants to be able to read it. So I keep it in my personal infrastructure, and I can index it because I know exactly where that data's going. And that lets me do that, but I think to run that kind of service for other people, I think, requires that they put a lot of trust in you, which I think is difficult. Which makes sense in team environments because if it's encapsulated to just simply the amount of knowledge and service you can give to the team, for example, like in a work environment, you sign a contract or you committed in some sort

of way, there's some sort of like clear boundary between you, the person, and then you, the worker, the individual that shows up, right? There's some sort of like offer there. And I think in those scenarios, it can be easier to give, but then at what point, like, what do you give? You can search all my emails, you can search all my docs I created. You can search all my notes in the employee version of my notes app or whatever. Like, there is some lines to be crossed there. But I think this idea of sharing knowledge like that is pretty interesting. You've done it for yourself. What was the motivation for doing it for yourself?

When you say problem-focused, what was the problem that you solved when you solved the problem? It's literally that I couldn't look things up as much as I wanted to. If I wanted to, frequently, for example, when I tried to learn something new around, I was looking up a lot of stuff around natural language processing, topic extraction from text, things like that. I was trying to figure out what I knew already about that subject. Without Monocle, I'd have to go to every data source and perform a bunch of queries to try to collate everything that I knew.

Where here, I could search Monocle, I can figure out all the people that I know that are in that field, all the bookmarks that I've made in that field, any notes that I've made of related projects. Having that there, having it so available so quickly, I think is actually kind of a game changer. It's one of those things where it's so easy that it actually makes you search more. Or even document more. Yeah, exactly.

I would imagine you're far more motivated to put down what you think you know, because in the future, what you thought you know, you actually knew. And now you want to know what you knew. Exactly. Try to follow that. Can you write that down? These days when I bookmark something it's not just i'll come back to it later but it's like i'll be able to search this later so anytime i come across something that is like oh i might want to remember this or recall this i just bookmark it now and i know i'll

be able to search for it forever for the rest of my life yeah so does this thing then just simply index and keep a copy or does it index because the the version i'm seeing at monocle.search.sh seems like it's its own version. Like, I don't think that this blog post that you wrote, the miracle of trust is because I'm just click on your examples. And I think the thing at search was actually your name minus Lee. And the very last one on the list was dub dub dub. So I'm assuming that's a blog post that you wrote. This is a copy of it, this is not the original version of it. But then it gives me a link to open it up. Yeah, so the way the monocle generally works is

I pull in excerpts if it's a long document, or the whole document if it's not that long, of any of this data stuff, data sources that I have, and it keeps a local excerpt. But then, if it's something that I can link to, you can click on the open button to link it, to open it up somewhere else. Frequently for tweets, for blog posts, for notes, for notes that I can link to you can click on the open button to link it to open it up somewhere else

frequently for tweets, for blog posts, for notes for notes that I have on web apps all of them are linkable and I can go and edit it or add to it or something like that the version that you're looking at on monocle.search.sh is actually also kind of exactly what you talked about it's like a public version that's the version where from the search index

all of my private data was scrubbed out so you can only search public sources essentially this is in the index but it's searched for this public version. You can only see sources. Do you mean literally scrubbed or just not searchable? It's in the database, but maybe it just doesn't show. So it's actually two completely separate indexes. So that one only has public data indexed.

The one that I have access to, I feel so secretive, the one that I have access to, I feel so secretive, the one that I have access to that nobody else has access to, has... He made a face when he said it to everybody. He's like, I'm so secretive. Has a few extra thousand documents from my personal notes and all this kind of stuff

that only I have access to. Well, let's face it, there's things to be private about and that's okay. There's things to be private about that aren't necessarily embarrassing or wrong. It's just private. This is my information, not yours. There you't necessarily embarrassing or wrong like it's just private this is my information not yours

there you go yeah and also it's so hard to you know I don't want to have to look through all my notes to see which one I can show or not

so I just don't show them but there's already a lot there all my tweets are searchable which is itself pretty embarrassing you can search for anything and find all the times

that I talked about Taylor Swift or particular technology or Apple 84 results Taylor Swift 84 results that's a lot that 84 results. Taylor Swift, 84 results. That's a lot. That's more than mine. That's a lot of tweets. You spent a lot of time tweeting.

I talked about Taylor Swift during this web design lecture while in a Taylor Swift shirt, while playing a Taylor Swift song, working on a demo of a Taylor Swift-themed web design. This is my best life. That's a public tweet by you, my friend. That is a public tweet. Like it or not, that's already public, by you, my friend. That is a public tweet. Like it or not. That is a public tweet. That's already public, so making it searchable. Yeah.

So, Taylor Swift fan, it seems. I am a big fan. Yeah. She's a good musician. That's fine, too. Yeah, nothing wrong with that. It's just funny because as you were saying that, I was looking at the results because it was one of your built-in labels.

Oh, yeah, definitely. It's a suggestive search for a reason. Yeah, exactly. Actually, one of my other side projects is a quiz that'll quiz you on how well you know Taylor Swift lyrics.

Yeah, it's a good party game. Are you the only one that takes the quiz? No, actually. I've had, whenever I meet someone who's like, I'm a big

Taylor Swift fan, I'm like, take this quiz, prove it to me. Wow. I've only had a few people beat me at the game. Wow.

I'm not even going to try. I used to think I knew Friends pretty well, and then I played the Friends version of Trivial P the game. I'm not even going to try. I used to think I knew Friends pretty well, and then I played the Friends version of Trivial Pursuit. I do not know Friends very well, it turns out. There are levels to all this.

There's always somebody who knows more than you at any particular subject, right? That's what you find. And this is Taylor Swift, and you went, at least on this call. So with Monocle, this was a personal problem that you solved for yourself, but you must have, and I suppose to some degree, you've probably shared some of the big idea you might have released as you've solved this problem. Maybe your thought process around

search and personal information and how you can search your own index has changed. Like, what do you think should happen? Not so much based on monocle, but just like understand the problem more. Like, do you recommend more people do what you've done? You mentioned private versus public. Do you think people can have sort of a monocle, if not monocle itself, a version of what monocle does for you as a utility for themselves? Like, here's a private version for me that I can see everything. Then maybe here's a public version that I'm like, I don't mind sharing these things with the world because I'm a public figure of some sort. I want to be more public even if I'm not a public figure, I'm still aiming

to be public about certain things I share in the world. What do you think? How's it evolving for you? So first I think, there's a couple takeaways that I had. The first one is I do think more people should experiment with building something like this. It's kind of funny when when I tweeted it out, and the tweet became reasonably popular, a lot of people commented sentiments of the sort of, I've been wanting to build something like this for the last five years,

and it's cool to see. My reaction is, if you've been wanting to build it for the last five years, why haven't you built it? I have good tools in my toolbox, but it took me a week or wanting to build it for the last five years, why haven't you built it? I have good tools in my toolbox, but it took me a week or two to build. More than that, actually, because you built Ink first. Well, it's true, but I could have written using Python or any other. You could have. But it's conceptually simple, and if you scope it right,

you can build something like this for your own personal infrastructure. So why don't more people do it? And I think one of my purposes or goals in putting things like Monocle out is to encourage other people to also build their own versions because it's a super tractable problem, it's not impossible. At a higher level, I think search is, the more I think about it and the more I talk to people about it,

search is an unsolved problem. We look at Google and we think, search is about as good as it's going to get. But I think there's a lot of headroom, both in terms of the basic style search of, I put in some keywords and find something that's related in my documents or my team's documents or the world's documents, but also things like I'm reading a webpage

and I'm trying to find other similar pages that I've looked at or other similar notes that I've looked at, or I'm talking to someone and I want to figure out what I need to know about this person from all my documents. There's a lot of applications of search for keywords or search for ideas that I think are still kind of underexplored. I think there's a lot of opportunity to just build better tools in the search space. The phrase search yourself comes to mind when I hear you talk about this because there is

no true solve problem. How do you search yourself? Darth said a version of this he said search your feelings you know what to be true which there could be a play on that for naming so we talked about naming how can i how we can help you but i think that may have ended up in a break but you know there is no true solved product to search yourself i can't search myself what i know yeah except for my own brain it's a non-technical problem. It's a psychological problem. It's in my brain to search myself. How often do people out there want to search themselves?

That is a big question. I think something that's related that Monocle has put in my brain is thinking about memory. A lot of your sense of identity comes from memory. One way that I describe Monocle a lot is as an extended memory.

Everything that you've written, everything that you've read is in this thing and you can search it. One of the interesting things that I did with monocle is actually made it my default search engine in my browser. So if I type in something into my URL bar and hit search, it doesn't search Google anymore. It searches monocle. And I like to describe it as, you know, Google's great for discovery, for finding new things, but Monocle is sort of searching my past instead. It's searching everything that I've already written or looked at before.

So in a way, it's sort of searching my past and it's sort of searching myself. So that's how I'll tie that into your question. But yeah, I think if memory's more accessible. There's something here for sure, because I've even rediscovered old notes I've written way back when I think I was wiser. I feel like as you get older, just based upon entropy, you should get wiser. And I think I have gotten wiser, but I've also gotten forgetful.

So there's been things I've said or ways I've thought that I've either evolved or changed, I no longer have that problem anymore. And I think differently where I'm like actually motivational to myself, you know, from previous ways I thought maybe even naive, but still yet wise and, you know, like visionary in some ways, nothing in particular comes to mind, but there's definitely been a few times I've shared that on brain science. Cause we had a show around psychology and habit formation and different stuff. And I've actually like been introspective. I searched myself, like, what do I really think? Why do I really think this way? And I've been surprised, but I don't have the search engine to sort of

like reveal those answers to me anymore. You know, I have to like literally hunt them down. It doesn't just appear in an engine where I can just be like, Hey, Adam, what did you think about motivation or whatever it might've been in this one particular scenario to rediscover what I already knew? I have to hunt it down hardcore. That is a real thing that happens, is rediscovering what you already know. Quite often I'll search Monocle for a person or an idea. The other day I learned about this thing called a trigram index, which is a way of doing text indexes in a database. I thought this was the first time I'd heard about it,

but I typed it into my browser, hit enter, and of course it took me to Monocle instead of Google. I wasn't still used to it at that point, so it was a little bit jarring. But it turns out I had read about it before in a different article. I remembered the article, but I didn't remember that this was a part of the article.

And so it made that connection. And I think in general, searching my past in this way, I end up making a lot more internal connections between things I already know or things I'm learning, which is cool. Yeah. Well, in memory, you have a graph, right? There's always neurons that fire together, wire together.

So if you never reconnect the wiring, essentially, in your memory bank or the way you think about things or how you associate a tree to the way you think about things or how you associate a tree to the color green or you know to leaves or a forest like all those things it's part of the graph so if you never go back and make those connections what you did there was make them stronger so now when you go back and you retrace that memory it's like well now i have an even deeper version of it because i've retraced the step the path got better grooved

and it's easier to get to the forest because that path was retraced. There's a new portion to the graph that's stronger now. Yeah, that actually reminds me of a really, really interesting question this one asked me about Monocle, which is, if when you're searching for things, you're searching things you already know, doesn't that sort of create a filter bubble? And as I build more of these tools that use my existing data

to help me discover new things or reinforce things, doesn't that generally sort of make myself, create a bubble in myself of things I already know? I think that's a really interesting question. I don't have a great answer to it. I think it is if it's limiting. So if you limit yourself only to that, then yes, it's a bubble. But if it's that plus, then it's not.

Yeah, I think there's definitely some bubble-like effect as I use more and more of it. But yeah, I think it'll be interesting to see whether that's something that's noticeable or whether the pros kind of outweigh the cons there. Well, I love that you put this out there, even though it's built for you. You said you want to inspire people

to build things like Monocle. I'm not sure if you've heard of Apollo or not, but there's at least one instance written by Amir Bolus, I believe is his name, which I came across, which is a Unix-style personal search engine and web crawler for your digital footprint. And I put this on Changelog News. And as I got to reading it, I'm like, this sounds a lot like Monocle. I'm like, maybe he has heard of Monocle. And at the very bottom, he lists inspirations, a lot like Monocle. I'm like, maybe he has heard of Monocle. And at the very bottom, he lists inspirations, and he says, Monocle, right there.

So I no longer had to wonder if that was inspired by Monocle. Sure was. So at least one person's out there taking your torch and running with it and building his own, which seems to be a little more general purpose than yours, but maybe not. Regardless, that's pretty cool. What do you think about that?

Yeah, I think that's awesome. So Amir and I have actually spoken on Twitter before. We've talked about various projects, and he's built some other projects that are sort of riffs of mine as well, outside of Monocle. I think what I like about Apollo in particular is it's not an exact re-implementation of what I built. It's not indexing all your data or things like that. It's doing something slightly different,

which is, I believe it's, if you want to save a web page to be able to search back later, you can sort of build your own web search index. You can build your own pile of pages that you can search later, instead of everything that you've ever done or everything on the web. So it's a slightly different spin.

Doesn't yours also index the pages that you're bookmarking, though? Yeah, that sounds right. So it's a slice of yours, a focus slice of what Monocle does. Right, right. As more people put this kind of spin on it and add their own opinions to it, I think that's the way that we're going to find new interesting tools.

So I think that's great. I love that Apollo is very Google-esque in terms of the colors. Maybe it's old school, at least on the visual interface, but it's paying some sort of homage to Google. Could be scary. I like the aesthetic as well. Yeah, it's like an old school design. We'll link that one up as well.

Well, Linus, thanks so much for coming on the show, sharing your personal universe of knowledge with us. I love how willing you are to go off the beaten path, learn and build brand new things. Kind of in a similar vein to Rasmus Andersen with his personal scale software idea. You're doing personal software as well for yourself, but you're publishing it for everybody to be inspired or to take ideas and to sort of follow in that same vein. Any last words or anything else you want to tell us before we call it a day? Nothing in particular.

I'd just say if you come across an interesting project or an idea, I think the world is much more interesting when your default assumption is not whether I can build it or not, but whether, you know, if I want to build something like it, what's the first step? How complicated could it be? Sort of have your default assumption be, I can probably build it.

Let's see how far I can take it. Very good advice. I love that. That's an excellent mindset. Linus, thank you so much probably build it. Let's see how far I can take it. Very good advice. I love that. That's an excellent mindset. Linus, thank you so much for joining us. It's been awesome having you. Yeah, of course. Thanks for having me.

All right, that's it for this episode of The Change Log. Thank you for tuning in. We have a bunch of podcasts for you at changelog.com. You should check out. Subscribe to the master feed. Get them all at changelog.com slash master. out subscribe to the master feed get them all at changelog.com slash master get everything we ship in a single feed and i want to personally invite you to join the community at changelog.com slash community it's free to join come hang with us in slack there are no imposters and everyone is welcome huge thanks again to our partners leno fastly

and launch darkly also thanks to break master cylinder for making all of our awesome beats that's it for this week. We'll see you next week. Thank you. Game on