Building software for yourself

So we’re joined by Linus Lee. You may know him as thesephist. I think it’s thesephist… Linus, how do you say that?

The Sephist, as in the, 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 it as simple as that. And there’s some fun in the ambiguity.

[laughs] That is true. What is a sephist? I don’t even know what that is.

When I was going to high school I was very into linguistics, and at one point I took on this kind of fun project of trying to invest myself my own language. So the word “sephist” means something in that language. The exact meaning I’ll keep off the record…

Okay.

Nothing shady, it’s just fun, but…

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 it’s a unique enough handle that nobody else has taken it on any social media sites, so I’m just gonna keep on with it.

[03:47] That is nice to have. So I’ve found you by way of Monocle, which is your personal universal search engine. And when I’ve 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… Then I started to check you out a little bit more, and you just have all these side projects; tons of side projects. So tell us about, first of all, before we get into the particulars of these projects - Ink is very interesting; I think Monocle is very interesting as well… What’s up with all these side projects, man?

Yeah, so side projects was kind of how I – it’s how I learned to program, and it’s still how I learn new things. I think the way that I think about side projects is pretty different from the way most people - or like the hackathon crowd, to the industry - likes to think about side projects. My side projects are never really monetized; they’re not really for other people. I just kind of make them for me to use them myself. Even that language is mostly for myself; I make them to learn about something, to understand how something works… I’ve built assemblers and compilers before to understand how those things work; just 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. I make them in a few days and just kind of maintain them over time. And once you do that over and over over a few years, you accumulate a lot of them. I think there’s 120-something on the big list on my website now. 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 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; a note-taking app 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, you know, tools for thought, as we get into Monocle, it’s kind of related to that to a certain degree.

They are related. The causality actually goes backwards. So I actually am fortunate to 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, so I tend to gravitate towards other people working on those things. But my side projects are where those interests start.

In your dayjob do you get to do a lot of the same things? Is there any crossover in terms of like – you know, when you do things for yourself it’s a lot of autonomy. You can do things that you wanna do, whereas maybe in the dayjob 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 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. So I’ll sometimes use side projects as kind of a way to 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 just complain about that; 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 you’re just 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?

The true side hustle…

Well, you said you’re not doing it, so it’s –

Yeah, yeah. I don’t think I’ve really even turned any of them into jobs per se. 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 like 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.

[08:01] Once you start running a service for other people, 1) it turns into a job where you have to listen to other people and what they want, and 2) there’s a lot more liability. You have to be liable for their data, for their security, and I think that then it start turning into a job. Maybe I’ll turn one of my projects into a job, but then that’ll definitely be a job, it won’t be a side project. I think there’s a pretty clear boundary for me, whereas in side 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 of it, and it’s like “You know what - I’m just sort of done with that thing.” Or “That bug doesn’t matter to me.”

Exactly, yeah.

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… 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 a 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 wanna 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 you becomes “Why publish them? Why not just keep them to yourself?”

Yeah, that’s a good question. I mean, for a few reasons. I think the main one that’s coming 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… Ink, the programming language, which we’ll talk about more later - that’s actually only a few thousand lines of pretty readable Go. And I think programming languages and compilers is just one of those things where people look at the general kind of space and say “Oh, it’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 showed up and started building tools like that is, you know, if you actually study it, it’s logical. You can follow. 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 you kind of have the same realization. A realization of 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 have come to me and said “Oh, I looked at what you build 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.” 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. 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.

Yeah.

Why put all the work in? I mean, you wrote a language in Go. You could have just written your tools in go.

Yes. I mean, you could ask the same thing about everyone with side projects… Why build anything then, right?

[laughs]

The story of how it came about - I was taking one of the introductory 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 undergrads kind of CS project. And it was one of those things where they had like 80% of the code templated, and you’d fill in the blanks, and fill in a 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 languages 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 just pretty – you know, there’s a lot of handholding, 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 switch of like “Oh, I really like this language. If I could only change this bit of syntax” or “If I could only change this thing that I don’t like.”

[12:12] 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… 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 a syntax highlighter, because otherwise it’s difficult.” So you write a syntax highlighter. And then you write a code formatter. And then you’re like “Oh, I wanna run my Ink code in the browser”, so you write 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 smaller 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 then; 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? 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 all the rest of the effort is 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. I mean, Jerod 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 cool – because it was my first programming language project and I also feel that there is a lot of little design mistakes and things, regrets that are now kind of baked into the language and baked into these projects and codebases, and I can’t make a lot of breaking changes, because I like to keep those projects working… So partly for that, and partly because I don’t think it’s a great language – like, it’s my baby, so I use it… But you know, if someone’s like “Is Ink better or is JavaScript better?”, I’m like “Clearly, JavaScript is the 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. I built this little startup on it, and now…”

That’d be a nightmare. Do not build a startup on Ink. [laughs]

“…and now 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 are running a startup on Ink and you’re not completely crazy, talk to me. But - yeah, you just do it at your own risk; this is with any of my side projects… I have a couple other projects that people will have rolled their own versions of. I have a Twitter client, I have a search engine that people have tried to spin up… And 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 kind of 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, like 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, its 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 primitive 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.

[16:04] A lot of it is simple because I had to build the simplest thing. I didn’t wanna 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, and you could attach – you had kind of an inheritance thing, but you really just had functions and objects, and you could do a lot with them.

I think one of the things that writing a lot of Ink 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 like structuring your functions and objects in basic data flow to make sense and be simple. If you do that, you can still write pretty clean code.

So what about tooling for Ink? Surely, Monocle has some sort of a storage engine or a place that you put your data. Its 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, or…?

Yeah. Built into the interpreter was a couple of different ways the language can talk to the outside world. There is a file system kind of interface, there’s a base 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 just so fast that you can kind of store things in normal files. All of Monocle’s search data lives inside a big 50-megabyte JSON. It’s kind of large for a JSON, but it can totally chew through it and be pretty quick with it. So I wrote a little JSON parser and serializer in Ink, and it’s 50 lines of Ink code… And I use that to do most of the data storage.

So I love that you’re still using Ink to this day, even though 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 a lack of a better word. Like, “I’m investing in the Python community” or “I’m investing in Go, my personal time.” I’m not saying I, Jerod, but this is the way people think… Do you have any concern that you’re spending your years writing in a langauge that only you use? 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 Ink code for their company…

Right.

I haven’t really ever thought about it. So the main reason that I haven’t thought about it is because at my dayjob I write React TypeScript, which is quite popular… And that’s gonna 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 gonna sound a little cliché, but it’s learning how to organize abstractions, and sort of deal with complexity. And I think a lot of that isn’t’ actually on the keyboard, it’s actually in your mind… So 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 kind of transfer over to any language that you use.

The other 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’ve built an assembler to learn how 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 is 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 the football, you may be just doing drills, you’re running, you understand the philosophy or the – I’m just using football as an example, but you’re still showing up to practice, basically.

Yeah, even if you’re not using a football. Throwing something.

[20:07] Right. You’re still involved in the process and the practice of maybe doing things that excel at programming, but not necessarily – like, Jerod’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-highlightable? 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. This is probably my favorite thing to talk about with Ink, because I think it’s sort of math-sciency. So my editor of choice is Vim, and I keep it pretty barebones, pretty simple; not a lot of plugins, just sort of basic color themes and little helpers here and there to work with Git. The only really Vim thing that I have for Ink is the 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 collapse functions down to one line.

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. I have Ink Fmt. That’s a code formatter for Ink. 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…

Yeah.

You’re the only one that writes Ink. I mean, just however you write it, that’s the format, isn’t it? [laughs]

It is, but you want your code to–

What if it changes over the years? He iterates his day-to-day, he can always have the fmt–

I love this - you have a formatter tool for yourself.

So actually - this is one of the rough edges… Vim’s auto-indent strategy doesn’t understand Ink syntax, so frequently it’ll mess us… And I don’t wanna have to manually go and untab and tab all these things, so I just write kind of messy code around the formatter, and it’s pristine again.

Okay.

And it helps with all the standards or benefits that apply to code formatters around standard formatting and automating kind of 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 Fmt… There’s also sort of color printers so I actually also have sort of a proxy on top of GitHub that’ll syntax-highlight Ink code, called Kin. That’s because to add your language to GitHub’s registry of languages that it knows how to syntax-highlight in its interface, one of the requirements is it has to be reasonably popular. And 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, 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 the syntax highlighter 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 wanna get Ink in, also let me know. That would be fantastic.

I think after this show you’re gonna have a lot of - maybe not immediate, but ongoing attention… “Hey, I listened to this show. I love your ideas. I know it’s open code, but not open to contribution…” Because based at least on Ink, I see a couple of pull requests where you’ve politely declined integration, just because the ideas didn’t align; but I can imagine after this show you’re gonna have more attention, let’s just say.

Yeah, which is – I don’t even have a great way of thinking about how I should deal with it, for a lack of a better word. It’s kind of my baby, so there’s like – especially for Ink, because I use it personally so much, I wanna kind of keep it the way it is. But I also recognize other people wanting to move in and suggest ideas. Yeah, we’ll see.

[24:00] Andrew Heely, for example, September 3rd last year, did a great write-up as an issue, and was like “Here’s some concerns around declares types as a number, and the tilde”, and all this different stuff… And your response was like “Hey, that’s intended behavior etc. etc. etc.” And there’s a couple other issues I’ve seen as well, where it’s like – there was a pull request, and I think the way… We had a conversation 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 wanna 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 about 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. So 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 him a few times and he’s built his own Ink interpreter in Rust. So if he wants to, he can implement his own version of Ink that fixes all these problems that he has. And I think that would actually be amazing to see.

So yeah, I think the forking model of open source I’m a huge fan of, rather than a lot of governance and decision-making, and things like that.

If it’s written in Rust, he should call it Rink.

Yeah.

Or he can write it in F# 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 gonna be super-useful or public or things like that, but I’m 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 the name… My girlfriend suggested “Why don’t you call it Oak? Because it’s like Ink, but it’s second-generation.” And it turns out there is an Oak programming language; it was the original name for the Java programming language, or the predecessor to it…

Yeah.

So it’s surprisingly hard to find a good name.

Break: [26:27]

Let’s assume there’s some FOMO out there. Jerod mentioned non-viable in terms of your language, you’d mentioned as a response with that may be true… And maybe not yet. Maybe at some point it will be. But at least right now, Ink is intended to be a Linus-only language. You’re open to hearing ideas, but you’re not necessarily looking for contributions etc. But to that fact, some of the knowledge you’ve gained while doing the interpreter, or syntax highlighting, 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 think “Man, that’s kind of cool”?

[28:11] 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 surfaces that are scalable, and modern, 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 - 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 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 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. It works for me. Look at how it works for me. Maybe you can take that idea and build something else.” So 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 with large amount of data, or analytics, or things like that. And I think that’s okay. You’ve gotta 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. I think I’ve become a lot more comfortable in my skin and in the particular way that I try to become better at what I do.

Well, if we’re speaking career and if we’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 spend 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… So does it really matter that you know TypeScript in and out? Even though you probably do, because you work a 9-to-5 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? I think that probably works…

Yeah, it definitely does. It’s actually funny, I talk about this with some friends who are more traditionlist from 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 a 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 sort of 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.

[32:02] You’re the purple cow.

[laughs] 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, be different in those ways. So in a world of cows, using Seth Godin’s language at least, his lingo - I didn’t make this up, he did… 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 and whatnot, but those are a different breed, but…

Lots of exceptions in this metaphor… [laughter]

The point is, in the world of just cows – you know what a cow is like… Okay, you find a child that learns animals and sounds. You show them a cow, they’re gonna go “Moo”, right?

That’s right.

If you show them a purple cow, they may go “Hm, 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 vibe with that.

Okay, you got him. He’s on board. [laughs]

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 an atypical result. 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. 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 “Alright, I wanna be a purple cow…” I can’t believe we’re taking this on. “I wanna be like Linus Lee.” And just to specify, there’s a namespace conflict online…

[laughs] Yeah.

“…and I wanna 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?

Yeah, so there’s a bunch of different ways. I think the way that I would recommend that’s closest to the way that I kind of went into it was start with something simple. I think one of the – that’s useless advice, out of context.

“That’s useless advice…” [laughs]

I mean, start with something more complicated – no, start with something simple. But specifically, I think it’s really hard to know what simple to implement… Like, classes 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 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 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 from the basics all the way up to building something that’s rather sophisticated.

There’s another book called – I think like “Building a compile in Go” or “Building an interpreter in Go”, or something like that.

Writing an Interpreter in Go. That one’s by Thorsten Ball.

Yeah, from Thorsten.

We’ve had him on Go Time, episode 28, way back in the day. He’s been on the show a few times, and… I haven’t read that one, but I’ve heard a lot of people also vouch for it.

Yeah, and 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 sort of follow it like any other programming tutorial. It’ll sort of teach you the basic concepts you need to know. And then once you build something like that following instructions… It’s like Legos - you follow instructions, and then you can start adding pieces on and 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 security, customize the syntax, you can change how the different built-in functions act… So follow one of these great guides that exist already, and hack away at it to your liking.

[36:14] So you’ve made mistakes with Ink, and you now have brought forth Ink 2.0, or this new thing; it’s 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 is a little bit embarrassing… I got this great chance to give a talk about Ink in this year’s GopherCon, happening later this year. The organizers have 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 Ink codebase, 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… So for that kind of talk, rather than rewriting significant parts of Ink and spending a lot of my time doing it - you know, it’s a few thousand lines of Go, so while I’m rewriting the interpreter, I’ll also fix all the things that I think are wrong with Ink currently… And that ended up being kind of a different language.

Ink is callback-based, even-loop-based, a lot like JavaScript. A lot of the syntax is staying, but I’m introducing a few more keywords. Ink is very heavy on sigiles, like symbols. That’s nice, 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, and a little less ideological and axiomatic.

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’ve found difficult while building more sophisticated products with Ink was like sometimes you wanna keep a handle to a file and read from it 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 array.map; you have to do map and then passing 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.

In my head, there’s a mental list of all the things that are like “Oh, 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.

Yeah. So you should have that done, plus your talk in time for GopherCon, right? October…

I think it’s sometime in December.

December, that’s right. December.

Yeah.

No pressure.

You know, 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 Jerod asked you in the first part of the show… I think you said it’s kind of backwards. You’re trying to not take what you’ve learned at the job back to your side-projects. You’re sort of taking your side projects to your job. So back to the career part, you’re not mapping out your career based upon like “Oh, I’m gonna do these things to get hired somewhere.” You’re sort of choosing your career, or at least your 9-to-5, based upon what you are learning now in your side projects, so you could 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 got to meet and talk to, 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.

[39:56] 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 purple cow moment in yourself, essentially. You’re just trying to keep doing what you do on the side. It sounds like that’s what you’re optimizing for; 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’ve found that if I work on things that most fascinate me and intellectually excite me on my side, it’s always gonna lead to me talking to people that are working on some of the things. With Monocle - it’s a personal search engine. That introduced me to a lot of problems in this sort of like cracked open 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 Google and Bing. There’s a huge space, and I think just building something in it, talking to people about it has opened up a lot of really interesting doors to other people that are working on some of those things, and potentially some people that I might work with in the future.

Break: [41:04]

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 in different locations. Lots of times Adam asks me things like “Where is 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, it’s in my notes app”, or “That’s in HackMD” or “Huh, I wrote about it on Changelog News two months ago.”

Yeah.

We’re gonna get into (I think) sharing at some point, because I think with knowledge it goes beyond the personal and you wanna collaborate or share knowledge… But just my personal knowledge, it just feels like 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’ve 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.

Yeah. So 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, my journal entries over the last few years, and it basically makes it all searchable in a full-text search setting. So I can go to Monocle and I can 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.

[44:13] Like a lot of my projects, this started as a learning project. So Monocle was 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… So once I had that search index working, I was like “Well, what do I wanna search with this?” and so I added my blog… 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 – I bet there’s a lot of companies working on search from like an enterprise perspective, of like search for your team’s documents, or search your Google Docs and Notion in one place, or something… But I think from a personal perspective it’s really interesting, because as you said, Jerod, 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 about information in terms of these products. 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?” And 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.

So 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 “Computer, tell me about this person”, and then it just tells him.

Right, exactly.

He doesn’t have to go stand at the holodeck, or the bridge. Wherever he is, he just says “Computer…”

Yeah. 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 the 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 it with Siri, for example. You have to be specific. “Siri, play X on Spotify”, for example. There’s all these at odds within this 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 wanna 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. Jerod, you’re barely in charge of your notes app. If Apple tomorrow cancelled–

Cancelled my notes?

…you know what I mean – what could you do? You could do nothing, right? You could move notes, but you might have history gone… Who knows. I’m not trying to say that you’re literally not in control, but the balance of power is really in the giants’ hands, for the most part.

I have a good friend who actually had a note disappear. This was a couple of years ago, back before – was it CloudKit that came out? There was 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 to 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. It’s just gone.

A month or two back I said that I messed up my son deleted this whole entire thread of this army buddy I had; my best buddy, my battle buddy in the army… And then we go back ten years, or whenever I got the iPhone, the history has been there, talking about people we’ve known in the military that have either passed away, or something happened, or somebody had a baby… You know, just history, essentially; that’s gone. I’m not in charge of my iMessages even. Like, it’s on my phone, I can back it up, but I can’t restore that single thread… You know, we’re just not in charge or our tools is the point I’m trying to make.

Yeah.

[48:15] Even if we think we are.

Linus is. Linus has all of his tools right there on his laptop.

Yeah.

You actually hit on something that I’ve been thinking about a lot recently… As the driving philosophy for building all my tools and also search is so much over workflows around our data and our information are digital tools are product-focused and company-focused, instead of problem-focused… Which I think is a really eloquent way of putting it.

A great example that I just said earlier is like “I wanna 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 wanna keep users to their product. Apple doesn’t really wanna think about how they integrate with every other thing that you use in your life to keep information organized. And I think one of the benefits of building my own tools is, you know, 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. 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 sort of solving your problem as an incidental kind of benefit to making you me use whatever these companies are building.

Yeah.

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, right? You can go out and tweet, 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 wanna be, wherever you wanna do it at, and you can just index it based upon that. And if you stop using that blog or 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 started thinking 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 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 gonna be dedicated to this practice for years, and Monocle is gonna make it easy because it’s so problem-focused and not product-focused… How can I take an Albert Einstein type person… In 25 years from now or 30 years from now Elon Musk had a Monocle. Could that become public? Could that become public domain, so to speak? Not because we wanna know his secrets, but because we wanna 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 context, our ideas, our tweets? Is that something that you’ve thought about as regards to Monocle?

Definitely. There’s a lot to it. This is getting into sharing knowledge tools space. At a basic level, you can take all of Albert Einstein’s notes, or Elon Musk’s notes, or Marie Curie’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 sort of index it and you can make it searchable, but then people don’t know what to search for. You don’t know – 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 like a suggestion system”, or a thing that sort of shows – you know, maybe I’m browsing the web and it can show me relevant things from not only my stuff, but also notes from your team, or from other people that have lived before. There’s sort of like a hierarchy of features that you can add to make people’s minds and graph some ideas better together.

I think the hard thing about sharing ideas is what I call by one label is not necessarily gonna be exactly what you call by another label. So there’s kind of like a labeling problem.

Yeah.

[52:09] 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 search both. More 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.

Yeah.

The problem there again is - okay, maybe they don’t know that it’s in there. They don’t know what to search for, so you get into more machine learning-driven ways to recommend things. But 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 you elect it.

I know it was.

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, even in real-time, 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 like 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 wanna 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 - I wanna share this with Adam, but not Linus, for example. Or I wanna share this with everybody in this team, except for George, because there’s reasons. Maybe they’re good or bad. But you know what I’m saying? It gets very, very–

He’s too loud.

George is too loud? Be quiet, George.

Get upset.

Yeah. It gets really difficult to actually navigate those paths well.

Monocle is 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 is 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.

Yeah.

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’re committed in some sort of way; there’s some sort of clear boundary between you, the person, and then you the worker or the individual that shows up.

Right.

There’s some sort of offer there. And I think in those scenarios it can be easier to give, but then at what point? 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… 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. Frequently, for example, when I tried to learn something new around – I was looking up a lot of stuff around natural language processing, like a topic, extraction from text, and things like that, I was trying to figure out what I knew already about that subject, and without Monocle, I’d have to go to every data source and perform a bunch of queries and 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… And 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.

[56:21] Or even document more.

Yeah, exactly.

I would imagine you’re far more motivated to put down what you think and know, because in the future what you thought you know you actually knew, and now you wanna know what you knew.

Exactly.

Try to follow that.

[laughs] Can you write that down?

These days when I bookmark something it’s not just “Oh, 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 wanna 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? Because the version I’m seeing at Monocle.search.sh seems like it’s its own version. I don’t think that this blog post that you wrote, the miracle of trust, is – because I just click on your examples and I think the things it searched was actually your name, Linus 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, yeah. So the way that 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 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 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 don’t need to search public sources, essentially.

Yeah.

This is in the index, but it’s search for this – the public version can only see sources that are from there. So do you mean literally scrubbed, or just not searchable? Like, it’s in the database, but maybe it just doesn’t show.

So it’s actually two completely separate indexes. That one only has public data indexes. The one that I have access to - it feels so secretive - nobody else has access to.

He made a face when he said that too, everybody. He’s like, “Hm, I’m so secretive…”

Hah!

It 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 go.

Yeah. And also, it’s so hard to – you know, I don’t wanna 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 Swift, or a particular technology, or Apple…

Taylor Swift, 84 results.

It’s a lot. It’s more than mine.

That’s a lot of tweets. You spend a lot of time tweeting. “I talked about Taylor Swift during this web design lecture, in a Taylor Swift shirt, while playing a Taylor Swift song, working on a demo of a Taylor Swift-themed website. This is my best life.”

Oh, no…

That’s a public tweet by you, my friend…

That is a public tweet… Like it or not.

[laughs] It’s 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, so…

Oh yeah, definitely. It’s to suggest a social reason.

Yeah, exactly.

Actually, one of my other side projects is a quiz that will quiz you on how well you know Taylor Swift lyrics…

[laughs]

Yeah, it’s a good party game.

Are you the only one that takes the quiz?

No. Actually, 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 gonna 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.

[01:00:02.19] There are levels to it. That’s all it is.

There’s always somebody who knows more that you at any particular subject, right? That’s what you find. unless it’s Taylor Swift, then you win. At least on this call.

So with Monocle, this was a personal problem that you saw for yourself, but you must have – and I suppose to some degree you’ve probably shared some of the big ideas you might have released… As you solved this problem maybe your thought process around search and personal information and how you can search your own index has changed. What do you think should happen, not so much based on Monocle, but just understanding the problem more. Do you recommend more people do what you’ve done? You’ve mentioned private vs. 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”, but then maybe “Here’s a public version that like - I don’t mind sharing these things with the world, because I’m a public figure of some sort. I wanna 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 is it evolving for you?

First, just a couple of 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 I tweeted it out, and the tweet kind of became reason to be popular. A lot of people commented in sentiments of the sort of like “Oh, I’ve been wanting to build something like this for the last five years, and it’s cool to see.” And my reaction is like “Well, 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 like a week or two to build…

More than that, actually… Because you built Ink first.

Well, true. But I could have written it using Python, or any other…

You could have.

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? 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 actually 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 “Oh, search is about as good as it’s gonna 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 the web page 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 wanna 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 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 solved problem. How do you search yourself? Darth said a version of this. He said “Search your feelings, you know it to be true”, which - there could be a play on that for naming. So we talked about naming, how it can help you, but… I think that may have ended up in the break, but… There is no true solved product to search yourself. I can’t search myself, what I know, except for my own brain. It’s a non-technical problem. It’s a psychological problem, it’s in my brain to search myself.

Yeah, yeah.

How often do people out there wanna search themselves?

It is a big question. I think something that’s related that Monocle has put in my brain is - think about memory; A lot of viewers a 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 I actually made it my default search engine in my browser. So if I type something into my URL bar and I hit search, it doesn’t search Google anymore, it searches Monocle. And I like to describe it as – you know, Google is 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, so I’m sort of searching myself.

[01:04:06.04] Mm-hm.

So that’s how I’ll tie that into your question… But yeah, you know, memory is more accessible.

There’s something here for sure, because – I mean, 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, or I no longer have that problem anymore, and I think differently… Where I’m like actually motivational to myself, from previous ways I’ve thought; maybe even naive, but still yet wise, and 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, because we had a show around psychology and habit formation and different stuff, and I’ve actually 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 a search engine to reveal those answers to me anymore. I have to 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 have 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, I 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 remember the article, but I don’t remember that this was a part of the article; so it made that connection.

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. 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 color green - or to leaves, or a forest, all those things - is 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 through the forest, because that path was retraced. There’s a new push into graph that’s stronger now.

Yeah. That actually reminds me of a really interesting question when you 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 create a bubble of 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’ve put this out there, even though it’s built for you… You said you wanna 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 Bolous 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’ve put this on Changelog News.

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, and he says Monocle right there. So I no longer had to wonder if that was inspired by Monocle; it sure was. So at least one person is 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?

[01:08:17.18] Yeah, I think that’s awesome. So Amir and I have actually spoken on Twitter before. We’ve talked about various projects, and did 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 reimplementation of what I’ve 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 wanna 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 pilot pages that you can search later, instead of everything that you’ve ever done or everything on the web. So there’s a slight difference there.

Doesn’t yours also index the pages that you’re bookmarking, though?

Yeah, that sounds right.

So it’s a slice of yours; a focused 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 gonna find new, interesting tools. So I think that’s great.

I love that Apollo is very Google-esque in terms of the colors… It’s old school, at least on the visual interface, but it’s paying some sort of homage to Google. It 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 similar vein to Rasmus Andersson, 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 if I wanna build something like it, what’s the first step? How complicated could it be? Have your default assumption “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 for joining us. It’s been awesome having you.

Yeah, of course. Thanks for having me.