XState Creator: State Machines & Startups

So, as a first-time founder, one of my biggest lessons is just because you are a solid developer does not mean you can do the CEO and everything else that's required. It's an entirely different skill set. Talking to customers, doing all of the business things. You realize that the tech part actually becomes a small part of it. It is about the network, you know, talking to your users, etc., and prioritizing features and yeah, there's a lot. Welcome, David, to the podcast. Thanks for having me. So the first question is a warm-up question. What are potentially any special skills that you have that people might not know about? I play the piano, but I mean it's in my username everywhere, so there's that. How long have you played the piano? I've played since I was five, six years old. Nice. So, have you done like recitals and stuff? I have. Yeah.

Lots of recitals. I went to university for piano. Oh, wow. Played it in college. I did. And then from there, I decided to do web developments because, you know, that actually pays the bills, not playing piano. Yeah. But there are like, you know, music theory concepts that kind of build on each other. I feel like in a lot of ways like a lot of great programmers were former musicians. That's absolutely true. There are so many developers that I know that they just they're obsessed with music, too. They're musicians themselves and they're just really great developers. So, I feel like there has to be some sort of association. Definitely. So you're famous for creating XState. Why did you create XState? So, going back to when I was a junior developer and you know leading into it, this is fresh out of college. I, you know, studied music piano performance for a while and then I got my junior developer job.

And when I got my first big boy job, like an actual full-time junior dev job, I was working in a jQuery PHP just mess of an application where there were many multi-step workflows. And as a junior developer, even back then, we were we're talking like the Angular backbone days, we had to work with just really confusing logic and multi-step flows, lots of its if statements everywhere. And as a musician, I sort of we sort of think more, you know, visually just more abstractly. So we can't just look at a bunch of if statements and be like, okay, yeah, that makes sense. Like to me, especially as a junior, that was confusing. So I started looking up like you know just like music notation there has to be a better way of understanding this mess of logic and so I was looking at flowcharts and then I got into state machines and statecharts and I'm like hey these diagrams are pretty nice and they help us both organize the way that we you know understand app logic and also it just you know it makes it a lot easier to consume.

So I got really obsessed with like you know just the idea of state machines for representing app logic. So eventually I created this library called XState and you know from there I've just been listening and working with lots of companies on just their specific app logic problems and realizing that it's just everything comes down to you know applications are a huge graph. flows aren't just step one, step two, step three, but really there's like lots of branching, nesting, looping, all these different things that make applications really complex. And my goal is just to simplify that all and make it easier to understand. So would you say that most applications should use state machines? I would say that state machines are more of a very useful tool as a mental concept but not something where it's like oh we have to restructure our entire application as a state machine and there's a few reasons for this first of all a lot of applications are actually conceptually simple where you know you could think of a CRUD app where it's just we're fetching data we're showing it on the UI it's not something that requires many complex flows or anything like that so using a state machine might actually be overengineering in that case.

And then you have the case where the application and the problem domain is complex but it's sort of too late. You have a legacy application. You have code where it's like we can't really afford to refactor this because that's just going to break a lot more things. So that's why I think state machines are a great tool for thinking. And if you have the luxury of using it to actually model your app logic, then that's great. And I think that it's a really good refactor target, but it's not something where every application needs to just completely redo everything in state machines. Got it. And you talk about kind of like the visual chart like it stemmed from there and then you created a library to like get close to that like bridging that gap. Do you think like thinking of a app visually or like a visual representation, do you think it'll ever become mainstream or do you think it'll be just sort of I don't know what's your position on kind of like the visual representation of an app?

So, will it ever become mainstream? I would say yes and no. I've been so, I founded this startup called stately.ai AI and one of the biggest realizations we made is that if something is inherently complex, it almost doesn't matter if it's purely in text or in a visual form. Complex is complex. It's still going to be a big mess. You're just, you know, visualizing it a little bit differently. So at the same time there's a lot of visual tools now for you know just a lot of AI companies are allowing you to just create these flows visually. You also have things like Zapier make etc for doing complex workflows. But yeah I think that there is a middle ground because we're also seeing right now that text is still king. the fact that you could just have a nice linear text flow. And if you could get close to that, that's actually something that resonates more naturally with people. So I think you need both. And I think that you could express complexity in both of those things equally.

Got it. So people prefer text, but like maybe expanding it out into like a visual format might like help you kind of like think in different ways or like see I don't know some insights. I don't know. I've never done any like visual programming like that. So yeah, it's a dilemma because text is great when things are naturally sequential, but once things aren't sequential, text sort of gets in the way. I'm sure you've worked on logic words like, okay, this function calls another one in this file, but then that one might trigger something in this other file, and then I have to scroll up to see what that one refers to, etc. So, it's not a linear, it's not like reading a book. When you're working in code, you're having to just jump all over the place. And so that's what I mean by, you know, sometimes the visual aspect of seeing like, okay, here's all of the boxes and arrows and we could just follow the arrows. Sometimes it goes here, sometimes it goes somewhere else. That can help sometimes visualize the complexity. Yeah, it makes sense.

And would you say there's like a particular type of application that you've seen that like XState has really solved you know or paid off big time like compared to other like state management. The most common one is multi-step flows. So anything that requires you know multiple steps where the steps can branch the steps can loop you have steps within steps or even in the back end where you have something that has to do a bunch of things in processing and you have a lot of splits where it's like if this happens then do this otherwise do that and go through a completely different flow and also highly interactive applications such as drawing apps modeling apps where it's not just fetching data, but you're actually doing something like CAD where you're designing things in 3D and things like that.

Play from 0:00

So, anything that has multiple states basically. Yeah. And I like when you're talking about that, I think about games immediately because game that sounds like every game, you know, has those kind of like flows and I think state machines are more popular in game development. Would you say that? Absolutely. Yeah. In fact if you look at some of the material for learning about state machines if you went off on your own searched Google there is there is a lot of material on state machines used in games and they use different aspects of for example the character is jumping the character is crouching etc as an intro to learning about how to use state machines for games and yeah so game developers state machines are their bread and butter they use them absolutely everywhere.

Makes sense cuz like if certain types of enemies are in the room or like different scenarios like you that would be super hard to model with like if statements just everywhere in your code compared to like yeah. having actual you know state transitions between when things change I think. Yeah. Right. Exactly. Because with state machines you only need to care about the previous state. So with if you don't have a state machine, you have an implicit state machine. So it's not like you never have a state machine, but I'll give you an example. In a game, let's say that you could crouch or you could jump, but and maybe those are two different key combinations, but you want to prevent an impossible state of when you jump, you're crouching in the because you can't crouch in the air. That doesn't make any sense. So when you jump in like regular Nintendo where games are just kind of like you're like jump crouch like Castlevania anyways but yeah this is a problem that yeah exactly you don't want to be in that impossible state.

So with finite state machines, you can say I'm in a jumping state. So I'm in the air and that's a state and only a finite number of actions are possible in that state. Like I could maybe double jump. I could you know maybe attack midair or I could just wait and land. And otherwise if you don't have that state machine concept then you basically have to guard in every possible condition like oh if not jumping or whatever then I can crouch or something like that. So you have to write more defensively and so that's where we get all of these huge conditional messes with lots of if statements and that's that's a telltale sign of I should have used a state machine. Makes sense. I like that. So where did you like what's your background like?

Play from 8:00

Where did you go to college and where did you kind of like decide to become a developer? I went to UCF and again I went there for piano. I did take a couple of computer science classes just because I used to do a little bit of web developments you know back when it was called web master. Yeah. You know just you know monitoring PHP forums and silly things like that. We might have been on the same PHPB like web master web master forums like that's where I learned exactly and so I had a little bit of interest in programming took some computer science classes and I actually really enjoyed that. We had to do them in C so I had to learn pointers and things like that too. And then I eventually just dove into PHP and then jQuery and then JavaScript. So that's pretty much where I got my start. And how did you land your first like job, programming job? I remember fighting really hard to be a web developer for the student union at UCF and I didn't get the job. I even I remember I tried to just tell them, hey, you have a lot of like cross-ite scripting vulnerabilities here and just try to impress them with like here's everything wrong with your website right now.

And that is not the way to go. So there was another job opening at the college of sciences for some PHP work and that one I was able to land and it's really convenience too. I could just go in between classes and work there and it was nice just working on WordPress sites and I feel like a lot of developers at least you know who have been in the field for 10 to 20 years got their start doing WordPress so that's what I did too. Yeah. Yeah. That's a great kind of path to start in building full websites and all that kind of stuff. Not a low barrier to entry, I guess. A little bit. Yes. Yeah. And then like how did you get your first like you said big job or like actual job? Yeah. Big boy job. My the person who hired me who he's a good friend. He he left to work for this company soon after I got hired at the university and then probably shortly after I graduated he said hey do you just want to come work here like we could get you an interview get you a job so that's what I did.

Cool. So you became like a student developer and then and yeah it led to your first job. So I guess what would your advice be for like kind of those early stages of you know getting into the industry and kind of like those first years of being a programmer. I feel like in some ways a lot has changed but in other ways you know things have stayed the same where networking is so important like you're you're much more likely to get a job if you know someone or people know you especially at the company that you want to work for and I think that advice still holds true today because otherwise you are a faceless name on a resume that people have to now second guess like was this generated by chat GP PPT, right?

Yeah. Yeah. So, I would say networking, going to meetups, and actually being passionate about whatever you're interested in. And honestly, it doesn't matter as long as you could show that you're passionate in something. For me, I was passionate about CSS animations, which is something that rarely comes up on the job. It is like a small fraction if you're lucky to do it at all. So, yeah, that was my passion that got me some more jobs after that. I was writing articles and making open source projects and I feel like that is really key just standing out and not just being a good developer at wherever you're working but going above and beyond doing what you're passionate at. Yeah. And on that note, like how did you land a job at Microsoft? Microsoft. So speaking of networking and all that, I was this was still the early days for XState. So I wasn't really known for, you know, doing that.

But I had a couple of other open- source projects. One of them being a form library in Redux, which yeah, that was an interesting library, interesting time. But they saw that they needed someone with Redux experience. They saw that I was, you know, giving a couple talks at conferences, I was online, etc. And so they flew me out for an interview or at least a month after we talked. was a typical Microsoft lead code style interview. So I was pulling all-nighters just studying and getting as many problems under my belt as I can. That was fun. But yeah, so lots of algorithm questions and that's how I got my first job at Microsoft. Nice. And somewhere in there you so you mentioned like getting known for like CSS animations. I think you made like a YouTube channel called key Framers or something around that time. Can you talk to us about that a little bit?

The key framers was really fun. We we took a break for a year or so. And basically our challenge was we were looking at really cool UI based animations in dribble or whatever other sources we could find, but dribble was the main one. And these were all like proofs of concepts, but we challenged ourselves like can we on air live in front of our audience actually build this out or get as far as we can. And for most of them we did and so we just kept challenging ourselves and doing crazier and crazier things starting from CSS animations and working towards audio visualizations and really cool things like that. So that was really fun and a nice creative outlet and it actually led to just us really improving our skills with CSS. Yeah, it's like the like putting yourself out there with open source doing something like that live on Twitch or whatever.

You get like so much feedback from the community. You get practice like coding in front of others, talking about the things you do. I just feel like it's a it's a huge way to like build your skills. Absolutely. And then eventually you kind of struck out on your own and I think you got funding like in association with XState, right? And you went and built this Stately. Can you talk about that a little bit and like what you've learned so far with that venture? Yeah, so during the pandemic I decided to start my own startup stately.ai. There was a lot of interest in XState at the time. just there was a lot of companies using it probably still today and the I guess the challenge was hey this is a popular open source project can you make it something that is actually a viable business which it's not usually the direct path for open source projects like it's sort of a ven diagram there's open source projects that are popular but not really monetizable but XState you know might have had like some sort of chance of doing that.

Play from 11:00

So, I built with my team a visual modeling tool. So, we really leaned into the visual side of state machines, making it easy for people to create and collaborate on state machines and statecharts for their app logic, version them, annotate them, share them, export them to code, or go the other way around where you might have XState code and you want to import that as a state machine. So we did a lot of work on that and a lot of companies use it. So still going on. That's awesome. Like do you can you think of like one or two big lessons you've learned from like going down that path and like learning or like yeah. What what have you learned through yeah. So, as a first-time founder, one of my biggest lessons is just because you are a solid developer does not mean you can do the CEO and everything else that's required. It's an entirely different skill set.

Talking to customers, doing all of the business things. Just everything that's involved with running a business, you realize that the tech part actually becomes a small part of it. It is about the network, you know, talking to your users, etc. and prioritizing features and yeah there's a lot. So there's that and then the second realization was where visual code can get messy and so we thought that oh hey we have all this complicated app logic let's visualize it for you and boom now everyone can understand that. That was sort of our assumption and that didn't really play out at least not yet because it still remains mainly a tool for developers just because the diagrams themselves became complex.

Play from 18:00

The difference though is that the problem domain itself is complex. So this is inherent complexity versus accidental complexity. The inherent complexity really led to, okay, you have lots of box and arrows and the arrows are pointing everywhere and it's still a little bit messy and hard to understand, but the code is probably five times harder to understand. Sure. So, one of our learnings was just that you can't just make things visual and expect everyone to be able to understand it. Makes sense. Makes a lot of sense. And then how did you get into kind of speaking and teaching? you kind of mentioned that you went and spoke at conferences and that kind of thing and that got you a job at Microsoft. Like how did you get into that? Yeah. So I actually started at meetups. I was just talking about what I was passionate about. At the time it was Angular back when you know Angular 1.0 talking about services and models and things like that.

And then I went to CSS because I was also passionate about that. But I just tried to talk at as many meetups as I could. And then eventually I applied for conferences, got into one, and this was back in 2015. And then ever since I've just been applying and going to more and more conferences, basically talking about what I was passionate about. At first it was CSS animations and then it was observables with RxJS and CSS variables. And then I talked a lot about state machines, of course, for a long time. And more recently, I've been talking about just React's pitfalls with useEffects, use dates, things that developers tend to run into with applications at scale. Yeah. And clearly that stuff has resonated deeply cuz I saw that your goodbye useEffect talk got like 500,000 plus views. So if anybody watching or listening to this hasn't seen that, go check it out.

And then yeah like any advice for I don't know people who would want to you know kind of go down that path and speak and teach. I would say number one, just like I mentioned earlier, find something that you're really passionate about and don't try to shoehorn yourself into, oh, this is the hot topic right now, like whatever it is, MCP or AI or, you know, whatever people are into nowadays, but just that niche thing that really, really interests you and really speaks to you. and just try to talk about it at meetups or even if you don't have that outlet, write articles, make open source projects, even make YouTube videos, things like that. And yeah, just really share it with the world because that's going to make you stand out, you know, from a lot of developers. It's going to get a lot of people talking to you, open a lot of conversations, and eventually that will make it a lot easier for you to go into conferences and just talk about these things in front of a larger audience. Yeah. And you've taught now front of masters workshops.

You've taught quite a few of them like and you obviously continue speaking. you spoke at React Miami and the local JavaScript MN user group you're speaking at tonight. Like why do you continue to teach? It's passion. I'm very passionate about this subject state management in general and I just want to at the end of the day I want developers to make more maintainable applications without ripping their hair out. I want them to be able to easily add features and work with their team and prevent antiatterns and just have a better time coding and you know just make their applications a lot better for users. So I'm I'm just trying to you know make development easier in a way. That's awesome. And do you have anything on your horizon, either career or personal, that you're really excited about right now? Not at the moment. No, I know that's a very boring answer, but it's just I think you're talking about I don't know if you want to share, but you're talking about like maybe taking a sbatical because you've been yeah.

You've been like working really hard for a really long time. I mean, it does sound nice. I've you know I've read stories about just the benefits of doing a sbatical, taking a break at least like just some sort of mental break because I realized that I've been at this for 15 years non-stop. So you know and the there's there's a concept of burnouts and burnout is a very real thing and it's also something that developers love to just deny. It's like, no, I'm absolutely not burnt out. But it's it's still very hard to tell because a lot of developers, especially the ones who are passionate, they will just keep grinding and grinding and just trying to push through the burnouts and then just be left with no energy at the end of the day. So, I think it's really important to address that. Absolutely. Like I've I've hit a couple points in my career where it's like I didn't realize it and then it's just like holy crap I don't have any motivation. like I am very tired and it's just like okay like throw myself into physical hobbies or other hobbies for a little bit and it's like all of a sudden the ideas start coming back the flood of like motivation and you know it's like I think we've all hit points in that career in our career where you know like I just want to code this open source project I just want to go talk about this I want to go teach this I want to you know it's just like all the new ideas are like flooding through and then other yeah. and then you reach a point where you're like the ideas aren't coming quite as much right now.

Play from 20:00

Like I think I just need to like take a step back and take care of myself. And I think that's I know a number of very talented high level developers that like have taken yeah periods of time off and they come back stronger than ever. So yeah, definitely that sounds like a great idea. Do you have any themes when you look back at your career that kind of like tie it together? Like, you know, thinking about the successes you've had and whatnot. I would say just, and this sounds, you know, cliche, but thinking outside the box, basically thinking about what's possible. So, back when I was talking about CSS and doing all of those experiments, I was actually not very good at JavaScript. I just tried to focus on CSS and I was actually a little bit anti-JavaScript at the time. And so, that led me to looking at things on dribble and being like, wow, that's a really cool interaction. Let's see if I could do this in almost 100% CSS. And in fact, a lot of the things we do on key framers are just mostly if not completely CSS only or CSS and HTML.

Yeah, I've seen some of like I think is code pens, right? Like like some of those code pens I'm just like how is how did you build that with CSS? This is incredible. Yeah, very impractically. That's the answer. But yeah, thinking outside the box. And then when I started talking about reactive animations with CSS variables, that's when I started to again think outside the box, not use JavaScript for animations, but only use it to trigger CSS variable changes. And then when I was thinking about state machines, that was also thinking outside the box of this complicated app logic. Can we actually visualize it? Can we copy paste the code somewhere and then make it visual? And then even the most recent React talks I've given on useEffect and useState that's also thinking outside the box because to any React developer they're like those are very basic hooks. These are hooks that I'm going to use absolutely everywhere.

They power my application. They're at its core and here's David coming to say like hey you're using them a bit too much. And actually the more you use them the more it becomes an antiattern. So that's me thinking like there must be a better way and you know realizing that those cause a lot of you just it makes applications harder to maintain and they cause bugs and things like that. Cool. Well, I think that's a great place to wrap. Thanks for coming on the podcast, David. Thank you so much for having me.

Play from 26:00