Noel: Hello, and welcome to PodRocket. I'm Noel. Joining me today is Matt Pocock. Matt's a developer advocate at Stately AI, and part of the XState core team, and as Wes Bos once labeled him, the Rodney Mullen of TypeScript. Welcome to the podcast. Matt Pocock: Thank you so much, Noel. It's lovely to be here. Noel: Awesome, awesome. I guess to jump in, let's talk about your background a little bit. What do you do as a dev advocate at Stately AI, and what made you get into this position? Matt Pocock: Yeah, well it depends how far back you want to go, really, but let's start with this really, which is I was a part of the XState core team going back a couple of years now, and I got into XState because ... XState, by the way, is a library for building state machines in JavaScript, you may have heard of it. I was part of that team, and I thought, "Wow, this has a lot of potential, and it has a lot of potential because it's a very visual way of building code." It uses a lot of visual formalisms like boxes and arrows to mean certain things. Matt Pocock: One thing that we always talked about in the team was could we build a visual way of building state machines, and we'll get into what state machines are in a bit. It just made so much sense to join forces, and talk about building this cool tooling that we're all thinking about and planning. I guess in March or April last year, David said ... He was working at Microsoft, this is David Khourshid, by the way, who's the founder of Stately. He said, "I'm working at Microsoft, I love it, but I've got this idea. Do you want to go in on it with me, and we'll try and build some stuff?" We all just said, "Yes, okay. Sounds great." Then a week later he quit Microsoft and was starting it, and we all quit our jobs and joined Stately. Matt Pocock: We're formed really out of the XState core team, and with a couple of awesome hires and people we've hired this year and stuff. Just a couple of weeks ago actually, I changed from being a developer there to being half developer, half dev advocate. Now I'm on the airwaves, talking about Stately, and mostly on Twitter talking about stuff. I've recorded a course this morning for it. All sorts of stuff going on, so it's a really exciting time. Noel: Nice, awesome, awesome. Let's start kind of higher level, like you suggested there. What is a state machine, and why should devs care about them today? Matt Pocock: Yeah. Okay, let's approach this from a frontend point of view first of all. Because you've probably coded something that was really, really complex in the frontend, and you probably have felt at some point your tools buckle and break beneath you. Like you've reached the limits of your tools, kind of what they were designed for, and really what they were thought of. A typical example of this, let's say in the React world, is building something using a lot of useEffects, right? If you've used useEffects and used React in the past, then you know, and I'm sure other frameworks have tools like this, it's kind of a very, very simple tool, but it's a very sharp knife, and you can cut yourself on it very easily. Matt Pocock: Now what state charts do ... State machines are kind of like ... They're probably something that you've learned about, if you did computer science at university, which I didn't, but state charts are especially what XState is designed for, and they kind of add layers onto state machines, and make them a bit more usable, a bit more powerful. What they do is basically they can handle any complex requirements that you might have in the frontend. Anything that you think, "Oh God, I really don't know how to build this," state charts allow you to build it, because they give you a set of primitives that you can bring to any situation, and coordinate side effects, and timers, and listeners, and all sorts of things all together, and they let you do it with boxes and arrows. They let you do it visually, which is incredibly cool, because you can build anything complex using relatively simple tools. Noel: Got you, got you. I guess what does that development process look like, if you want to get started? Matt Pocock: This would have been a very different conversation like a year ago to what it is now, because a year ago you would kind of take something ... Take XState, let's say, download it from npm, and you would start building out your machines kind of like with almost like a JSON object basically. Let's say that you have a, I don't know, you're building let's say one of those cards in Netflix, where you hover over it and then the video starts playing. A relatively complex thing to build. You have the not hovered state, where it's just chilling and it's not doing anything. That then receives an event, and you go into the hovered state. Then there you maybe wait for the video to load or something, and you go to that video loaded state, and it starts playing. Matt Pocock: All of that, if you code that with useStates and useEffects, or whatever your framework is doing, you're going to hit some barriers. It's going to be hard for you to really get a high level overview of what's going on. Whereas if it's all in a state chart, if it's all in this adjacent object where you can see where everything goes, then it makes it a lot easier. Whereas now you can actually start building that stuff visually too. Matt Pocock: Just this year we shipped a tool called the Stately Editor, which is available at stately.ai/editor, and what that does is it allows you to build state machines visually. You can actually just go there, and click, and drag, and drop, and build these boxes and arrows really completely visually, and it's incredibly powerful. It's so cool to use. Noel: I guess to just help contextualize, what would the state chart look like for a Netflix card editor or card view with hoverable boxes for shows? Matt Pocock: Totally. We're not in a visual medium, so I will try my best to paint a picture. Noel: Right. Matt Pocock: The idea is imagine if you have like let's say two big landmasses in the world with an ocean between them. On the left side you would have the not hovered state, and the not hovered state, there's nothing going on in it really. It's kind of like America. Then let's say you bring it over to the UK, and then you have this hovered state, where all the cool stuff happens, and all the history is. Then inside there, inside the UK, you can zoom in a little bit, and you start seeing regions within it. Then you've got the video loaded state or video loading state, where some things are happening, and you can run what's called a service inside there, and add async behavior, add side effects. Then when that's finished, you can go to somewhere else in there, or if it errors, you can go somewhere else. It's all about having these kind of ... You can look at it from a high level, and view this top down perspective, or you can start zooming into different functionality, and see how everything works. It's really, really powerful. Noel: Got you, got you. Before this visual editor recently came out, what did the development process look like? What would you define? Was it just JavaScript objects? Matt Pocock: Yup, it's just pure JavaScript objects. We had some sort of more rudimentary tools before, so we had a visualizer, which was kind of like a ripple really. We've still got another version of that. In fact, we shipped another version last year, which is where you can just paste your code in, and it would show on the left hand panel what your state chart looked like. Even that is pretty powerful, because you can just take your code and visualize it, and see what's going on. It's pretty cool, but having drag and drop, it just makes the whole library a lot easier to learn and a lot more intuitive. Noel: See, that was kind of my next question, was have you guys found teams struggle to ramp on new developers who haven't spent a significant amount of time in the frontend space? This seems like a pretty, I don't know if abstract concept is the right phrase, but it seems like it'd be quite a few jumps for someone who's new to web dev to just kind of leap into. Have you guys encountered that? Matt Pocock: Totally, it's a whole different way of thinking actually. Noel: Mm-hmm (affirmative). Matt Pocock: To be honest, it's harder to convince people who are more entrenched in web dev than it is to teach a beginner. Because if you're really entrenched in web dev and you think, "Right, I do this imperative stuff. All my stuff is kind of like in these async function calls. I like to use React," whatever, whatever. It's just harder to break out of that mental model, and start thinking of everything in terms of states, and events, and services, and actions, etc. There is a lot of terminology to learn, but there's a lot of terminology to learn in traditional web dev as well, and so state charts ... We're in the process of rewriting the docs at the moment, like making a lot of this stuff more beginner friendly. We think actually if you show this stuff to a beginner, they get it, because it's so much more visual than the traditional web dev approach. Noel: Yeah, got you, got you. Have you found that the drag and drop editor is making that quite a bit easier for ramping? Matt Pocock: Totally, it's revolutionary. Especially one of the things that we've focused on as well is integrating it into tooling, so we have a VS Code extension, where you can actually just have your code on the left hand panel- Matt Pocock: and have the visual stuff on the right-hand panel. You drag and drop, and it changes your code. When you have that level of integration, it just feels so cool to work on this stuff. And it just makes it so much more maintainable as well because let's imagine that you inherit a code base and you say, "Okay, all right, this code was written two years ago." State charts have been around as a formalism for... I can't remember. I always go like, "Oh, it's a number of years." I think it's between 30 and 50 or something crazy, so it's not going to change. And you inherit this code from two years ago and imagine you could just click "Okay, open the visual editor." I just get to see how it works. I get to simulate it. It's so cool. Noel: Nice, nice. So I guess coming in... Say you're trying to sell the typical entrenched React dev, who you're saying it's hard to get buy-in from sometimes, and they've encountered these cases where they have built components and they get hairy and they have gone in, but they spent enough time in the space where they know a lot of the common pitfalls and they are pretty good at separating concerns and mitigating that. How do you sell the state machine-based logic and using state charts to simplify your developer experience to those people that are so entrenched? What's the pitch there? Matt Pocock: Yeah, the idea is you use it for complex things. You use it for the most critical infrastructure in your app for the most difficult stuff that you had to work on in code. And you'll know when you need it. You know the feeling of when your tools start creaking under you and you feel like you can't express what you want to express, or you keep shipping bugs or things like that. It's a feeling that I think we're all pretty familiar with, the sensation of riding on the seat of your pants and not quite stretching your tools to the limit. So if you're feeling that, maybe state charts are something you should consider, because even if you don't end up using XState itself, actually just knowing about finite states and knowing about the tools that XState gives you and the mental models it gives you is pretty powerful. And you can take that and put it in your normal useState, useEffect stuff. Noel: Yeah. Perfect. Yeah. That makes sense to me. I guess I'm curious, have you found that there's a common journey that a lot of the members of the XState core team have been on together? Did people arrive with this kind of affinity for state-based development from a common background? Matt Pocock: It's a really good question, actually, because I think it comes from just fury and terror at the code tools and just I think you ship one too many bugs, and you realize there must be a better way. And for me, it was about... I was working at an agency, and actually, the Netflix video card is actually a perfect example because I was working at a company that did a lot of work with TV companies, actually, and so the Netflix video card was something that they wanted. And that was one of the last things that I coded in useState and useEffect and I thought, "Oh God, this code is just so awful. Man, this is terrible." And as I was building it, I thought, "If they stretch requirements or if they change things or if there's something new that comes out of this, I'm going to have to dive into this code, which is spread out over four component layers, including a carousel, all that stuff. And I'm going to have to try and change it." Matt Pocock: And I left that company and then I joined a different company and I started working on a call app. It was a really cool application, actually. It's called Agent Relay and it walked you around... You could explore a property remotely with your estate agent, which was pretty cool, so on a video call with them going around this place. And I did that in XState and the difference was night and day. I could look at the state chart that I built and I just go, "Okay, I know exactly what's happening. And if I need to change something or new requirements come in, every single requirement is captured in one place. It's not spread out over components. It's not in one big component even. It's just in one place and I can just add anything I need to." And that was the light bulb moment for me. That's when I started joining the XState core team. And one of the people in our community... We have a Discord, by the way, which is Discord.GG/XState. [crosstalk 00:14:55] get one of the people in our Discord. Yeah, called Rob Penner. He was building something in the backend actually, which it helped two Steinway pianos communicate with each other. It was crazy. So cool. And you just had this- Noel: You would play one and it would make the hammers fire on the other one. Is that what it's doing? Matt Pocock: Yeah, I don't know what the details were, but yeah, it was basically linking up those two things and so cool. And it used XState for it as a medium in between them because XState, you don't need to use it, with React you use it with anything. And I just thought, "Wow, if one library can fix all my problems and fix all of his problems, totally different problems, then it must be something special." Noel: Yeah, nice, nice, very cool. That led into my next question is my understanding correct that most XState users are using it for web-based frontend work? But it's agnostic. It's just a JavaScript framework. You could use it for backend code as well. Matt Pocock: Just a JavaScript framework. Yeah, it's Vanilla JS. You can run it in React Native. You can run it in React. You can run it in Node. You can run it in Deno. You can run it wherever you like. So yeah, some of the work that I've done, when I discovered XState, I thought, "Okay, I'm going to use XState for everything. Perfect. Lovely." And I started putting it in backend lenders and that sort of thing, and I'm putting it there and it's still pretty cool. You can see everything that's going on. You've got all the visual elements, everything like that. I've also used it a lot in CLIs. And in fact, when I was working with that CLI, I noticed that Gatsby, it's backend build process... Gatsby is a JavaScript framework Noel: We use if for the website and blog. Yeah. Matt Pocock: It uses XState for its build process for managing all of these parallel running processes for listening for watch events, all that sort of thing. So anything complex basically use XState or [inaudible 00:16:53]. Noel: Gotcha. Yeah. Yeah, that's interesting on the CLI front. Yeah, I'm also sitting here like, "I do a lot of work on Discord bots to bring around..." And I think that there'd be a lot of good use cases here because there's very controlled inputs and outputs, but it would be easy to represent those as states in a state machine. Most of them are not as complex where I've run into these kinds of issues, but I think that might be a good learning platform for me if I wanted to jump in a little bit deeper. That leads me to another question of if there are devs who are interested in... They want to get into this, but they really spend all their professional time working on some large code base, and it can be tricky to determine where to start. I think you said before that if you have some core that's really complex, that's a good use case for XState. Is it easy to take XState and add it piecemeal to an existing code base to a given React component, for example. Matt Pocock: Yeah, definitely. It's not a framework like Redux, which demands a certain style of architecture from you. It doesn't make any demands of you like that. You can have it in one component in your application and then not use it at all anywhere else. It's incredibly minimal. You can put it at the root of your app, if you want to, and have a kind of global state machine. That's what we do for a lot of stuff, actually, that we build internally. But yeah, it can be as small and as unobtrusive as you like. Noel: Nice, nice, awesome. Maybe we should talk a little bit about Stately. What is Stately's relationship with XState? Matt Pocock: Yep, so Stately is the XState core team, basically. We are obviously a company, and basically, we are interested in maintaining XState and keeping XState running. One of the things that we're doing right now is actually just, as a company, getting together, rewriting the XState documentation. We're going to push out a version five of XState. XState has been in version four, five, I think two years or maybe longer, like three years maybe. We really value stability and stuff, so we just kept it on the same major for a long time. But we've had a lot of changes that we've wanted to make in a major for a long time, so we're pushing all together. So yeah, so the open source and the closed-source stuff is interchangeable for us. It really is just the VS Code extension, for instance, is open source, but the editor itself is closed source. And so that's where the boundary is, and we work across the board. And we're actually hiring at Stately as well. So if you want to be an engineer doing that stuff, so please, join us. Noel: Gotcha. Gotcha. Yeah, so what else is in... Is there anything else in Stately's purview? So you said you had the VS Code extensions, the work on the core library, which is also super important, the visual editor. Is there anything else that you guys spend cycles on? Matt Pocock: Yes. There is some secret stuff that I'm not at liberty to reveal yet, but it has some cool implications. We're looking to use the editor and the visual editor for... Matt Pocock: lots and lots of different things, and we've been hiring developers to cover that stuff. Noel: Yeah, I'm sure those three or four things I listed are a... Insurmountable amount of work in and of themselves. So I think [inaudible 00:20:21]. Matt Pocock: They are, yeah. But there's some cool stuff going on under the radar as well. Noel: Yeah, nice, awesome, awesome. In doing my homework for this, I saw that you have a lot of material out online concerning TypeScript and type generations, or type generation. Has that stemmed from your work at Stately, or is that a separate passion that just has a little bit of overlap? Matt Pocock: This is a cool story, actually. So I've learned a lot about TypeScript in the last two years working on the core, because XState itself is a very, very complex TypeScript library. It's really pushing the boundaries in a lot of ways. And I credit my colleague, Andrzej Rijk on Twitter and Matthias Brzezinski for that. He's kind of a real TypeScript genius. He absolutely hoovers up this stuff, and so working with him is a pleasure. Matt Pocock: For me, what that's enabled me to do is learn a lot more about it. And my initial in the XState core was working on a library that basically took XStates, like the code in your application, and spit out some stuff that would help make it more type safe. And it was called XState cogen at the time. And I used it in production. It was really, really good. Because XState... Its API was never really designed for TypeScript. It's just like a big object that you kind of do stuff with, and that's not really very conducive to good generics and that sort of thing. Matt Pocock: And it took a long time for us, but we always talked about bringing this XState cogen stuff into core so that loads of people could benefit from this TypeScript goodness that we were doing. And about three months ago, we finally did. There is now an official XState CLI that takes your application code and spits out Type generation stuff. And it's built into the VS Code Extensions integrated with everything. So you can get this crazy, beautiful TypeScript experience. One of the best actually around, just with a little bit of extra fiddling and extra little tips. So that's one of my proudest contributions to Stately, I think, and Andrzej has helped me all the way too. Noel: Nice, nice. So just to reiterate that one, so there's a CLI. And then, this logic is also used in the VS Code Extension. What does the CLI do if you're only using that? Matt Pocock: Yep. So basically what it does, if you have an XState machine in one file, let's say like machine.ts, and then what the CLI would do is it would generate a file alongside that, which is like machine.typegen.ts, which gives you some sort of extra stuff to go in there. What the VS Code Extension does is it just means you don't have to run the watch process in the CLI. So it just goes like "blurr", it's all good. And just building that in just helps, helps everyone really. And it means that people who don't want to use the VS Code Extension can still use the .typegen, et cetera. Noel: Nice, nice. This is a weirdly specific question, but if you're working on a project under source control, and you're like trying to run this, do you guys recommend that you commit those generated type files or let [inaudible 00:23:39]? Matt Pocock: Great question. Git ignore them, always. Noel: Okay, yeah. Matt Pocock: So any generated code should never be in your... In your Git, essentially. Noel: Yeah, yeah, sure. In the... I've encountered some libraries in this type generation space where they're like, "Oh, it's faster if you just check them in," and it's never consistent. It's always super noisy. Matt Pocock: Yeah, yeah. Noel: I don't feel like this needs to be under source control. It's not- Matt Pocock: Yeah, just run it on a post install basically, and then it'll always be there and update it when you dev all that stuff. Noel: Nice. Nice. I guess, when you set out to do this and build this Type generation logic, was the... My vocabulary is failing me slightly. But were the APIs similar enough that it was... There was parity and it was easy to do? Were there any shortcomings where there were cases that you were not able to generate types for consistently? Matt Pocock: Yeah, this is a really, really good question because it's super complex. So just like an architectural overview, what we did was, essentially the problem space is, we have a file, like a string, essentially, of code where there may or may not be State machines in that code. How do we understand what's in that code in terms of its machines? How do we pull that out? And then, the type generation is sort of secondary, right? When you understand all of the bits in the file and you have that kind of Thanos level power of, "I understand everything," from there, you can do all sorts of crazy stuff. Like all of our visualization stuff comes from there. All the visual editor stuff is powered by the ability to extract machines out of the code. So how do we do that? Matt Pocock: We did that by, we tried four different methods. The first one I did, we actually used esbuild to compile your application and run that code actually, which didn't work. Essentially, it was quite slow, even though we were using esbuild and all that stuff. And we tried a couple of other methods, and the method we landed on was an AST based parser, which I think I wrote and Andrzej helped. And it basically just looks at the abstract syntax tree, just like eslink does, which is super fast. And because XState is mostly just adjacent object, it works really well and works consistently. So it means that you can just look for things that look like a machine, and then grab it, and extract the information. Noel: Gotcha. Gotcha. And then, I guess yeah, once you're in that state and you've found all of the machines and can parse them, is generating types for them pretty easy? Matt Pocock: When you know all the information about it, you then need to generate something which can essentially represent all of the... So, okay. Something that we have in XState, and a problem that we were trying to solve is that you can imagine you have the two land masses again. You have your two states, then you have states inside states, and states inside states. You need to know, essentially, all of the states and their hierarchy in order to generate some types, right? And that's really hard to do in TypeScript, especially with the legacy stuff that we had left over in V4. It just wasn't going to happen. But what you basically want to do is generate a list of strings that represent that entire hierarchy; a.b, a.b.c, a.b.c.d. Matt Pocock: So, what we did was we basically just wrote that to an interface, like a TypeScript object in this kind of companion file. And we wrote a bit of code that would insert it back into your machine. And it would insert it into your machine, and then it would go through the core library types. And the core library types would have to then work out this information and work out what to do with it. So, it was an enormously complex project in terms of Type stuff, doing stuff I've never seen done before in a TypeScript library. And I don't think that's... I've never seen that as a pattern anywhere else actually. Usually generation just pumps out code that you then import directly. Whereas this was importing or creating the file, importing it for you, but actually not creating any run time overhead at all. It's just another Type that just gets added, which is kind of crazy. Noel: Yeah, yeah. I don't think I have either encountered anything that works that way, yeah. Interesting. Were there any fundamental problems that you guys encountered when you started down this path that you didn't expect? Or once you'd realized this was the approach you wanted to take, did it all line up pretty easily? Matt Pocock: Well, we took a bunch of other approaches and found fundamental problems with them basically. Noel: Sure. Matt Pocock: So, the other approaches we had was we created a new... My first approach was to create a new dummy package, like XState compiled essentially, which you would then import from, essentially. So there, you could plug in all these crazy types and they would live in your node modules, basically. But it just didn't feel good really. And then you need to change all your imports and stuff. Whereas this, you literally just add a flag to the machine, save the file and it's done instantly. Noel: Yeah. Matt Pocock: So cool. Noel: Nice and awesome. I guess yeah, to pull us out of the weeds a little bit and reel us back, in this space of tooling that exists to help developers manage complexity abstractly, do you guys have major competitors or other people you're looking at in the industry who are doing either similar stuff with State machines or with XState specifically? Matt Pocock: Yeah. It's quite a rare space, not that many people are doing it. We're sort of bumping into people or workflows that we consider competitors quite often. Because let's say that you are planning a feature. Really, we want you to be using something like our diagramming tool in order to properly plan it, to simulate it so that everyone can understand it, and you can pass it off to the devs. There's a lot of potential here for product-to-design-to dev handoff, really being improved if people are using this stuff. So tools like WinSCP, tools like Excalidraw, Miro... Mira or Miro, I can't remember. Are sort like competitors in that- Matt Pocock: in that space. In terms of other companies doing things with state charts, there's YAKINDU is the one that really comes to mind, but they're more focused on, I don't actually know much about what they do, but they're not in the JS world at all, really. They're focused more on other languages and low level code. So I think we're fairly unique in a couple of fronts, really. But there's so many tools that are saturated right now, that are all about helping devs to plan stuff. And if we can just get a little slice that pie and pull those people into using the Stately tooling, then that's a win for us. Noel: Would you say that the focus of Stately is really at that planning level or is it more, well, we know we want to build? The design is there. Now, we have to figure out implementation. Which of those two points do you think Stately fits into? Matt Pocock: Yeah, I think Stately can cover both. So if you think of this like, if you imagine planning on a state chart, in a very high level, you basically have this formalism where you go, "Okay, we need to go from this state, to this state, to this state." That does not need to be precise. It doesn't need to be accurate for a dev to be able to go, "Okay, I get what you mean." And imagine that a product owner is building this. They didn't know nothing about state charts, but they can plug together boxes and arrows. They know what they're doing there. And they understand boxes within boxes. They understand that. Matt Pocock: And so, when you get to that point, and a dev goes to them and goes, "Okay, well, we might need to add a loading state here. Or this might need an error state associated with it. Let me just formalize this a little bit, turn this into my language." You hand that back to the product owner. They can still see what they built, basically. And the dev can still see, now that's just ready to go into production code. That's the crazy thing, really. You can work at different levels of fidelity. Noel: Yeah. Nice, nice, cool. Yeah, it'd be cool to be an organization doing that, end to end. Do you guys have users that you know are that bought into the ecosystem that you work with? Matt Pocock: Totally. Yeah. Well, XState is used in tons of different companies. It's used in the Lego group a lot. It's used in AWS, and Microsoft, in Apple. It's used everywhere. Noel: Awesome. Matt Pocock: It's so entrenched in the industry. And it's especially used in places where they really value robustness and they have a lot of complex problems to solve. So it's not necessarily very beginner friendly, because a lot of beginners are not focused on the really complex issues. Whereas, having XState in your toolbox is so useful for so many things. Noel: Yeah, totally. Yeah. In the same vein then, are there other libraries that are focused on state charts that are not JavaScript libraries, that you guys look at quite a bit? I'm sure- Matt Pocock: JavaScript libraries that are focused on-? Noel: On other languages. Other state chart frameworks, not JavaScript based. Matt Pocock: Let me think. None of them come to mind. I know that there's some in .net, in a couple of other languages. Noel: Sure. Matt Pocock: I'm really bad at learning languages, basically. I, basically, learned TypeScript or JavaScript seven years ago or something, and I've been trading off that ever since. Noel: Sure. Matt Pocock: So, I'm not very aware of the stuff that's happening other languages, but, yeah. Noel: Yeah. Where I was going with that is I was curious if there was a more lower level academic pursuit of, how should we be developing state machine based tooling to empower devs to write code in whatever their language of choice is? Matt Pocock: Yeah. Yeah, that question has a very storied history, because the guy who came up with state charts, called David Harel, he's an academic, and he was working with the Israeli flight school, basically, or the pilot program, or, basically, building planes and building safer planes. And what he wanted was a visual formalism that, he could go into these meetings with pilots, with all these different people, and everyone could understand what they were building. Matt Pocock: And so, what he ended up with was this, basically, state charts. And he formalized this and you can parallel states, and services actions, all that stuff. And they had this great big board up on the wall, and with everything, basically, inside the plane and what it was doing. And this pilot came in, and he says, "Oh, what's that?" He said, "Oh, it's a state chart, or it's what the plane does." And he looked at it for a while, and he said, "Oh, that's wrong. That little arrow that's going there should go there." Noel: Yeah. Matt Pocock: It just widens the barrier for contributing to these complex systems. Noel: Yeah. That's a powerful story. I think, because typically, engineers are in this space where we can't imagine that the user would have any grasp of what we're trying to architect and build. So, yeah, that's super cool. Noel: Yeah, amidst this conversation and preparing for it, I was thinking back to my computer languages course in school. I'm really reaching into the memory banks here, but yeah. I feel I remember my professor talking about writing code that is bug free on day one. He was very much into this. We need to be using well defined grammars, optimally using a state machine. That's how we write code that is not going to have bugs, once you publish it. You can get 98%, 100% test coverage and still have bugs, because you do not understand all of the states of your system. Matt Pocock: Yeah. Noel: And yeah, he always told some story about NASA, code on a satellite or something, being a good application here. Matt Pocock: There you go. And those implicit states are everywhere, in terms of how we communicate to each other in our organizations. Have you ever received a design from a designer and thought, "Oh, there's an implicit state there. They've missed something. I'm going to have to work out what that looks, because they didn't think of it." Noel: All the time. Matt Pocock: All the time. Right? That is the design developer handoff, in a sentence, essentially. Implicit states. Noel: What about XYZ, is always the dev question, right? What about XYZ? Yeah. [crosstalk 00:36:27] What about covered? Yeah. Matt Pocock: Absolutely. Whereas, if that is written in black and white, and it's somewhere central in your organization, and you can all refer to it and go, "Oh, I see, we missed something there." That's the organization I want to be a part of, because you are really focused on... I imagine a version of JIRA, where everyone is working off the same state chart, and you assign different jobs based on what states people should be building, assign designs per state, all that stuff. It's state chart driven development, basically. Noel: Yeah, totally. Totally. Yeah. That's an awesome vision. That's probably as good a place as any. Is there anything coming down the pipe that you guys are working on at Stately, at large, that you can talk about? I know we touched on this a little bit already, but anything else you're excited about for the future? Matt Pocock: Well, for me personally, I'm taking some of the TypeScript learnings that I've been working on over the past couple of years, or my experience leading teams of TS developers before that, and I'm working on advanced TypeScript course, which you can look at at mattpocock.com, which should be launching sometime this year. In terms of Stately stuff, yeah, we've got a bunch of stuff coming down the pipe. Watch out for V5, that's launching soon. You can follow us on Twitter. I'm doing tons of tip videos these days on Twitter, focusing on XStates and focusing on TypeScript, as well. So feel free to follow me @mpocock1. I really need to get a better Twitter username. But yeah, just watch this space, really. And there's some really exciting stuff that I can't talk about yet, that we'll be launching soon. Noel: No worries. Yeah. We'll have listeners keep their eyes out. Cool. We'll get links to all that in the show notes, so people can find it. Awesome. Well, thanks for coming on and chatting with you, Matt. It's been a pleasure. Matt Pocock: Yeah. Been really, really fun. Thanks, man. Speaker 1: Thanks for listening to PodRocket. You can find us @podrocketpod on Twitter, and don't forget to subscribe, rate, and review on Apple Podcast. Thanks.