Programming is the best! We're chatting with Thorsten Ball (self-published author of Writing an Interpreter in Go and Writing a Compiler in Go) about all of our mutual favorite topics: learning new stuff, great textbooks, writing, and why bugs are actually great (a gift, even!).
Shownotes
Shownotes
- Writing an Interpreter in Go (Thorsten's book):
- Writing a Compiler in Go (Thorsten's book)
- The Dragon Book (compilers)
- Thorsten's newsletter:
- Thorsten's website
- Zed.dev
- Sourcegraph
Creators & Guests
Host
What is The CS Primer Show?
A show about computer science and computer science education by Charlie Harrington and Oz Nova.
All right. What I was about to say is, I fully agree that idiosyncrasy or different perspectives
on learning are really important. I've only come to realize this in the past few years, I think,
in that, you know, the more you learn or teach yourself or things you read, the more you realize,
you know, like, you read five books on a topic, and maybe the first four don't click. And then
the fifth one, for whatever reason, you cannot even point it out, you cannot even say, oh, this
does, you know, whatever. But it's just a slight shift in perspective that this book gives you. And
that suddenly makes things click, right? Recent example, this week, I was trying to learn Flexbox,
you know, just out of curiosity. So I tweeted about this a couple weeks back, and people were
sending me all of these links. And they said, look at this, try this, read this. And they were all,
you know, the ultimate guide to Flexbox, you know, the Flexbox cheat sheet whatsoever. And everybody
was saying, I swear by this, and they were all different. So I read through, I think, three or
four. And the first two, oh, yeah, I think I'm starting to get it. But then the third one was
this interactive tutorial. And they just explained it in a way that immediately clicked with me from,
I don't want to say first principle,
but where others, for example, they, they kind of skipped over the names, they said, oh, this is
justify content. And this is a line items, and this does this, and this does that. But the third
person, they were like, this is called this, because here's the underlying mental model.
This is called this because of so and so. And that just made it click for me. And it's again,
three different people having the same goal. I'm going to explain Flexbox once and for all.
ending up with completely different explanations. And now thanks to the internet, I can flip through,
you know, the teachers and can see which one clicks for me.
So do you think if you had landed, if you had landed on that third one right away,
would that have been sufficient? Or was it you were sort of introduced to a few different ways?
You knew the terms? Yeah. It's interesting.
I think I think the third one was I think, yeah, I would have gone further with the if I had started
with the third one. And that's because it's just, you know, sometimes you read something. And while
reading, you have these questions pop up, what does this mean? What does this mean? Blah, blah,
blah, blah. And then sometimes you read something. And every time a question like this pops up,
the author answers it in the next paragraph. It's just I think it's, you know, some minds work like
this, and other minds work like this. Some person needs a comparison to math, another person
needs a comparison to physics, you know, something else. And for me, it's basically,
I don't know, specific way of explaining things from the ground up, I guess.
It's funny that you mentioned Flexbox specifically in this context,
because I feel like weirdly Flexbox is like, just this really rich domain of
people exploring different ways of explanation. Like there's Flexbox froggy,
there's like a Flexbox game that you shoot zombies and stuff. And then obviously, people try to write
the one definitive medium article. It's just like, people are going to study Flexbox teaching as a
kind of pedagogical vein. So can you at this point, I was gonna say, can you send her a div now?
I think I could look up how to do it. I think people say this is how you send her a div. I
think I could look it up now. Yeah, justify content center. I don't know, something, something.
Yeah. So were you, did you have this kind of feeling while you were writing your books?
Like, did you feel like you needed to express your way of teaching this subject matter to a particular
kind of audience? Or were you trying to make the one true, you know, text in this field?
The first one, I think,
um,
you know, I'm looking at these books, Apple, Modern Compiler Implementation in ML,
Engineering Compiler. What else? Dragon Book down there. I think, whenever I read them or
try to read them, and I haven't read the Dragon Book, you know, just bits and pieces. But whenever
I tried to read it, I just couldn't get into a groove where I thought we're on the same wavelength,
it was always, I'm missing something, something here does not add up. Why do we do this? What's
important? What's the ultimate goal here? Why would this be a thing? And I found that
there was a lot of other resources, blog posts, you know, tutorials, as you call them,
um, that were completely opposite end of the spectrum. And they would explain, let's build a
little toy interpreter, let's build a little toy, you know, language. And the goal was clear. The
goal was let's build this, look, we can type in eight times four, whatever, plus three, look,
you know, how it uses the operators and whatnot, and the correct result comes out.
But I was missing things in the middle that explained, you know, here's, here's what we want to
do. Here's why we do this to reach this goal. And here's how to do it. And to give you a concrete
example, this, this, um, I can't get the full title. I can't remember the exact title, but you,
I'm sure, you know, this paper, the one paper, an incremental approach to compiler construction,
building a scheme in x86, something, it's only four pages where, you know, author explains how
to build a little scheme compiler in.
Scheme, obviously, in just four pages, and they were saying, you just stop with the primitives,
you move this and register it. Now we have numbers, now we do this. And online, everybody
was saying, read this paper, this paper, this is so simple, build a scheme in scheme, build a scheme
to x86 compiler in scheme, so simple. But I was reading this, and it was just, you know, every
little paragraph felt to me like the meme of draw the rest of the owl, like, oh, yeah, you
want to do numbers, just move the number into the register, you're done. And for me was, what,
now we do strings. And then it would, for example, say, actually, let's, I don't know if it says this
specifically like this, but it would say, we have to allocate them on the heap, right? And I would
sit there go, why do we have to allocate? Why? Why do we have to do this? So then I found another
resource where a person was implementing, like they had a full implementation of this paper, and
like the full code and not just the snippets and like the brushed off, you know, fill in the details,
but the full thing. And just reading through this and comparing it, I could suddenly, oh,
make sense and see. So this is why you do this. Okay, if we have this, this is what they meant
with that. And I had many of these experiences. And I thought, you know, wouldn't it be great
if somebody took all of the bits and pieces and without saying, let's skip over this,
or let's skip over that, just compiled them in a straightforward way. And, and, you know,
put it in a resource like a book or tutorial, whatever. And yeah, I guess that's what I did.
And now looking back, I mean, it's been six, no, it's been eight, eight years, Jesus. But
it's been a while. But looking back, I realized that even when I was I was 14 years old, I was
writing tutorials on online, you know, forums, like how to use, for example, I think the first
one I wrote was how do you screen on a Unix machine, you know, the precursor to tmux. And
like all of these tutorials, and I always love this approach this, here's what we want to do.
And back then, you know, common thing was Photoshop tutorials, you know, everybody had their pirated
copy of Photoshop six, and then all you want to use this, you know, you want to do a logo like this.
So here's how you do it. And it's step by step, nothing left out. And then you could basically
follow up and you could go inside quest and find out why certain things work the way they want. And
when you follow step by step, you always have the option to pause and kind of explore on your own,
right? You're in step six of 10, doing something in Photoshop, you can just
continue and play around and you know, fiddle with the controls and see what happens. So
I'm saying this, because looking back, it, it seems like it, maybe one thing led to not another,
like even 15 years later, but that I really like this style of learning this. Show me something.
And feed me enough information to, to help me along, but leave me room to find my own, you know,
to pull in more information as I see fit. Yeah, I, to me, it feels like leaving those breadcrumb trails
that you can go down, the sort of err text that you're going, that four page thing, it didn't do
enough in that regard. Yeah. And you also, I feel like there's a failure mode where it explains
literally everything. And you don't get to explore it on your own. And I think Oz, you do a really
good job of advocating for people to say, like, when you come to a point in a textbook, you should
maybe like put your hands over it and block and think about what it's gonna say next, rather than
just reading the full thing. Because I know I've read, I did this great book, how to make a dungeon
crawler in rust. And it, I went through the whole book and I had an awesome game at the end. And I
don't know that I, I don't certainly don't remember how to write rust. And this was like a two years
ago or something like that. And I think I was just too, I wasn't going on the side quest enough. It
was just, oh, I wanna make my character do X, Y, and Z. And I sort of linearly went through it
where I wasn't really going, doing that recursive backtracking. I wasn't going on the side quest
cuz I was just flipping through and making progress. And I don't think it stuck. It, it did not stick.
Yeah. My favorite example of that is Balaji Srinivasan. His approach is to just do the
problems at the end of the chapter before looking at the chapter. It's like, I've got a textbook,
it's got exercises, whatever problems at the end, I'll just attempt the problems.
Maybe I'm gonna figure them out and maybe like I can skip reading the chapter if I,
if I do that, or maybe I'm gonna figure it out and then look at how the author
suggests doing it. Or, uh, maybe I'm not gonna figure it out, but that's gonna motivate me to
actually go through that material. And now I know, uh, that this is what I'm going to be able to do
at the end, like, because I've made an earnest, uh, attempt at that already. Uh, and you know,
in terms of like picking up different areas of particularly science in his case, uh, he was just
like a machine. He just like worked, worked through this stuff. And, uh, he was always like, you'd be
surprised what you can already do. Like you could, you'd be surprised what you can take from one field
and apply it to another or what you might already know. And like this, this exercise is worth more
than the kind of revealing aspect of it. It's super interesting because to me,
I know that doing the exercises is I think the most beneficial way of learning because you just,
you know, repeat what you learned. You actually put it
to use.
Into, you know, into exercise. And I did this with, um, uh, structured interpretation of computer
programs. And I, I have to admit, I skipped a lot of the super mathy stuff, but a lot of the
other things, implement your own map, implement your own fold, stuff like this. Um, I think that
was really nice, but in general, and this is purely me and it might be related to, you know,
school whatsoever, but I.
Hate exercises in books because to me, it's,
they create this weird sense of expectation and pressure. And I feel like it's a, it feels like
a test to me. Oh, you read this chapter proof, you know, prove that you actually read this and
that you understood it. And it, I just, you know, shriek away from this. I think I don't want,
I don't want this because the best way for me or to get me to do something would be not to say,
Torsten, I want you to do something. It would basically be to look somewhere else and say,
it sure would be nice if someone could, or. I bet nobody can do this, but Hey, no pressure,
you know, something like this. And it's, yeah, I, I, I had the same feeling, I think because
of school, because we were always given specific exercises from the book to do a lot of the time,
they were bad. Like they weren't actually a good representation of the skill that we were trying to
learn. Uh, but part of what biology is saying is that like, you're going through this process for
yourself of deciding whether you want to engage with this book based on what you're going to be
able to do at the end. And so if you look at those exercises and you have this recoil effect of like,
I don't, I don't want to do this or like, this isn't what I'm trying to learn, then maybe that's
not the book for you. Uh, like maybe, you know, maybe you should come up with your own exercise
and find your own.
Resource or whatever. Well, like you look at the exercises and you see, I kind of get where
they're getting at. I'm not excited about that particular thing, but I'll do this instead. Like,
I don't want to write an interpreter just for fun to see if I can do it, but I want to do it as a,
you know, tech set at a plugin or whatever. Um, so I'm going to do that. And that's a close enough
approximation and I'll attempt it. And I'll know that I can go to this chapter as a resource. Like
if I get stuck, that's exactly that. That will be the perfect mode of learning for me as in,
um, and just to stop a little bit on this part, because you said experience in school. And now
that you said it, I think my problem with these exercises is that maybe it's because of school
books and whatnot, but whenever I read exercises or I guess I don't read them anymore, I skipped
them. But whenever I did read them, it was always this feeling of you don't want the answer. You
want me to know this specific thing that you try to get out of this question.
It's, you know, there might even be a trick in there where, oh, you know, this reads like the
answer is obviously this, but you wouldn't have put this as an exercise if it was this easy. So
then I feel tricked. I don't know what it is. It might be because of school and my experience in
school. I wasn't a great, I didn't get good grades, but everybody told me, not everybody,
but a few teachers told me you're pretty smart. You should have gotten better grades if you were,
you know, so lazy whatsoever. But to me, it
always felt a little bit off. So my perfect mode of learning is exactly what you said. It's,
for example, right now I'm interested in, I have this itch to really understand how
terminals work. Like I know just enough right now. I know the syscall, the open TTY. I know
about the file descriptors. I know roughly what's going on, but I don't really know
how it works. So my perfect mode of learning this would be somebody gives me, say,
whatever, 60, 80 pages, something. Here's how to build a terminal emulator.
And I would read this, but, you know, not retain all of it. And then I would go and try to build my
own, you know, fully assured, you know, I didn't have to pass a test. Now it's all on my own. I
can do whatever I want. I'm going to write a terminal emulator. And when I get stuck,
I can always go back and consult the book, which is what I would do, you know, after the first
page of code immediately go back and look up, what did I do here? And then it would start for
me where I would, you know, put the pieces together and actually understand it. I was
hoping you were going to say you would get a vintage teletype and start with that and try
to make it work. Yeah, that's also a good point, right? This, not to go on a tangent here,
but I think this, especially with technology, a super interesting path or
what I always try to do is strip away all of the, the modern stuff or say the fluff and try to see
what's the basic thing here. What's the, what's the purest abstraction, the purest mental model
of problem solution, and then build up and see, oh, so that's why they added this. That's why
they added this. So. So have you been, you've been working on a terminal emulator, but ghosty,
right? A little bit. Yeah. Okay. Well, yeah. Hacking a little bit. Hacking a little bit. Okay.
But it was enough to say like, okay, I want to keep going deeper in this area.
Yeah. So, so ghosty is this terminal that Mitchell Hashimoto built and it's cross platform and he
built a whole thing from scratch in Zig. And I was, I was just hooked by how different it was
from what I usually do. I mean, you know, I usually do or did for the last years, developer tools,
and systems program whatsoever, but I've never done any native development. I've never done a
Swift app. I've never done a, you know, GTK app, nothing like this. So then when he asked me what I
want to try it out, you know, I used it for the first time and I, I needed this, it's called the
non-native full screen in MacOS, which is I think, I don't know, from older MacOS version where the
work hides whatsoever. And I said, I need this. And, you know, then I thought there's no expectations.
I can maybe take a stab at this, you know, maybe I can boot up Xcode and see if I can write some
Swift and whatnot. And that's when I started to do this, but I never, I then added some more fixes
and did some stuff on the GTK side, like splits and GTK and the, in the Linux version. But I never
got down to the core.
The actual, you know, control characters and whatsoever. That's, you know, I kind of, again,
I roughly know what's going on, but it's now this, my mini map of knowledge, you know, there's like
these black circles and it would feel so satisfying to just go over there and also uncover those and
see, you know, that's what happens. And now that I work on Zed, the text editor has a built-in terminal,
but it uses, uh, because it's written in Rust, it uses alacrity, which is also terminal emulator.
And that's written in Rust. And we were getting, uh, panic reports, crashes from users because
bad file descriptor to open TTY syscall produced the file descriptor that was then invalid
when you wanted to poll on it. And so read through the code areas.
Oh, okay. Open TTY. So that's how you do this. And then you spawn the shell and you connect it to this.
But you know, just enough so that I'm now thinking, I kind of know where to look,
but I don't know how it fits together. And that to me is this, the sweetest spot where you,
where you could sit down and you know exactly where to look and what to, what to Google,
what to search for and what to piece together.
Well, as you always talk about this, where, uh, explore your curiosity on these
bug reports and these, you know, going through Sentry and like actually, you know, not just
automatically muting everything and seeing if something looks interesting. And that's this
amazing opportunity at work to learn. So that's cool that you, uh, you know, have this itch and
it's already something that's like cropping up in your workspace. That's amazing.
Every bug is a gift. Every bug is a gift.
Not all of them, but like selfishly as someone who's trying to learn something, every bug is a motivating example.
Right. It's like an opportunity to say, Hey, I was wrong about something. We were wrong about
something. Let's like get to a better understanding. Now, obviously under the pressures of work, you
know, you only have so much time, you're stressed, whatever. It's a shame that we don't have the
ability to pursue that opportunity. But like, at least like, I mean, I wouldn't say it like that
unless it was a little bit wrong, but there is something there. Like it is true that if you could
modify your
mentality a little bit to not get so stressed about the bug and say, Hey, this is, this is great,
because if everything was going well, I would have fewer opportunities to learn about this.
Now I have this really specific, um, motivating problem. Uh, and it's an opportunity for me to
learn, not easy necessarily to switch your mindset to that. But like people like Mitchell, I feel like
a very good at this, where it's like this, now this thing is slow. Fantastic. I get an opportunity to
figure out how to optimize this thing. If I were doing that in the abstract, I wouldn't care so
much, but right now I'm trying to make this thing right now fast. I'm trying to fix this bug right
now. Uh, that like software engineers who can foster that mentality, I feel like are constantly
learning no matter the context, like the task can be easy or hard or whatever. Uh, some people will
ignore a bug. Some people will like, yeah. I feel like I love bugs. I love bugs because
it's such a binary thing. You either fix it or you didn't, you know, what I don't like is Greenfield.
Hey, you know, what can we do next? What's the next, you know, I don't like that because it's
so arbitrary. You have to come up with things. You have to test stuff. A bug is here's the bug report.
This does not work, make it work. It's the ultimate puzzle. So I've been now at Zed for five weeks or
six weeks. And I just hop on bugs because it's such a good way to learn too, where you not only
understand how the system works, but trying to reproduce it, right? That's the first thing. But
also then you jump around the code base, trying to figure out where does it come from, but then you
also have different bugs. So you jump to through different parts of the code base and you also see
which code was written by whom and why and when, and how you get some historical perspective too,
so I, you know, I actually really like doing this. I think the most, the problem or the downsides that
I can think of is there's some bugs that upon closer inspection turn out to not be bugs. And
then you end up with what should we do? You know, what's the desired behavior here? Is this our bug?
Is this a user bug? Do we have to accommodate for them? Can we even fix this? Does this happen again?
Just brush it under the, you know, brush it aside. And the second thing is, you know, Mitchell,
for example, he has this, you know, I guess, I don't know, I don't know,
I don't know how his inner life works here. But I think sometimes you're faced with bugs,
where I go into this mode of I can invest time to fully understand what's going on.
But you, you feel the clock ticking, and you go, I spent four hours on this, like you said,
pressure of work, I need to put a bandaid on and you start to feel bad about this,
because you know, it could be a good way to solve this.
And then it's all these mind games, like, will I ever fix this puzzle? Will I ever figure out the
right solution? Can I do the proper solution? Or do I put a solution on even though I don't fully understand it?
But yeah, in general, it would be nice if somebody were to create, say, you know,
learning resource, and it's just debugging, you know, every chapter is about here, fix this,
it will be a tremendous amount of work. But, you know, say, say you have, I don't know, you have a
terminal emulator, and you put bugs in it. And then you ask people, hey, when I type this, this
happens, it shouldn't, it shouldn't.
It shouldn't crash like this. You couldn't start with crashes, you know, stuff like this. Why is this no?
And then I've definitely seen the failing unit test approach, which is nice. And you get that
sense of progress and things. I wanted to jump on the comment about Greenfield and things like that.
I sort of feel like, I hear from a lot of programmers that they don't want to just
be ticket takers, and it feels like an automaton in some sense.
And they want to be shaping the product in some way, which of course, like you can find
different ways to do that. But is that, how does that play out in terms of if you were given a
project where it's like, hey, we need to build this new feature, you need to dive into that.
And there's all this customer discovery. Do you, you know, how, what's your reaction to
that in terms of how you orient your work life? It's an eternal struggle in that.
I think, you know, if, if you would leave aside career prospects, titles,
roles, whatever, all of this, maybe this is maybe this is wrong. But I guess if you leave all of this
aside, and just think about the moment, I would be happy just fixing bugs, because it's so
interesting and so satisfying. And for some bugs, you can really pull out the big guns with your
debugging tools and go crazy. And it's just, it's nice engineering. It's I like this, I like fixing
things, I like making things more efficient, I like making things more, you know, better,
I like making nice things. And that's, you know, why I don't prefer Greenfield projects. But in
my career, so far, I also worked on a lot of these Greenfield projects. And I'm also relatively good
at it, at shipping an MVP, or building the thing that customer wants, I have a lot of,
you know, customer empathy, and building the thing that actually, you know, I don't have this
engineering, say, I don't want to say disease, but you know, this building something that actually
doesn't solve a problem. I don't have this when it's not for my own curiosity, I get demotivated
super quickly when I build something that nobody uses. It's that's the worst to me. Which again, a
bug is,
has validation that somebody uses it, right? Otherwise, it wouldn't be a bug.
Can I say something about this as well that I've been thinking about?
I think that the, the distinction between maintenance and creation from scratch is
pretty arbitrary. And the people who are good at maintaining existing systems are thoughtful about
how systems should be designed in the first place. It's like, let's say you spend the first
10 years of your career doing the implementation work behind someone else's API, like you've
inherited an API, and you need to maintain it for compatibility. But you know, you work behind it,
like constantly, if you're thoughtful about it, despite the fact that you're doing maintenance
work, bug fixes, whatever behind the API, you're thinking about what the API has cost you,
like the impact of the API on the implementation. And so when you go and design an API,
you're in a better position than someone who like specializes, whatever, in
designing the API, like you're thoughtful about this thing. And to me, it connects with the concept
of being an engineer, like we call ourselves software engineers, we should think of what it
means to be an engineer. An engineer is literally someone who works with an engine, at least
originally, right? It's like this, the person who is running, maintaining the engine. Like that,
you know, imagine tinkering with a car engine, it's like, you didn't necessarily build it.
But over time, engineers did build the next engine, like engineers, the
people who are maintaining the engines are building the next engine, because they're the
ones who are intimately aware of how the old one was breaking. To me, in software, React is such a
good example of this. It's like, you can have one state management bug after another, and think of
them as isolated things and say, "Hey, I fixed this." Like, it was showing 300 messages in the
counts, but when you clicked in it, it was only showing 200 messages or whatever,
how do we get this state mismatch? Okay, we fixed this. Then you have another problem with
another state management issue. Like at some point, if you're thoughtful about it, you say,
"We are having state management issues, not we are having 100 message count issues." And you like,
step aside and say, "Well, what if we reconsidered how we actually declare our rendering of state?"
Like, that's a very fundamental, really innovation, I would say, in how people started developing their
front-end code. At least innovation in the context of JavaScript, right? And that was through kind of
bug fixing. Thoughtful bug fixing led to a new design. That is engineering, in my mind. Not
just fixing the bugs, but eradicating them through fundamental design improvements.
I agree. I think that's a really interesting thought. Because I think, just to add another
thought to this,
innovation, in my experience, doesn't look like innovation from up close.
It just often looks like marginal improvements. Step function is something. You make something
slightly better, more efficient, and you accumulate these little steps, and then suddenly, look,
you know, we made our computer one millimeter thinner. And then 10 years later, look, you can
now carry it around.
with you and it runs the whole day or something like this. And I think there's this lure of,
"Oh, it's Greenfield. It's new. We can do anything we want." And that's where the innovation is.
Because, you know, an empty room and the light bulb goes on, there's the big idea. That's innovation.
But like you said, to me, the engineering aspect is
building something
that's fit to a purpose and to the requirements with the correct trade-offs.
And you won't get it right on the first attempt. So you have to kind of optimize and tweak and make
it more efficient and polish here and there and move something around. Or even take a step back.
And like you said, say, "This whole part doesn't work." Like, it just, you know, listen to this.
Like, that's not a good sound. It shouldn't make this sound. We have to take this part out. And then,
you switch that part out and suddenly it looks like you invented a whole new thing. But it came
from the steady analysis or the steady, you know, putting your ear to the thing and tweaking it
slightly and understanding it, learning with it. Yeah, I don't know. I'm rambling, but it's just…
The word that's coming to mind for me is integration. It's this integration of maintenance
with understanding that seems to actually allow you to sort of have these informed decisions,
which is a nice way to think about one's career mindset. I had kind of a, I don't know if this is
like a fluffier question, Torsten, but, you know, I recently went through a job search. I know you
just switched jobs and things like that. And my observation of you on Twitter and with Register
Spill, your newsletter, I get the sense that you love being a software engineer. And I imagine if
you could write this book, I know there's the joy of cooking for cooking. I could see you doing the,
like the joy of programming. I don't know if that makes sense. But that's my perspective. And I'm
just curious if that resonates with you. I sort of, I personally sort of feel very lucky to have
found myself into this career, but what is, you know, as you view the next X years of your career
in life, like is that love of programming seems to me from the outside to be a big piece of how you
think about, you know, what you're working on? Yeah, that's, you're trying to get me to not shut
up for 30 minutes, right? Yeah.
No, please go ahead.
I think, I think, yeah, I, I do love it. You know, I, I love it. And it's,
let me order my thoughts here. But
I was talking with a friend two days ago, actually, about this. And he said,
man, you know, I had a conversation with him a couple months back, and he's an engineering manager.
He was a software engineer before. And then he read one of my newsletters. And he said, man,
I think you kind of sparked to join me again for technology or developing stuff. And then he was
talking about, you know, oh, yeah, this would be this, and this will be that. And but then he had
this thing telling him, yeah, but that's, I also want to do this. I also want to do that. And I
said, Yeah, you know, I don't have that I like to do this, I really, I like to get better at this,
I like learning about its history, I like talking to other engineers, you know,
this is a good Friday evening for me, they're having this conversation, you know.
And that's just now looking back, when people say to me at work, you know, you motivate the
team, or you bring the team together, or you get others fired up. I always thought that's weird,
because doesn't everybody, you know, feel this like, what, and then I realized it's the way I
talk about things or the joy I spread or whatsoever. And to me, again, I said, I don't have
ordered thoughts. But I like sitting in front of a computer. I like working with computers. I like
having a good computer. I like, I think it's mind blowing that I can talk to you one in Australia,
one in the US, on a Friday evening, through computers. And that net magic never went away
for me. Sometimes I get this little blip where I sit in front of a computer on a Thursday afternoon
at 3pm. And you know, it's like a lens flips down in front of me, and I can see, oh, so maybe this
is how I just see this, they see this as I just sit in front of a screen and type characters into
a text editor. But for me, that's not it. For me, it's, look at the color scheme, look at this
language here, look at what this other person that I'm working with, their micro decisions,
look at how they debug things. Why did they formulate the git commit message this way?
Why did they notice? I bet they learn it like, you know, something like this. It's
endlessly fascinating to me. And I don't know, like, that's, that's, I realized last year, I became,
I became a manager, engineering manager. And it was, I wouldn't say out of boredom,
but out of necessity, one thing, we didn't have an engineering manager.
But then I thought, you know, should I become an engineering manager? Should I not? And somebody
said, why not? You know, now's the best time to try it out. And I thought, yeah, it is.
Because, you know, the company, trust me, Sourcegraph, I have, you know, I know everybody
there. I like everybody there. They trust me to do this. I don't go and search a different job and
say, I want to start as an engineering manager without ever having done it before. So everything
was aligned. And then I always thought, but isn't there more? Like, don't I have to learn more? Don't
I have to learn more? But over the past few years, people would say, you know, Torsten, you're the
senior guy now, you're the staff engineer now, you have to teach the others, they look up to you,
you know. And then somebody said, man, like, there's not much else left, you pretty much got
it figured out, you know, you can switch to management and, you know, there's nothing else.
And over the next, what is it, 10 months or something, I realized, no, like,
there's this whole world, there's so many worlds still out there that I haven't explored,
you know, GPU-based programming, native programming, not even, never touched games,
programming, that didn't even come close to this, you know, the financial stuff, all of this. And
it's still fascinating. It's like, you know, you're done playing your game. And then somebody
else says, here's the expansion packs. Now you can go and do this. So now I'm at Zed, and it's native
app, high performance, GPU accelerated. And I'm walking around like a kid in a candy shop thinking,
I get to explore this code base with really good programmers and talk to them all day long. And
they explain to me how they think about problems. And I get to be the dumb guy again, and ask all of
these questions. You know, I don't want to say because it's recorded, but sometimes I think,
should I pay them, you know, like. Yeah, yeah. If the founders listen this far,
I'm sure they'll have a chuckle with that. Yeah.
Yeah. But I don't know. I don't know. This only dawned on me in the last few years where people
would say this, or you would see people fall away that started with me 10 years ago. I met
them at conferences. They also started programming. And I don't want to say they dropped off like
flies, but they, you know, kind of lost interest after five, six years, and they stopped learning
new things. They, you know, became a manager or did something else or still doing the same thing.
And then I realized, no, if you just keep going, there's this whole other thing that you can breach,
you can push through. And now, you know, you're a senior engineer, you've done a lot of things,
you've done a lot of things many times. So you have these muscles all trained. So now you get
to actually use those muscles and use them in different contexts. And then you have this whole
meta game going on where you think, well, I solved this problem five times before, but now I'm at a
new company, look how they solve it. What are the trade-offs here? How does this compare? So all of
this to say, yes, I do love this. I do love this very much. I find it endlessly fascinating. I can
talk about it all day. Yeah. I love that view of you on Thursday afternoon, like over your shoulder.
I'm imagining, I don't know if you played Mario 64, but there's that little Lakitu guy with the
little camera hanging down. Who's this is a video game Oz. And yeah, I was not a gamer. I also
stopped in like 1996, but he's falling and panning around. And sometimes you see him,
I use this when I'm on a long run and I sort of say, okay, imagine you're Mario and you're
like the Lakitu guy going, and that helps me get into flow. But I think in your case,
what's missing from that is it looks like Torsten's just staring at a screen,
maybe occasionally moving his fingers and you're not seeing that sort of mind meld flow thing.
That's another thing Oz and I are always talking about that, the concept of flow and finding that
flow. So yeah, it's, I feel the same way. And I also was an engineering manager at my last company.
I sort of evolved into that and I've now moved back more towards hands on the machine and it just,
I'm already feeling the joy of that again. So that's important. Yeah.
And I guess, I don't know. Sorry.
Yeah.
I don't know if it's my age in that, you know, I grew up with the internet and you can see,
you know, you can see it start to take, like, you can see all of these dreams,
what's actually happening, where, when I was, you know, when friend and I, we were 14, 15, and
we would think it would be nice to have internet access here, you know, something like this. And
now it's everywhere. You have it on your phone. And now when I, I sit in meetings
and there's 10 people editing the same Google doc and you see the curses move around and there's
people sitting in India, sitting in the US, sitting in Germany, Australia,
that's,
that's mind blowing. Like, how can you not find this magical, that this is possible that this
works this well. Well, maybe you had to go through that evolution and I, I don't know.
Yeah. Yeah. Maybe. Yeah. Yeah. Yeah. Cause I was thinking about this with video games. Cause I
still in this room, I have my original Nintendo and then super Nintendo and N64. And I had this
very dumb idea where I was thinking, oh, I'm gonna introduce my kids to video games in order.
So I'll give them a regular Nintendo.
And then two years later, I'll say we got this new thing. It's super Nintendo. Look at the graphic.
And of course that'll never work, but I don't know. And then just the, the, the bad side of
nostalgia, um, coming to come in and bite me. And I guess, you know, the other thing I do like
writing, I've always been always, I've been a long time reader read a lot as a kid and reading to me is also something
magical in that you can teleport yourself into someone's head, right? You, you write something,
they sit down, they lie down on their bed and they read what you wrote and you have a communication
with them through space and time, right? You could have written it a hundred years ago or 200 years
ago. And that is a fascination. Writing is a fascination and look at programming, you know,
where people say the abstraction is the
machine, you know, like the code describes the actual thing. It's not just that it is the thing,
you know, the idea is the thing. There's no other thing. The ideas that you encode in text,
that's the thing, like all of these, you know, meta thoughts, these abstract thoughts combined
with writing, with sitting there, thinking, communicating with others, having a machine
executed and the machine basically testing your understanding of what you put into words,
you know, that's, I don't know, it's nice. It's really stimulating. And the last thing,
and then I'll shut up. But the last thing is I noticed
when I started to pick up programming again, I programmed as a teenager,
then I stopped and tried to become a musician and play guitar.
And I would say I did have a knack for guitar or I got compliments and whatnot,
but when I then went back to computers and started programming again, I realized
I can practice programming all day long. I can practice sitting in front of the computer and
doing something with the computer all day long. I don't like practicing guitar, but sitting in
front of the computer and trying to figure out why this does not work, this app, I can do this for
eight hours.
Like, it's not an issue to me. You don't need to motivate me even. If you give me the buck and say,
why doesn't this start up? Can you figure this out? I will have all the motivation I need. And
then I realized, maybe this is my poison, you know, maybe this is the thing that I should do,
because I do enjoy getting better at it and I don't mind the practice. And I think Jerry Seinfeld had a line,
on the Tim Ferriss podcast, I wish I could quote it, but he said something along the lines of,
"Everybody has their own poison or their own pain that they can endure, and you have to find the
thing that you can endure." And for comedians, you know, in his case, I think it's writing is hard,
going on stage is hard, bombing is hard, not having a bit that works. But if you found this to be your
poison, then you're hooked, and then you try and get better at it. And for me, it's, you know, sitting
in front of computers and trying to get better at programming.
To what degree do you think that this is encoded in a person? Like, are they born with it? Do they
develop it at five? Is it a function of their first work experience or something? Like, to what
degree is it malleable?
I think now having, you know, I have a six and
a two year old, I do think there's something that you're born with in that my older daughter,
for example, she has no interest in figuring out how stuff works. Like you can install, we install
the AC in her room, and she didn't notice. She's like, "Oh, yeah, there's another thing." My friend's
son,
he came by, and he's like, "What is this? Where does this wire lead? Let's go outside. I want to
check this. How does this work? So what does this do? Where does it do that? Where does this come
from? Why does it only do this?" He's the guy who picks up the remote control and, "Oh, I got it
figured out." And that was me as a kid. Back then, they would sit me in front of a computer with
Windows 3.1 or DOS or whatever, and you just, what, type? Like, "Oh, here, look, I can change the
prompt in MS-DOS."
And just sit all day there and try and figure out how this works. I would take my toys apart and see
whether I can. And I don't know where that comes from. I don't know. But I do know that my parents
encouraged me, "Yes, please use the computer." They didn't encourage me to get a video console. They
always said, "No video consoles in the house, but you can use the computer." And then I realized-
That you can get games on the computer.
Yeah, well, that too. But also, early on, I realized that this is a level playing field,
because I'm eight years old and my parents asked me for advice on how to do something
with the computer. And you realize, "Oh, I can get better on my own with this."
And then it just went from there. But I don't know. I would say you have something, but that's,
I think that one thing is your unique perspective on it. And I think that can be different for a lot
of people. I think there's some fantastic programmers who have a completely different
view on programming and computers than I have. And for me, a good Sunday morning would be to tweak my
.files, whatever. I like that. Or setting up a Linux machine or Raspberry Pi, whatever. For
others, absolutely not. They don't care about anything. They don't care about it. They don't care
about any of this. They don't have a fascination with that. They do have a different fascination,
which is abstract thought, math, whatever. So this bit is interchangeable. But then I think,
apart from that, you have to kind of put things within reach for that thing to hold onto. And for
me, it was computers and the rise of the internet and the excitement, like the late '90s. Every
four weeks, there was a new, faster CPU coming out, TV commercials for the new Pentium 3, whatever.
This is why The Matrix said they picked 1999 as the optimal time for humanity. And that's why
they were looping in that time, I believe. Do they say that in the movie? Yeah.
I'm pretty sure. Certainly, 20 years later, when the robots took over,
that probably wouldn't have been ideal to be running in the simulation. Gang, I got to run.
No worries. But this was amazing. Torsten, we'd love to have you back on. I feel like I want to
pick your brain on... Oz and I have been mulling over some things around what a striped press for
kids would look like. I think that'd be really fun. But this was great. Cool.
Yeah, this was a lot of fun, man. I could have talked for longer than this. I appreciate it.
We'll be back. All right. Bye-bye.
Bye-bye. Thanks, guys.