Christoph: [00:00:00] I think the, the whole idea is that obviously I wanna do more things that I love, but it looks to me like game development is somewhat broken and I feel like the web has some of the answers, not all of them.
Definitely. Um, and so the ideal outcome in the end would be to just kind of more democratize, like making games and like making it much easier to build games
Justin: hi folks, before we start, I'd like to remind you that our full episode is only available to our paid subscribers. You can support us by subscribing on Patreon, Spotify, or apple podcasts in the full version of this episode we
Andrew: Hello, welcome to the DevTools.fm podcast, this podcast about developer tools and the people who make 'em. I'm Andrew, and this is my co-host Justin.
Justin: Hey everyone. Um, I'm really, really, really excited to have Christoph Nakazawa on as our guest today. Christoph has done a lot of just prolific tool building over his career. [00:01:00] So Christoff, you've been involved in what? Like moo-tools, yarn, Metro bundler, jest like the list goes on. Super excited to talk about that and to talk about what you're doing these days.
But before we jump into all of that, would you like to take a moment to tell our audience a little bit more about yourself?
Christoph: Yeah. Um, as, as you introduce me, I literally just, um, did a get push, um, because I, I have a big announcement today. I'm starting a company, I'm starting an indie game and open source tech company in Tokyo called Nakazawa Tech. Um, and so this is a, you know, you're getting me at a really good time because, um, I just quit my job.
Um, my last day was on Friday, um, and I'm all in on like building video games and doing open source as, so, like literally right now. So, so I'm nervous. I'm, I'm really nervous about this.
Justin: That is so awesome. I'm very excited for you. Uh, a friend of mine, Orta Therox is working in a game. Do you know Orta? You probably have crossed paths before.
Christoph: friend of mine.
Justin: Yeah, yeah, yeah.
Christoph: I think he's a friend of [00:02:00] everyone. He's just a really
Justin: Orta is, is amazing. Yeah. So he's doing a similar sort of thing. That's that's really great.
Christoph: Absolutely. Yeah.
[00:02:06] OSS Culture
Andrew: Cool. Um, so you've worked on, uh, a bunch of different OSS tools like, uh, Justin mentioned them, just metro yarn moo tools, like that's, that in itself is a crazy list.
Uh, what drove you to focus on open source tooling so much. And did the Facebook culture at the time help, uh, steward your open source efforts?
Christoph: Oh yeah, that, that's a really great, uh, great question. And the, the blog post that I just published about building a company, I, I go into detail there because I, so I started coding 22 years ago when I was 12 years old. Um, and I wanted to build video games. So this is, you know, in a way what I'm doing now is kinda like going back to the roots and like back then, um, you know, Microsoft wasn't as celebrated as it is now in the developer community.
So I pretty early on, I like started using Linux, and then there was this book by like Linus Trovalds, um, it's called Just For Fun. And like in that one [00:03:00] he, he describes like the early history of, um, Linux and like how he kind of just, you know, built it and it was so much better than everything else and he just put it out there for free.
Um, and, you know, there's all this controversy about like, his, like conduct online and like, I don't wanna, you know, none of that is good and like, you know, I, I don't like him for all that part, but like the, the core principles of like how he like started like a large part of the open source movement.
Obviously there were others, but like Linux is like one of the most celebrated ones. Um, so, so that really inspired me from early on when I started coding. And then I, I pretty early on I, I found this library called moo.effects that was like the, a precursor to moo tools. And then there were a few other moo dot something and.
And I think Valerio Proietti, the creator of moo tools, he just found that funny. Like he was like, oh, cows and moo and that's funny. But then later on he put together moo tools and he called it my Object-Oriented Tools, which, you know, is, is definitely like the name was there before the meaning. Um, um, and so, so I got like, um, you know, and I grew up in Austria, so my native language is German.
So it actually took me a really long time to [00:04:00] learn enough English as a teenager to be able to communicate in an English speaking environment. And, you know, I made a lot of mistakes there. But generally the, the thing was that I really loved the idea of like, Hey, I'm building something and that's useful for me and it's probably also useful for you.
You know, like, it might not be, it might be, but I'm just gonna give it to you and I have no expectation that you'll use it and, you know, please don't have any expect expectation on me to maintain it. Right? Like, you know, maybe, maybe not, and if you like some parts of it, but you don't agree with my principles, you know, go and fork it.
Right? So, so I was also a really early user of GitHub. I, I signed up, I looked it up like as part of this announcement that I started, um, uh, I, I created my GitHub account in June of 2008. So it's like pretty shortly after, after it launched. Right. So the moo tools crowd like moved onto that really quickly.
So the funny thing is, by the time I arrived at Facebook in 2011 as an intern, Most people at Facebook there, there was no open source program, right? Well, there was one, but it's very small, right? Like, it wasn't like a recognized brand as it is now, right? Like it was pre-react. Um, there was no like open source library, like by Facebook [00:05:00] or, uh, no open source, front end library by Facebook.
They did a few other small things, I think in the PHP world. Um, but at the time when I arrived as an intern, very few engineers at Facebook like used GitHub. So I was actually as an intern, the like, most followed like GitHub user, you know, like I had like so many followers on like, on like GitHub, you know, GitHub is also like kind of a social network.
So, so, you know, I think early on, like I had this, but then, you know, so, so that's like a long, long answer for like your question about how I got to like Facebook, I guess. But then, you know, when I worked at Facebook, I definitely appreciate like everything that Facebook has done and like the support they gave me and like pursuing some of this open source work that said, um, there's, it's definitely always been a challenge to like justify, you know, like, you know, why would you go and do this work, uh, on like open source and like a lot of it is just like, Okay.
You know, we have this thing that, that library is open source, but we also need it at Facebook. And so if you can align like what you're doing in a way that is like good for Facebook and also good for open source, then you kind of can do both, right? Very [00:06:00] easily, right? It's easy to justify and then you do a little bit on top, um, you know, maybe outside of work hours to like make the open source project really awesome.
Um, so, so that's, that's kind of like, you know, how I got into open source and also like how Facebook supported me or, you know, how I just forced myself to like do open source without anyone really like, you know, asking me or something.
Justin: In those early days, um, was it, was it sort of hard to get people excited, turn inside Facebook about open source?
Christoph: No on, on the engineering level. Never like, like engineers, like they all got it. I think a large part of Facebook was just always, you know, from the first day on was like built on open source. You know, obviously I cannot speak to that. I wasn't there, but from the outside that at least it, you know, looked like that it was all Apache and like PHP and like whatever, like it started with, you know, very, very like a basic stack.
And most engineers like really got it. And it's. The, the challenge I think that you have in engineering and also in [00:07:00] like some levels of leadership is to just make the case of like, Hey, you know, we want to open sources. Like, why, why does it matter? And I think that has definitely gotten a lot easier where, you know, I'm, I'm, you know, I haven't been at Facebook for two, uh, meta for two years, but I'm looking at it, they, they just, you know, very liberal, liberally, open source, a lot of stuff like in, in the AI space.
Um, and like that just gets taken and like, um, advanced so much. So I think, you know, it's very clear now that like Facebook benefits from it. Back then, um, when React was released, it was definitely, you know, Not expected to have this huge impact. You know, and, and as you know, you probably all saw the React documentary.
People were like, oh, you know, this doesn't make any sense. But then once people caught onto how awesome React is and then a lot of other libraries came out around it, um, Facebook in the front end space was able to build a brand, right? And then it very easily became this, okay, we're doing open source, we're doing open source well, and that is gonna help us bring awesome engineers into the company.
Um, and also, you know, we are benefiting from the contributions of people that are, um, out there externally. And, you know, it's, it's a bit [00:08:00] of, uh, it's interesting cuz like there's so much hype around ai, um, and very little talk about like, you know, what the, the impact of Facebook's front end open source program, which I think has been huge in the front end community.
Andrew: say, say what you want about Facebook. There's opinions you can have for sure. Uh, but like their efforts in open source definitely should be applauded, like literally just today. They released a text to speech, uh, AI that works with like 4,000 languages. Some languages that only like are spoken by 75 people work with this AI now.
So like the, the quality of work they put out too is just incredible.
Christoph: Yeah. And my, my take is that, um, this is my impression, and this is one reason why I liked working at Facebook so much, and also why I am so appreciative that I got to work on open source at Facebook, is that it very much like aligned with those principle that I had where it's like, you know, and this also in the community can be frustrating, but like a lot of Facebook open source is like, Hey, we find this useful, you know, or this is a research project and you know, here's the code.
You know, do whatever you want. In some cases, the license, you know, and there was [00:09:00] also the react and patents. I don't know if you, if you go back a few years, there's like a lot of stuff where, you know, nobody had any ne any nefarious thing in mind, but that's kind of just like the way we got to. Get a lot of code out of the door.
Um, but Facebook was a lot like, um, okay, you know, we think this is useful. We hope this is useful for you. And then, you know, some teams have always been struggling with like, getting enough folks to help out with like making open source awesome. You know, like if, if you look at for example, type script that has like 50 to a hundred people or something working on it at Microsoft and they all primarily work on the open source project because everyone else at Microsoft is also a downstream customer of that.
Um, that's a very different setup from like a type checker at Facebook where they only had ever had like five to seven people work on it and like very little time to support open source, right? So, you know, I think there like quite often, um, it's misunderstood where the community has expectations on like certain open source projects just because they're backed by a big company.
But then in the end, you know, um, what that team does, you know, a little bit is open source, but like 90% of their time is spent on supporting [00:10:00] internal use cases. Um, and you know, the reason why some open source projects are awesome in open source is because some individuals are just. You know, so excited about working on them and you know, there's nothing that can stop them.
Justin: Yeah, for sure. Uh, it is hard to discount that. Like you get really, really smart people who are very, very excited about solving a problem and they end up producing some really amazing things.
Christoph: Mm-hmm. Mm-hmm.
[00:10:26] Sheparding OSS
Justin: So, um, in the role that you've played in developing these projects, uh, how have you helped make them successful? Or, or what are the like key aspects that you think were required to make them successful?
Christoph: that, that's a great question. And you know, I just, um, when I talk about, you know, like what, what people at Facebook are doing in, like, what have, what they've done in the past and like what they're doing now, you know, this is all just like my impression. So I cannot speak for them. And I also kind of wanna take myself out of that because I think there's a lot of open source projects that others did that are way more amazing than anything that I ever did.
[00:11:00] And I feel like, you know, um, my contributions, you know, maybe people appreciate them, but I think they, there's a lot of ways in which they could have been much better. Um, I think the, the one thing, um, that I, I learned that I was really good at is get, getting people excited about the stuff that I'm working on or, you know, like, Getting people to understand what the value is of like having a certain system exist in a certain way.
Um, and I think Jest is like a really good example where, um, early on, you know, I, I actually didn't want to work on it. Like I, um, the reason why I was open source, so I had always been working on like testing and like, you know, even back in the mootools days, but also when I was like an intern at Facebook in 2011.
But then the reason why Jest was open source is cuz React was going to be open source. And so all the tests for React were written using jest internally, right? And so it's like, okay, if we're gonna open source react, then if we cannot open source the test framework to run the test, that's like, you know, useless.
Right? And so, you know, the, the mission there was, Hey, you know, take this thing that we have internally kind of works for us and just put it out there [00:12:00] in open source. And the person who did that, Jeff, he was awesome. But then right after that he was like, okay, I'm gonna go work on something else. Right. So never real, never nobody ever really worked on Jest for like.
From 2013 when React was released until like 2015 when I started working on it. And so everybody kind of hated it, right? Like in open source people were like, what is this? We don't use it, it suck. Or like, we started using it, but it sucks. So we stopped using it and then Facebook is like, well, we're stuck with this like thing with like 10,000 test suites and it takes like an hour to run them.
And so my manager, Tommo Keno at the time, I was like kind of shopping around for like a new thing to work on and he was like, Hey, Christof, go work on Jest. And I'm like, no way. I'm not gonna touch this. You know, it kind of sucks. But then the thing was that, you know, everybody was like, Hey, you gotta rewrite this.
And I, I kind of tried to take it, like, take his suggestion seriously, because, you know, he was always coming from a really good place and like he's always supported and mentored me really well. Um, and I tried to look at it and. I was like, everybody was kind of saying, let's rewrite this thing. Let's, you know, just build a new test runner, not rewrite, like build a new one.
You know, don't call it, jest build it. Uh, like take it, call it something else. And then I [00:13:00] looked into it and I realized actually, like the ideas here are really good. It's just that nobody has maintained it. And like, there's a lot of assumptions that were made about, you know, the scale of for a code base that no are no longer true or that, you know, the code base just grew much faster, right?
So what if we take everything about just, you know, it doesn't make sense to rename it, you know, it doesn't make sense to build a new thing. Cuz all the tests at Facebook had, would have to be rewritten for the new thing, right? And so I just made a plan of like, okay, how do we just make this like 10 to 30 times faster so we can run all the testing like a few minutes?
Um, and that was, you know, a huge amount of tests back then. So like literally 10,000 test suites, that's like 10,000 files testing, like millions of lines of code. Um, you know, how can we do that? How, how can we improve the ergonomics? How can we, uh, improve the api? How, how can we add like new features to it?
And so through that and that, I started finding partners and like ads was like an, a very obvious one where it's like, Hey, if we make a mistake here, that's gonna cost the, uh, cost us money, right? So I was able to build some allies. Um, uh, I, I was gonna, I was able to find some allies in the [00:14:00] ads team. Um, one of the most awesome was his Aaron Abramov.
Um, and, and like he kind of just joined Facebook and then joined the ads team. And then we just worked together full-time, even though we were like kind of virtual team. Um, but like he was so excited to work with me. And so I think overall, sorry, I, I, this is like a long winded answer of how I got into, like, working on Jest, but the, the point is that, um, getting people excited about a mission and like, you know, making that happen, that's really what has helped me work on open source and make awesome, uh, awesome open source projects happen.
And then outside of Facebook, I went and also built like a core community of contributors for like, jest for example. So it wasn't just like an internal thing, but I think that's also something. Especially if you're not working at a specific company that supports open source, you have to just go out there and like find people that are excited about a project.
Um, and that's how I also then ended up moving to engineering management because I found that, um, I'm just so much more excited about having, you know, working with people that work on those projects and then, you know, them being excited and them having good career out outcomes because [00:15:00] they're working on these kind of tools that made me so much happier than like building, uh, building things myself at the time.
Andrew: Yeah, c commu community is key. And I think all of your accomplishments, uh, or your team's accomplishments really, uh, show that. Uh, so speaking about jest a little bit more, I think I've seen you talk about this on Twitter a few times, but I've seen the jest maintainers at large refer to jest as being a thing that could be more than just a test runner.
It could be like your task runner. I saw you had a blog post where you made it into a bundler. So like what, what, what Hidden Potential does just have, and maybe we haven't like quite used yet or Will may never use
Christoph: Yeah, I would say may never use, um, I think, you know, um, that was more something that made sense five or six years ago. It doesn't make as much sense anymore now. So, so all those things that, like we kind of popular popularized with like lerna and yarn was this like whole idea of like mono repos, right? [00:16:00] Back then all the open source repos were like, here's like all the code in one folder and like, you cannot take it apart, right?
And so when I was rewriting just like all the internals of jest, um, I tried to start splitting it up and that's kind of how all the projects start nowadays. But nowadays, but back then it was just not obvious, right? And then over time I realized, okay, so there's like 30 packages or so that like compose.
Um, just, and so you can actually take five of them to turn it into a bundler. You can take five of them to build a package manager if I wanted to. You know, and there was like, all of these things were, um, I think if five years ago we had built a bundler on top of jest, it would've been much faster than anything that had existed five years ago.
Um, that said, you know, I mean now there's a lot of, um, um, progress on like building these kind of like mono tool chains, right? There's bun, um, that just like, they have a test framework, they have a Bundler, there's Dino, right? Like, so, so all of that kind of moved from, you know, I had like the basics for JavaScript infrastructure, all written in JavaScript.
And now all of that moved into like Dino and um, bun, and then there's [00:17:00] like turbo pack and turbo repo and like all the stuff that Vercel is doing is kind of like going into this. Here's a mono tool chain kind of. So, so that was definitely the potential was there. Um, it was never something that, um, would've made sense that Facebook, I would say.
Um, but also the team was just not large enough to, uh, at the time to like go after that vision. There was like other stuff that, that we were focusing on. Um, but yeah, the, the basics all there and yeah, as you said on my blog, I'm like, I'm taking the just thesis to build a bundler and you can basically build anything with it.
Um, now I would not suggest anyone to go and do it. Like I think you can build better foundations, um, in 2023 than, you know, we have in 2018. And like you would start with that.
Justin: Yeah, it's really interesting and it's been very gratifying to watch a lot of the, the tool chains in the whole ecosystem, mature. And one of the things that I've always been, you know, very positive about the front end ecosystem. You know, despite people being, you know, having like, uh, you know, frustrations about how much churn there is and how mu [00:18:00] frequently things change, but it has been really gratifying just to watch the, the sort of evolution of all of these products and projects like really come together.
And it's like the, the dev experience we have these days is, you know, so much better than it was in, you know, the early 2010s for sure.
Christoph: one thing that I wanna add there though is that, um, I think. People often get too attached to their tools. And like I definitely made that as a mistake when I was an engineering manager for the first time. You know, I was managing JavaScript infrastructure and I was like, Hey, you know, we are the team that's building yarn just and Metro.
Um, but what it should have been is like, be much more problem and solution oriented where it's like, Hey, we're solving bundling for Facebook. We're solving testing for front end at Facebook, and we're solving package management. And then, you know, the, the, what I learned is when when people get too attached to projects, it's very hard to get them out of that.
But also they'll, you know, quite often, you know, and including myself, I'm not speaking about others. It's like, you know, if you get attached to something, you're like, okay, how can I make this thing just a little bit better instead of [00:19:00] throwing it away and being like rethinking it? And that's one reason why I'm so excited about vitest is, um, that, you know, it's basically a re-implementation, a re-imagination of jest But in 2022, 2023 built on vite which is definitely, in my opinion, the best bundler because it's just like so incredibly fast and like, you know, still all mostly JavaScript except for the esbuild part. Um, so what I care a lot about is like the ideas surviving and like the ideas actually that were, that are in jest like, they all still make sense, they're all relevant because vitest is, you know, more or less like a copy, I would say.
I hope that's okay to say. Um, I don't wanna be unfair to the vitest, um, team because they're doing a lot of stuff from the ground up. They're, they're having a lot of inventions, they're building a lot of stuff into vitest that we never were able to build into test. Um, but you know, the core idea of like, you know, the, the testing API is like basically the same, the way it looks, the way the watch mode works.
All of that is like very similar and inspired by, and, you know, if you look at the code, like a lot of it is definitely taken from jest, which I'm totally a fan of. I'm not saying that as a negative. It's [00:20:00] all, you know, the whole idea of open search, you know, we threw some code over the wall, you know, it's us.
If it's useful for you. Um, take it, you know, fork it, build your own thing, make it better. And so I'm, I actually think that's like a really good example of how open source can go really well. Um, and my recommendation is just for people to not get too attached to something. Because quite often the sentiment is like, oh, why did you build a new thing?
Couldn't you have just like, built it into that old thing? It's like, yeah, but that would've made everything slower, larger, you know, it would've moved much slower because you have to argue with a lot of people. So sometimes it's better to just, you know, burn it down and build something new.
Andrew: Yeah, we, we build lots of assumptions into our code and those assumptions change over time and just shedding those is not a trivial thing and can often result in the project looking like it's getting worse rather than better. Um, So, uh, you, you mentioned a few cool new tools that are out there, but like, what are your most, what, what are, what are the most exciting tools to you that are coming out right now?
Because we're kind of like in a golden age of JavaScript, uh, evolving.
Christoph: [00:21:00] Oh yeah. Um, um, yeah, as I said, vite and vitest, um, and like the entire v ecosystem, what the folks there like, um, Evan You, Patak, I don't know what his like real name is actually, um, Anthony Fu. Um, what all those folks are doing is like really, really impressive work. Um, I, I, I think there, there's this whole split now, right?
We're, we're like going into this direction of like, okay, should JavaScript tools be always written in JavaScript or should JavaScript tools be written in another language, but they're, you know, supporting JavaScript? Um, it's a tough, tough decision, right? Where, you know, you go to another language like Rust, which is like a lot faster, but a lot slower to write, but harder to interface with JavaScript when you're like trying to think of a plugin system.
Um, and. I, I don't know, actually. Like, it seems like there's enough room for all of these to exist. Um, but I'm, I'm still a fan of the JavaScript based tools because, you know, when people, when the tools are written in the same language, it's a much easier way, like, it's much easier for people to contribute to, to them.[00:22:00]
And if you, your entire tool chain is written in another language, then, you know, maybe all the code should be written in that language, right. Where it's like, you know, so, so I'm, I'm not exactly sure, um, where we're gonna go there, but, um, for now, I, I'll try to always bet on JavaScript. Obviously there's some things where other languages just make a lot of sense though.
Justin: Yeah, this is something we talked to Charlie Marsh about back on episode 54. So he's, he's writing Python tooling and Rust. Uh, but I mean, we're, we're seeing sort of this hybridization, you know, tape be it like WASM stuff, which we'll have some episodes coming out about soon or whether it, um, yeah, just this rust, uh, rust tool chains being embedded, uh, either like.
As a full layover. Say, say like Rome, you know, where it says like, we're rewriting everything in rust. Or, you know, just things that like leverage stuff like Es build. So it's like there's a go core and then everything else around it, there's a lot of JavaScript that powers it. I, I, [00:23:00] I find it really interesting.
I feel like we've gained a lot, and this is my personal opinion, I feel like we've gained a lot by setting aside a little bit of the purism, but to, to focus on like, we do want to make these projects approachable, but we also want to have like these, like really nice characteristics and, and finding the, the right trade offs per tool, per community, per ecosystem for that has been,
Christoph: Absolutely. And I think this is one reason why, you know, from having worked on a Bundler, um, why VI is so exciting to me because it, it uses ES build or wc, whichever one you wanna like, hook in. But, um, you know, the, the act of like taking a JavaScript file and compiling that into a different type of JavaScript file that you know is heavily string based, um, you know, you have to traverse a bunch of trees, um, that's much faster in languages that are not JavaScript, right?
Um, so like rust or go or other languages. Um, and it definitely makes sense for that stuff not to be JavaScript. But then vite is like almost everything else well, Yeah, I think everything else is [00:24:00] actually JavaScript, right? The mini five is also esbuild. Um, and you know, maybe Rollup could be faster if it was written in Rust or in Go, but all the layers around that, you know, starting a dev server, you know, figuring out hmr dependency tracking, um, all that.
There's probably very little point in rewriting that in another language and like keeping it in JavaScript allows you to move much faster, right? So I think that hybrid approach probably makes a lot of sense. And the problem is then when people are like, Hey, let's rewrite all of this in Rust, and then in the end it's like two times faster.
You know, two times is still great, you know, it's, it's not nothing, but it's like, okay, if we wanna rewrite this whole thing and like make all these trade offs of like, you know, around, uh, other than performance, you know, there's some negatives as well. Then it has to be 10 times or 20 times or maybe even a hundred times faster.
And like people are so excited, like, oh, we rewrote it in another PR programming language and it's two times faster and it's like, okay, and you spend like, how much time on that? You know, and like how much more maintenance is that? Um, so, um, yeah, I think, um, I think it has to be
Justin: Yeah, for sure.
Andrew: Yeah, r r writing it in another language seems like [00:25:00] a silver bullet, but if you look at bun, I don't think, uh, all of the wins are just cuz he is riding it in Zig. It's because he is optimizing down to the bit, like there's a lot you can do before switching languages, uh, to optimize your performance.
Christoph: Absolutely. Yeah, I think you obviously have to talk to Jared about that, but um, this is like another aspect of open source that I love that like, sometimes you just have specific people that are just so excited about one particular thing and like Bun and Zig and like Jared being obsessed with performance.
That's like one of those things, right? Um, so yeah, power to him. Let's see where it goes. Um, I'm super excited and yeah, you're right. Maybe he could have chosen another technology and like he will also be as fast just because it's him who is building it.
Andrew: Yeah.
Justin: This makes me think of the, the conversation we had with Steve Krouse too. So he tried to start a startup that was like, oh, we're just gonna do WASM stuff and make your, you know, digital projects really fast by, you know, adding this native element in there and defining was a, like, [00:26:00] performance on its own is really hard to sell.
Uh, and b it's like, sometimes it's not as actually as fast as you think it is. Um, and you know, it, it really like, performance is more, well it's as much of a mindset as it is a, a particular set of technological decisions. You know, it's like you have to be really focused on it and you can write.
Performance code and whatever ecosystem you're in, it's just, uh, yeah.
[00:26:26] Front End ArcheTypes
Andrew: Okay. Uh, so one, one more question, uh, not about Athena Crisis before we move on to Athena Crisis. Uh, you have, uh, an interesting blog post on your blog about front end developers. I often joke on this podcast that I'm, I'm just a front end developer, but I really do think that it's a, a very varied field and there's lots of depth there that you might not, uh, initially see if you're just like, oh, it's a person who knows how to put boxes on screens.
So, uh, could you explain a little bit the different archetypes that you explain and then, uh, which one you think you are?[00:27:00]
Christoph: Yeah. Uh, great question. Um, so the, I, I, I wrote this blog post about front end engineering archetypes. I actually started a blog post on. Interviewing for front end roles, um, from a like company perspective, like, um, you're like, okay, I need somebody to figure out this front end. You know, you're like open AI that like, is like, just cannot get right.
That c get that css right? For like picking between like the language models, right? And it's like, we wanna hire front end engineer. So I wrote that like a, a draft of it and I'm like, wait, no, actually first I have to like, go back and explain the archetypes and then all this stuff with like starting my own company happened so I didn't get back to the actual thing I wanted to write about and which so is, so how it happens, I will get to it eventually, but basically, yeah.
Um, the, you know, I've been basically a frontend engineer for my whole engineering life, right? Like, not just career, but also like when I started like coding, um, the, the thing that really always defined me is that, you know, obviously I'm excited when like I'm super obsessed with performance and stuff has to [00:28:00] be fast, but when it's in service of like printing a few numbers in a terminal, I'm just not that excited about it, right?
I'm more like, okay, you know what, what do you put on the screen? On like a website ideally that you can share with the whole world immediately, right? And like, what does that look like? And that's why when I'm like building front end stuff, I can never just work with like a mock-up. I'm like, okay, you know, obviously I have to stop at some point, but I'm like, I'm gonna try to make this as good as possible and then move onto the next thing.
I cannot be like, oh, this is just a placeholder. I always need to just be like, okay, this is what it needs to look like. And so very early on I knew like I was a front end engineer because that's just where my passion is. And then from working at Facebook, um, and so when I, I, I was in Menlo Park at first for like four years and then I moved to London and there, um, I had the opportunity to kind of help with front end hiring, um, besides just doing interviews, but more on like a holistic level of like figuring out and like, For all of Facebook, London, like how many front engineers do we need per year?
Um, you know, who is gonna be interviewing how to train the interviewers? [00:29:00] I trained a lot of them. How do we stay calibrated across like the, um, front end interviewing team so that we all conduct interviews in like a similar way? Um, and part of that, like for me was, um, and that was not like a Facebook concept, like the, the archetypes, but um, that was more like, here's like what I think are the archetypes for front end, right?
And so the four ones that I defined are product engineer, UI infra engineer, designer, and tooling infra engineer. Um, and so, um, the product engineers, I think the most commonly one that people associate with front end where it's like, hey, go, you know, here's a mock-up. Go and like implement that. Um, and the thing is that, you know, that just that, that's like a very specific type of frontend engineer that loves doing that.
Um, and I think even though it's the biggest one, most people would be like, oh, I'd rather work on tooling or I'd rather work on design systems or something like that, right? So, so that's, I think the most common one. But, um, most companies also don't really have the. You know, like half the size and the scale where it makes sense to like really separate it, right?
So most often you'll find a product engineer and it's like, yeah, I figure out how our package [00:30:00] manager works, how our bundler works, and like how we ship that to the front end. But ideally, if you can scale up your org, product engineers don't have to think about that. They just go in, write their react components, go make product happen.
And then the really excited ones are the, are the exciting ones, are the ones that can really communicate with your entire organization. Like, you know, with the designer, with the backend engineers, with the pm, with the managers, um, you know, across the organization to like build great products, you know, and not just build the buttons, but like actually build user experiences, right?
Another one was the UI infr engineer. That would be the one that's sitting right below their product engineers. Right. And those are the ones that build design systems. Those are the ones that like actually wor, like maybe are even embedded with the design team. And they are like, okay, you know, we see each team building their own button.
You know, we are gonna go build our button. And then they're like, oh shit. You know, we have to figure out typography first. We have to figure out paddings and margins. Right. A lot of that stuff is maybe getting a little bit easier with like tools like Tailwind, but. You know, I feel [00:31:00] like at a sufficiently large size, every company needs to have product folks and then ui, uh, infr engineers below it.
Then there's one archetype, and that's the one that I love the most working with actually is the designer. And maybe I, I love working with them because that's the one I'm clearly not. I can definitely tell you I'm, I'm not great at design, but those are the ones that are usually like self-taught or they have like, Um, some, I would say weird, like career path.
And I don't mean that in a negative way. It's more like, oh, you know, I was an English teacher in Cambodia and then I came back and I did design, and then I went to this school to learn how to design. And then I was like, oh, actually I wanna implement it. And I learned coding, like, kind of like that sort of story.
And those are usually like super interesting people that have like absolute, they're super creative, have absolutely great ideas, and they can go in, it's like, and, and come up with a design in, you know, whatever design tool they're using and then also implement it. Um, and then they come in and it's like, okay, and I've just dropped WebGL in it and now it's like 3D or something like that, right?
And you're like, wow. And like, those are the ones that like make amazing splash pages, for example. [00:32:00] And then the final one is, I guess the, the tooling infra engineer and that's the one that I would identify with the most given the stuff that I used to work on. Um, those are the folks that actually go, um, and like figure out all the infrastructure and build it.
Um, but now I'm, you know, trying to get back a little bit more into the product engineering side as well. Like I'm, you know, trying to be a full stack front end, if that's a word.
Andrew: Yeah, those, those archetypes really resonate with me. Like I think, uh, I started out as product but then like slowly crept more and more into infra to where like at my old job at Intuit, I was design systems and design. Systems tooling so squarely in those two brackets. Then I recently left and went to descript, a startup and was like full stack product, but then slowly, like my expertise ca came in and all those responsibilities piled onto me and like I built our design system and handled lots of our tooling.
So, uh, yeah, I really think those are good, good archetypes and if people are getting into front end, they should like learn about them so they [00:33:00] can go deeper on the topics.
Christoph: Yeah. Can I just add one thing to what you said? Because, um, that's so, so one reason why I wanna write about these things is because I feel like, um, having been an engineering manager for the last six and a half years or whatever, um, you know, there's certain things that you learn about. These sort of, you know, like, um, like positions and like profiles and like people and like how to make them work together, how to make them happy.
Like how to, you know, make everyone happy basically. And so, one reason why I actually wrote this is because the, what I've seen in some engineering orgs where I've been in is that engineers are treated as like this fungible good. Where it's like, oh, that's just a resource, right? Like, and you know, okay, we're okay, this is I guess, a front end engineer, so let's go put him on that team and work, like, have them work on that thing, you know?
And like, um, And so the, the problem is it doesn't work like that, right? And you really need to figure out what is somebody's passion. And the best way to start is by them knowing what their passion is, because then you can just ask them, right? Like quite often with like more junior folks, they haven't figured it out yet.
They still have something to learn, but more senior folks, they will [00:34:00] really know. And then if you come and it's like, Hey, actually I know you'd like the design systems, but now I need to to work here, uh, need you to work on a new bundler. And then you go and you're like, okay, sure, I'll do it. And then you're like, I, I actually really hate this.
And then, you know, you won't be good at it. You won't be happy. Nobody will be happy, right? And so knowing what you like doing the most and like being able to share that with like your manager and the people around you. Um, and like trying to get into a position where you get to do that more of the things that you love.
Um, I guess that's also the story of like why I'm starting a company. But, but in general, like, it, it leads to better outcomes, right? And like makes people more happy. So that's one reason why I'm trying to, you know, maintain this blog and like write about these things.
Justin: Yeah, head of manager, uh, a while back who I was, I had this kind of continual conversation with was like, you know what? I'm trying to do this work and it's really hard, but I want to get better at it. And, you know, I just like, I kind of, sort of continually banging my head against it and, and he'd sort of stopped me and he is like, but you're really, really great at like this other area of work.
You know, you [00:35:00] should just focus on this and take what you're already good at and just get so much better at it. And then, you know, it's like that level of contribution is, is sort of interesting and important to understand. So I do appreciate the archetypes. Um, and, and another thing that I think is really important is just like having a way to refer to things, having words to describe them is also really important to say, oh, actually this is, this is what describes me, or This is what describes what I like.
So, um, It's cool to see and, and definitely if there's anybody who's junior, who's listening who you're like, well, I thought I really liked front end, but I'm doing this thing and it's really annoying and I'm really having a hard time. It's probably a really great signal that there is something else out there for you that will really, you know, light your fire and get you excited and you should explore.
Christoph: Yeah, so I, I, I have two daughters now, uh, Mia and Lena. Mia is five and Lena is one. And I, I think so much about, you know, I, what, what do they want to do and like, what should they do? Or like, um, how do they [00:36:00] learn, right? And so, so what I read. And what I, what makes a lot of sense to me is that there's two things that you need to learn anything.
One is that you have to have a passion, you have to be excited about it. And two is you have to spend time on it. And when you can align those two things, then usually you'll get good at something and you'll actually learn something. And so, you know, first off, not giving people the time to like, learn something, always a bad choice.
And also putting people on projects that they don't enjoy always also a bad choice. Obviously at like smaller companies, you don't have that choice, right? So I'm really talking about like larger organizations where, um, that choice usually exists where, you know, I, I've seen a lot of engineers, they're like, Hey, I'm just not good at this, you know, and it's like, yeah, you know, but we don't have anything else to work on and that, that really sucks, right?
And so, um, ideally you always find a spot where, you know, people can be happy and then that leads to really great outcomes and they'll, they'll learn something
[00:36:50] Athena Crisis
Andrew: So speaking of being happy with what you're working on, let's switch gears a little bit and talk about your new game and your new company. Uh, so your new game is called [00:37:00] Athena Crisis. Uh, so what is it exactly and why did you choose to build it?
Christoph: Yeah. Um, so it's a 2D turn base strategy game. Um, and it's kind of inspired by games that existed like 20 years ago. Um, the thinking primarily was that, um, I want, as I said earlier, I started coding to, to, you know, create video games. And I did that as a teenager. So I built like video games and social networks.
That was before I knew Facebook existed. And so I spent like 10 years at Facebook. So I feel like, you know, the, the social networking po uh, box is kind of ticked, you know, I, I still love Facebook. I'd be happy to work at Meta anytime, but, um, you know, I kind of did that, right? And so, so I kind of thought after two years at Stripe, like, what, what am I really passionate about?
What, what do I really want to do? And so, um, I kind of thought maybe I want to go back to like, building video games. And so I, I actually built a similar turn base game in high school. Um, so that was like, 17 years ago or something. But it didn't have like animations, it didn't have the right data structures, it didn't have an ai, didn't have fog of war [00:38:00] Like basically it was really bare bones. It, like, I felt like at the time. Wow. That was really cool that I was able to build that. But it, it, you know, it, it just had so much missing stuff and there was no way I could have ever built that back then with the knowledge that I had, um, without rewriting the whole thing.
Right. And so about a year ago, maybe a little, well, maybe a year and a half ago, I just got that old game to run again in a Docker container. It was all written in PHP five, and I got like a Docker container running with that code. You know, try to run a three year old JavaScript project, you know, do an NPM install.
It's, it's impossible to get that to run, right? But I was able to run, to run like a 17 year old code base on a DACA container. It was amazing. And so I just thought, man, you know, wouldn't it be cool to like actually build an AI because I have absolutely no idea how to do that. And you know, for me, when I read online like, Hey, how do you build an AI for the video game?
You know, and it's like, here are all the steps. And I'm like, I don't get it. I actually have to go and do it. Right? And so, Um, also our second daughter was born and it's just, you know, amazing to have two children, but it's also really exhausting. So I needed something to balance that. And so I [00:39:00] started as a meditation project, kind of like just from scratch.
Um, how do I build this? And I put one really weird constraint on myself that was, I'm only allowed to use tools that I fully understand, you know, obviously. Uh, so, so the, this, we mentioned Orta already, right? And like he, he had this talk back when he was an art artsy that. They want to only use open source that they also could maintain if they maintain a dropout, right?
And there's like kind of this idea of like, you control your entire stack. And so for me it was like, I don't really know game engines. I don't understand them. So the only way I can use it is if I build it from scratch. But I know React, I know Relay, I know like all these front end tools that I either was on the team of or like very close for like a really long time.
So that was my constraint, right? And it's like, how far can I get with that? And over time, um, this hobby kind of turned into something real. Um, and so, um, the, the other thought is just that building a 3D game is just incredibly hard. Um, like either it's really expensive in terms of like assets or it's really expensive in terms of like making it.
So I thought I'll start out building something 2d, something retro, [00:40:00] um, just to, just to see if I can do it and how far I'll get with JavaScript, CSS and React
Justin: That's awesome. So is the, so you've got a whole custom game engine that's just like, is it mostly just react on the front end? What, what is your, what does your stack look like?
Christoph: Css, so it's obviously images and css, um, and React. That's basically it. Yeah. Um, I have run into, so this is another thing, you know, but from having worked in tooling for so long and having worked in, um, as an engineering manager for so long, I haven't done as much css. You know, I kept up to date. I know the basics.
You know, I kind of grew up with CSS existing, you know, or like evolving, but I never used like all these advanced features, so, That was another goal next to like building an AI is like, you know, become really good at 2020 threes or 2020 twos at the time, css. Um, and I ran into so many issues with browsers.
Um, so this is why, um, I have, I put together a talk about how not to build a video game. [00:41:00] Um, and I'm going to Amsterdam in like to, in, in a week to, to speak about that. And um, I also did a similar talk at React phone. Um, there's a bunch of really wild CSS stuff that exists, now in browsers, but there's also a bunch of wild ways that you can use it.
Um, and so that's the premise of my talk.
Andrew: Yeah, you use it in a few, uh, pretty interesting ways. Like, uh, the sprites looked like they were really easy using your CSS variables. You have like a global like index that you use to like, animate all the sprites, right?
Christoph: Yeah, I'm really embarrassed about that because there's a much better way that I haven't reverted back to. Um, so. I feel like I did all my research and I looked at everything about the Web Animations api and I basically want to run as little JavaScript as possible for like just the idle animations. So just for context, for those who are listening, um, they're like units, um, like, you know, an infantry unit or something, or Tank on the map, and then they move up and down like they're reading or like alive.
Um, and that's all animated using css. And I don't wanna run [00:42:00] much JavaScript to like get that animation going. And my problem was that with CSS animations, I couldn't align them because they start when an element gets inserted into the dom. But now, finally, even though I thought I had done that research, now finally I learned through doing this talk at React Devon, that there is a thing called document dot timeline.
And that actually gives you the like current state of like, um, you know, like a time that starts when you open the page. And that way you, you can set the current time of a, an animation. To that time, and then all the animations will be in sync. So obviously I'm gonna change my approach to that because it's much less clowny than what I have.
Um, but you know, this is another way in which it's actually good to go out there and speak about it because one, I can find bugs and browsers. Um, I can find things that browsers want to remove but shouldn't, because actually it's a really valuable feature and it like, um, it's needed. Um, and I can also learn about how to actually do things much better than what I came up with.
Andrew: It, it's scary how much of the web is built upon those [00:43:00] browser features that can't possibly be removed.
Christoph: Absolutely. Yeah. So actually I think that word maybe like saying why, why does, like, does any of this make sense? Right? Like, and you know, maybe there's, um, a way that you could say no, it actually really doesn't, you know, just go and build u build it using unity and like unreal. But the, the thing is that, you know, web technologies, in some ways they're like light years behind, but in some ways they're like light years ahead of anything else, right?
And so the, the thing that I can do with my setup is that I can just type and I save vscode code as I'm typing and like the code just updates in real time. Basically. There's like no compile time. The time it takes me to compile the game and ship it to production is probably less than it takes any other game engine to just go build a game and development to try it.
You know? And so, so those are the sort of things where you get so much value out of that. And so this was also another consideration is like, okay, I'm building this game. Um, I love open source. I want to, when I'm building a company, I want to build it in the open, you know, obviously I'm not gonna open source like the core of the [00:44:00] game at this point, but, um, I wanna open source as as much technology as I can, but even if it's not the technology, cause I don't think the game engine I'm building is like one that would actually support like, you know, 3D games.
I think there's, you know, WebGL, web, gpu, like all those things make a lot more sense. But, um, there's, there are probably a bunch of ideas that I'm coming up with, um, or that I already had that make a lot of sense to popularize in terms of like, here's how. So, so, uh, just, just backing up, I think the, the whole idea is that obviously I wanna do thing, more things that I love, but it looks to me like game development is somewhat broken and I feel like the web has some of the answers, not all of them.
Definitely. Um, and so the ideal outcome in the end would be to just kind of more democratize, like making games and like making it much easier to build games. Right. And so I don't know exactly what role I can play in that yet, but, um, You know, o I'm pretty sure open source will play a huge role and I want to be a part of like helping in that space.
Justin: There's, there's a lot of interesting, [00:45:00] uh, aspects to your story. So, you know, you talked about starting this journey after having kids and sort of ha needing this meditative exercise and, and picking things that you knew. Something that is a sort of a common problem that I have with projects, and I know a lot of other people probably stumble across the same thing, is, you know, anything you build takes energy.
There, there is a conversion of like mental energy to some output, and you have to pay your, especially as you get older and you have less time, you have to be very strategic about how you pay that cost. And I, and I appreciate your, your strategy here. You're like, you're, you're basically optimizing to pay the cost on, you know, really the nuts and bolts of the game, of, you know, how the technologies that, you know, fit together to like bring this thing to life.
Um, whereas oftentimes it's so. Easy to get, like really fascinated by like a shiny new game engine, for example. And then you go spend all this energy on this shiny new game engine. And then when it comes to like the core of [00:46:00] just like building this thing that you wanna share with the world, you just don't have it in you to like sort of finish it out.
And that's a, a really common story. So I just want to give some appreciation for that approach.
Christoph: this, this, you said something absolutely great and this whole thing of like using things that I know. Um, and, and like if you jump on something shiny, then everything is new and you have to like start from scratch and you don't know what to hold onto. And then it, the turn is just really like slow.
Right? Not saying that you shouldn't learn new things, I'm all for that. But, you know, time box it, right? Like spend a weekend with a new thing and then figure out if you wanna build on that. But the, the thing is, you know, I, yes, the base layer of what I started with, like that's all the tools that I knew, but there's so much that I don't know that I was able to learn through that.
Right? You know, one thing where, um, you. Like the, the whole game is built using immutable data structures because it's basically, you know, you have a turn base game and anytime you make a change, you execute an action and then you get a new game state back. And like, I felt the smartest way to do that is using immutable data [00:47:00] structures because, um, with like, especially, especially immutable js, which I think now is kind of considered as a legacy thing, but the idea is that you, you know, anytime you change something, you get a new copy back.
But then the backing data store is like the same except for that one minor change, right? So that's called persistent data structures. Um, and so you can actually have like, you know, a hundred thousand game states, um, you know, in memory and it will not take up that much space. Right. Um, and also it's really fast to add or remove or change something because you're not recreating that entire thing in memory.
You're just making a small change. And then the external representation is like, okay, this thing has changed. And so I was able to get super nerdy on like, okay. Immutable. Everybody says immutable JS sucks. Um, and it's slow. And yeah, some parts are slow. Okay, can I make a faster implementation of immutable Map?
Um, and you know, with the constraints where I'm like, okay, I make one change all the time and I want the change to be fast when I'm creating a completely new thing of that and there's just nothing that I could build that was even remotely as fast, [00:48:00] right? And so I just forked immutable js and I got rid of everything else but immutable map and then I published that as a separate library cuz I don't think there's any better immutable map, um, um, um, implementation out there.
And even if you're using mutable maps, it's probably faster to copy. Well if, if you ever have to copy a large map, it's probably faster to use an immutable one, right? And, and so I think there's also this whole thing of like, people are just going with like all these new technologies without really like evaluating some of them.
And maybe sometimes it makes sense to go back and be like, Hey, actually this thing from like five, six years ago is actually still the best at that. So what I'm saying is you can learn a lot of things by using the things that you're, you know, because you get to focus on like learning things that you didn't get to invest in earlier while still holding onto that base layer of knowledge that you have accumulated.
Andrew: Yeah, wholeheartedly agree with that. It's, uh, an extension of learn by doing. Learn by doing, but with things, you know, so you can't learn more. Um, so, uh, we've talked a little bit about what [00:49:00] the, like what web made easier for building this game. Like styling was easier for you, layout was easier. Uh, the feedback loop was easier.
But what were some things that were hard because you chose the web platform?
Christoph: Uh, yeah. Performance. I think that's like something I still struggle with, where even though I'm not doing that much, um, uh, in terms of like graphical intensity, um, it's sometimes really hard where, you know, some CSS properties, Their c uh, GPU accelerated, but then they're not. And then some other things were like with background images, for example, they, when you change a position of a background image in like a spread, it actually bounces back between CPU and GPU all the time.
So you, you spend a lot of time compositing. So there's a lot of stuff that I learned about like how browsers really work, you know, where it's like, this is, you know, you read like how this thing is supposed to work and then you're like, okay, actually if you really do this to the max, it's not meant to u be used for that, right?
So, so there's definitely an element of, I'm trying to do this with an, you know, an engine you could call browsers a game engine [00:50:00] in a way if you really wanted to. Um, if you're trying to do that, it's maybe not the ideal setup. Um, but then, you know, there is web gpu, there's WebGL WebGL, um, so you can always fall back to those kind of modern technologies.
Um, I'm still trying to sit in the space of like, how far can I push all the browsers and like, are these things that browsers are supposed to be able to do or not? Um, and then from another perspective, um, I think making, like building the AI was not hard. Um, but making a smart AI for a turn base game is actually incredibly hard because it's, uh, that's something I still haven't unlocked.
Um, you know, I, right now the AI that I've landed in is that I've built it to play in a similar way that I would play the game and it's better than any beginner. So beginners will always lose, but it's worse than any of the experts, people that have played similar games before. So they'll always win. Um, and so, so that's like this struggle where it's like, okay, built this intermediate AI bot, [00:51:00] but I need to make it like dumber, but also smarter and like, um, I don't know exactly how to make it that smart yet.
So that's something where it's just really excited to, exciting, to like, figure out how to do that. And, um, the, the crazy thing is like when you have so many variables that go into the decision making process for an ai. Then you only make a small change, like you change the weight on like how important something is to the AI from like 0.2 to 0.1, and then it plays completely differently.
And so, um, it's super fun and interesting, but also super hard to, to get that dialed in where it's balanced well so that it's, you know, the, the, all of this is in service of making something that is fun to play. And if the AI comes in and crushes you every time, or if the AI comes in and loses every time, maybe not ideal, right?
So, um, that's, that's hard and really fun.
[00:51:48] Challenges
Justin: What are, uh, what are some of the parts of the game so far that you've had the most fun building?
Christoph: Um hmm. [00:52:00] I think anytime I figure out something with CSS that nobody ever has thought about, you know, I'm, I, I don't think I'm that smart, but like every once in a while I'm like, damn, this is like, so fun. So there's like this whole thing where, um, whenever you select a unit, it shows you the movement radius, and that's like, um, um, it's like blue rectangle.
So each field gets like a blue rectangle, but then it's actually like, has this striped pattern and that is actually like a mask image with a linear gradient. So all of that thing is like, just all of that stuff is just rendered in css. So it's like super dynamic. There's no images involved, um, or the like, um, the movement arrows.
So when you like highlight like a specific spot of like where you wanna move to, then you get like an SVG generated arrow that like, looks pretty nice. And then also it has, it's like animated using CSS animation. So again, there's like no images involved. Um, I think maybe that that makes me the most happy is when.
I get to do something with CSS that previously you could only do with [00:53:00] like pre-rendered images or something. And in a way, like CSS feels like a very basic and somewhat slow shader language. Right. And I don't really get shader languages. Like I, I read the tutorials and it's like, you know, this whole thing of like how to draw a owl, right?
Like you read a tutorial about shaders and it's like, oh yeah, I didn't know how to make this rectangle blue or something. And then it's like, I have no idea how to like, do anything smart with them, right? So I, I wish CSS was way more expressive and like, could kind of be like a simple shader language for the web.
Um, I think I, I don't know if that's the goal for the people who are working on css, but I think that would be a pretty cool, cool thing to go towards.
Andrew: Css, Houdini kind of fits that, right? Like you can kind of extend CSS to do whatever you want and do all the hard stuff somewhere on the gpu.
Christoph: exactly. Yeah. Yeah. So I think, you know, we, we talked so much about open source, right? And so one thing that I'm, I've always been so excited about, and that's something that, I learned on early on, on mood tools. Like mood tools was supposed to be this, like this is 40 advanced or, or inter [00:54:00] intermediate or advanced like JavaScript developer, which didn't exist even, we weren't in like advanced JavaScript users in 2007 or eight, right?
It was like still so early. Um, and so I think we kind of ran that community wrong, you know, and I think it would've been a hundred times more successful project if we had said, no, this is a beginner for new project. You know, here are the docs, and like, here's how you figure out how to use it. Um, and so, so everything about open source that I care about nowadays is like, make it as easy to use for anyone as possible because you want to bring everyone along, right?
And so this is why I'm like, okay, you know, what if CSS could be an easier or simpler shader language, you know? And like there's too many tools out there that are hard to use or not fun and like, you know, not for beginners, right? And so, um, I'm just excited to make something that has a great user experience and great develop experience and so, Yeah, that's maybe why I'm never happy, right?
Because I, I always get angry when things are not, not there yet. And you know, like sometimes I fail at myself, right? Like, it's not, say everything I say, it's not like, oh, I'm so good at [00:55:00] this. It's more like, this is what I aspire to make. Right? And so, um, I'm hoping to play a part in like, making things easier to use as well.
Justin: Yeah, absolutely.
Andrew: Yeah. So, uh, we, we've alluded to it a little bit, but you've, uh, you're starting a new company, uh, Athena CRI Crisis being the first product. So congrats on the announcement that just went out today. Uh, what are your goals with the company? Like, what, what do you want to do next other than, uh, you're starting with open source, but what after that?
Christoph: Yeah. Um, this, this is such a great question. Um, I didn't know I was going to build a company a few months ago, so this, um, this kind of just happened. I knew I was gonna ship the game, um, and I. Just it, it just was clear to me after a certain point that like, you know, building my own company is the only way to just do that.
So, you know, it's not that, oh, I really want to build a company. It just seems like the thing you have to do to go and like, build the things and do the things that I want to do. Um, and so, um, yeah, [00:56:00] Athena Crisis is the thing that I'm gonna spend most of my time on. I'm the only engineer. Um, there's six people working on it in total right now.
There will be more soon, but, um, they are working on the art and the music, um, and administrative stuff, translations, all that sort of stuff. Um, I'm currently looking for, um, a narrative designer. Also, maybe a community manager. Like one of the things we didn't talk about is that, Um, Athena Crisis is supposed to be more of like a hybrid, online, offline experience.
So it, you know, I, you know, you'll, you'll, it's not just for you to play on your own. It's, um, and let, I mean, if you want that, that it will be supported and that's totally fine, but the idea is that you actually go and you play with friends, um, as well, or, you know, with random people on the internet and however that will go.
Um, so, you know, I am hiring, um, people all around the world to, to like help me in like putting this game together. Um, my engineering time will be mostly focused on open source or the video game. Um, and then after that I'm hoping that I'll be able to make more games. And it, you know, kind of depends on how this one goes.
Um, and, you know, it's something that I want to exist and there's a bunch of other things that I want to build [00:57:00] that I want to exist as well. Um, you know, gaming is one thing. There's other things that I'm excited about, but I'm not yet able to share it. You'll have to wait and see.
Justin: We, we typically ask a forward facing question, but you, you sort of preface there that you've got stuff that you want to keep in your bag. So I actually want to, to ask a little bit of a different question. Um, so. You know, you've made this, this choice. Anytime someone decides to make a company, it's, it's, it's a fairly big choice.
And, you know, especially you have kids. Um, what I really wonder, what was the, what was the impetus? What was the thing that, that, that just made you say, all right, you know what, this is, this is time, this is what I need to do. And sort of like, how did that, how did that unfold for you?
Christoph: Yeah. Great. Um, Just before I answer that there, there's like a little add-on to the previous one about like, what, what my goals are because you were talking about forward-looking stuff. Um, I want to just, um, you know, work on this game. I wanna build it, [00:58:00] I want it to exist. I'm glad other people wanted to exist as well.
Um, and I want to do open source and, you know, there is a really high chance that maybe that doesn't work out. Um, but I also feel like I can go back and do something else later. Um, you know, um, I, as I said earlier, I'd be happy to go back to Meta. Um, there's other amazing companies out there. Um, but this just seems like something that I need to do right now.
And, um, a, as part of the process here is that, um, and you know, having two children and the family is like a huge part in like, making that decision when you're an engineering manager or like in a leadership position in like, in like a. Company that is not yours. Right? Then you give everyone else the ability to monopolize your time, right?
Like your calendar internally is like open and people will just go and be like, oh, you know, there's another spot for 60 minute conversation. Right? And then it's like, and then as you just sit there and you like open your laptop, especially if people working remotely and you work from home a lot, you open your laptop and you're just in video calls like from nine to six basically, right?
And then [00:59:00] it's like, what, what does this add up to? And, and it's so hard for me to, to be like, tell my daughter, so like, Hey, I didn't spend time with you because I was in this meeting that I just really don't care about and that, you know, doesn't matter to my life or your life or anyone's life really, right?
Where it's like we're just like in a very slow organization where nothing is moving. Um, not saying that my just current, previous experience was like that, but you know, I, I think people who have been in meetings like that will emphasize. Um, and so one part of starting a company is just that it gives me much more control over my own time.
I don't mind working at nights and the weekends. I care about working a certain amount of time, and when I feel like it's enough, then it's enough. Um, but I don't care about being there from nine to five, being stuck in meetings all the time. Um, so I just wanna have more control. Um, and, you know, that's also, you know, easily said, but then if you're starting a business in Japan, there's insane amounts of paperwork involved.
So, you know, it's not like all of that is just like fun, you know, but it, it [01:00:00] feels different because it's something that I care about that like matters to me and that, you know, I'm hopeful that that will also matter to my family. Um, and it's, it's just a completely different feeling to do boring paperwork or working on spreadsheets when it's your thing compared to when it's somebody else's dream that you're just part of
Justin: Yeah. Uh, I mean, it's cool. I, I'm so glad that you're doing it. I mean, I, I think this is, this is something that everybody, at one point in. In their life. If they have the privilege to be able to support themselves and do it, then you should take a moment to live for yourself. You know, before, before retirement if possible.
Christoph: Can, can I just add one thing that this
is like, because it's so interesting, like if, if you have the opportunity, right? And, and this is definitely, I, I grew up in a blue collar family in like the countryside in Austria, right? And so doing this sort of stuff is something that I never imagined I would be able to do.
Um, and I just thought, and, and like, you know, you, you've mentioned family for a few times and it definitely seems like a really [01:01:00] crazy time to do that when my children are so young. Um, and so, you know, the only option is to do it later. Or now. Right. So, so, and like, I think I would regret if I never, if I never do it, and, um, I was really fortunate to, you know, we talked about some of the stuff that I did.
I was really fortunate to be part of those things. And also having, um, that luxury, I would say, to, to try this and see if it works or doesn't. Right. Um, and I recognize like most people don't. Um, and to me, I'm usually pretty risk averse, so taking a risk of starting a company. Um, you know, I'm, I'm nervous, I'm really nervous about it, you know, but I'm, I also feel really grateful that I'm able to just go and try this for a little while and see how it goes.
Um, yeah, just wanted to share that.
Justin: Yeah. And I think it would be great. And you know, the thing that you said earlier, it's like, you know, if it doesn't work out, I can always just get another job. It's, it's something that I try to, to remind people. It's like, you know, especially if you're good and you've been doing this for a long time and you're like thinking about, [01:02:00] oh, should I do something for myself now?
It's like, you can get another job. You know, just try it
Christoph: Yeah, I'm not sure if my.
Andrew: If, if, if you never open source the game, they never have to see it.
Justin: outta sight, outta mind.
Andrew: Uh, thanks for coming on, Christoph. It was a lot of fun talking to, to you.
You have like a wealth of information and history in the dev tool space and I'm excited to see where your games company goes.
Christoph: so much for having me.
Justin: Yeah, Christoff, it was a pleasure. Um, and I'm, I'm really excited for you. I'm excited for this direction, this new chapter in life. I really, honestly just wanna see more people exploring their passion and, and finding some joy in the world. So, uh, yeah, we wish you the best.
Christoph: Thank you.