EPISODE 1643

[INTRODUCTION]

[00:00:01] ANNOUNCER: Stately is a web-based drag-and-drop editor for collaboratively developing code diagrams and documentation. Laura Kalbag is the Developer Advocate at Stately and she joins the show today to talk about Stately, state machines, building good documentation and more. 

This episode is hosted by Josh Goldberg, an independent, full-time open-source developer. Josh works on projects in the TypeScript ecosystem. Most notably, TypeScript ESLint, the tooling that enables ESLint and prettier to run on TypeScript code. Josh is also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies and a live code streamer on Twitch. Find Josh on Bluesky, Mastodon, Twitter, Twitch, YouTube and dot-com as Joshua K. Goldberg. 

[INTERVIEW]

[00:01:01] JG: All right. With me today is Laura from Stately. Laura, welcome to Software Engineering Daily. How's it going? 

[00:01:07] LK: It's going well. Thank you very much for having me, Josh. 

[00:01:10] JG: It is my pleasure. Could you give the audience a brief introduction? Who are you? 

[00:01:15] LK: My name is Laura Kalbag. I'm a British person in case you couldn't tell by the accent. And I call myself a designer, I suppose. I'm a designer who also writes code. I guess you could call me a designer and a developer. I also do a bit of writing and a bit of speaking. I've been working in tech for about 15 years at this point. And right now, I work for Stately. I do advocacy and education for Stately. And I also have a not-for-profit organization called Small Technology Foundation that I run with my partner.

[00:01:48] JG: Well, that is an excellent overview of the stuff I would like to cover today. 15 years ago, you got into tech. Why and how did that happen? 

[00:01:56] LK: It started out because I really loved the web. And bearing in mind that the web wasn't something that was available to me when I was a child and really was becoming available to people in the mainstream. I think we had a home internet connection when I was about 13 years old. And I love the idea that, on the web, you could learn anything you wanted and the only cost of it was an internet connection, which, granted, for a lot of people can be quite expensive. But once you had that, you had access to so many things. And I love kind of equity of information. I thought it was really cool. 

And so, I started making little websites. Although, I was using – and I built my own forum just using one of these services that allows you to set up your own forum. Nothing code or related to that. And I was studying design. And so, as I went to art school, I sort of designed a load of websites and got them sort of uploaded, working okay. But I actually wanted to learn how to build them properly and how to actually make this stuff work. I wanted to make pretty pictures of websites but I wanted to make real working interactive things. 

And so, when I was studying, I decided I have a lot of free time when I wasn't working. I think it's the most amount of free time you ever have when you're studying. And so, I taught myself how to do web dev while I was doing that. And mostly very front of the front end at that point. But I learned how to do HTML and CSS pretty good. And that was back in the day where we were just getting past tables, front end and moving into complicated float layouts and things like that. But I taught myself how. And so, as soon as I graduated, I was like, "Oh, I want to work for myself and make websites for other people." And that's how I started out.

[00:03:48] JG: I remember on freewebs.com, that was my intro to making websites. These ridiculous table-based layouts where the entire page would be a table and then you have something floating in there. It felt a little Wild Westy on the web because just the CSS rules you would follow were so weirdly defined compared to the stuff we have today. 

[00:04:06] LK: Oh, yeah. I think one of my early experiences with CSS was modifying my MySpace profile. Because if you entered CSS into the text input boxes, it would actually render. And so, you could use that to hack your profile in a lot of different ways. And so, that's how I started learning all of the different properties, was, "Oh, I want to make MySpace profile different color or add some images and things like that." It was very hacky. But I think it was a lot of people's way in.

[00:04:35] JG: Yeah. I hear that a lot. It was the Myspace. It was the fun forums online. How did you go from learning HTML, CSS to where you are today in Stately though? Was it a direct line? What's happening there? 

[00:04:49] LK: For a long time, I was just a freelance person who made websites for other people. And so, I'd work with a lot of small businesses and increasingly larger businesses. Just helping them sort out there – just a one-stop shop for websites is what I was doing. 

I was doing WordPress development as well. And I used to build a lot of sites using WordPress back in the day. And eventually, I started being taken on as a consultant for more specialized areas. I specialize a lot in accessibility because it's something I've always cared about and taken an interest in learning as much as I can about it. And also, responsive design and design systems. 

I was pretty early on the bandwagon for those things and very much hand-in-hand. I was actually designing mobile websites before responsive design was a thing before. Really, just as smartphones were coming out was when I was starting out in mobile design. And I was very lucky to be working with folks who were working for mobile networks at the time. So, they understood the importance of having a web presence that worked on mobile. And so, that was quite fun to be able to see what we could do and get rendering on mobile phones even if they weren't the smartest of smartphones. 

And so, I ended up doing quite a lot of work in responsive design and consultancy around that at the time. And for me, then, that's when design systems started to make a lot of sense. Because you were trying to think about how a design might work across lots of different viewport sizes. And it made sense to be able to reinterpret a design in a way that worked on those different platforms rather than creating lots of different fixed-width designs. And so, that's how I got into that. 

And how did I get from there to there? Well, it was probably about 2013, 2014, my partner, Aral Balkan, and I set up Indie, which was the sort of initial version of Small Technology Foundation. Basically, when the Edward Snowden revelations came out, we were like, "Now this isn't on." The idea that all of these massive corporations were collecting so much data about people. And we were like, "We need to think about ways in which technology could do better. Ways in which we could create business models that aren't based around collecting people's data and exploiting it." 

And so, we thought, "We'll try and set something up to look into, I guess, research and development." Into how do you architect a web that is built around respecting people's human rights. Respecting their privacy in a way that's also accessible. In a way that is also available to people in the mainstream. And so, we've been working on that for a very long time. And so, I've done a lot of work on sort of web presences around that and different web technologies for that as well. 

And then during COVID, I was like, "Well, running a not-for-profit isn't making very much money." And I need to try to do something to support what we're doing at Small Technology Foundation. But also, I don't want to work for a big evil corporation. I would like to see if I can to work for people that really care about what they're doing and have some principles behind it. 

And so, I poked my little head out in a couple of groups that I belonged to and said, "Hey, does anyone want a person like me? I love free and open. I really believe in that. I care about accessibility and privacy. I can do design and dev. And I can write some stuff and give talks and things if that's helpful. Who wants me?" And I was very lucky that David Khourshid, who is the creator of XState and the founder of Stately was like, "Oh, hey. I think I've got a job that will work for you." And that's two and a half years ago now. Really, he was the first time that I was properly employed by another person inside of the tech industry. That's been quite an exciting change for me.

[00:08:46] JG: Stately is a pretty small team.

[00:08:48] LK: We're only nine people. Yeah. 

[00:08:50] JG: That's wild to me. But that's really kind of the epitome of within the tech industry, the opposite of giant corporations, right? As a small team, you have a lot more say in what's happening and you're able to exert that influence more. 

[00:09:02] LK: Well, I think I was number four in Stately as well. And to be fair, the previous three were involved for a lot longer. And they were involved in XState a long time before Stately was a thing as well. I really came in right at the very beginning. 

And, yeah, the idea that you do have a say but also that you get to work really closely with each other. And that's one of the things that's so nice about the Stately team, is that it's mostly engineers. And it means you get to learn something from someone who has a different specialist area from you. And I've learned so much from that team. Everyone is really smart but also very generous with their time. And we work a lot together on sort of helping each other understand our different areas and trying to make Stately as good as we can. 

[00:09:50] JG: Just to disambiguate XState is the open-source project that later on Stately was a company founded around?

[00:09:56] LK: Yes. And I should probably mention that XSate is a JavaScript library for state machines on the web. And Stately is, I suppose, state machines as a service. The idea is that you can visualize your application logic. And you don't even really have to use it with XState. You can visualize it anywhere you like. You can build any kind of logic flows with it. But you can also use it with XState and use it to orchestrate all of your state inside of your apps if you so wish. 

[00:10:27] JG: Before we dive into that, because that is a juicy topic, you were into or working with accessibility before the large recent boom in the last few years of accessibility interest in the industry. You were working in responsive design before CSS Flex. You were working on a not-for-profit around privacy before the recent surge in Twitter alternatives such as Bluesky and Mastodon. Have you notice that you keep doing these things before the rest of the industry catches on? What is it about your thought process of what to work on next that we should all be emulating enthusiastically? 

[00:11:01] LK: Wow. No one has ever put it like that. That really makes me sound like I'm a far more advanced person than I believe I am. It would be wrong to say that I was the first in any of these areas. I'm for sure following along with what I thought was the tide. And maybe I just followed some very interesting people and were listening to the right people at the right time on a lot of these topics. 

I think, to be honest, the thing that drives me in tech is not the new shiny. And that's really what sort of pulls me into things is what I care about, is building things that respect people's rights. A lot of the areas that I've been in it's because it's something that I care about from a principled perspective. 

But also, as someone who started out in designed and got into development, I am really interested in how we can work better together. Because it is my eternal frustration that designers and engineers don't work very well together. And that we kind of – designers can treat engineers like code monkeys and engineers can treat designers as if they're painting pictures of websites. And really, we're all much better than that. And we could do a lot better and much more interesting work if we get to collaborate and learn a lot more about what each other are doing. 

[00:12:23] JG: I want to run something by you. I've worked on several teams with several people who, similar to you, had an art school background. And they had a lot of context on let's say design, the history of artistic movements and so on. Things that I did not pick up in my computer science major that are not typically taught in CS majors, or boot camps, or similar. 

And I found that, because these folks have had such a deep understanding of the art or design side of things, there's a lot that they can bring to the table in these discussions around web design, accessibility, responsive layouts and so on. Have you found that there's a lot that you're still pulling in from your art background into the design and code work you're doing today? 

[00:13:06] LK: One of the things that I think we get most from going to art school, and it's not actually at all anything about the history, or knowing about movements, or even any design rules and things like that. It's actually about being able to view and criticize each other's work. And also, from that, you learn how to justify your own work. 

On the negative side, that can make you a really good bullshitter. You can justify anything. And even if you don't really think your work is that good, you can work out putting how to put a spin on it that makes it sound like it is artistically justified. That's the negative side. 

But on the positive side, what you learn to do is really examine what other people are producing. Try to understand the assumptions and the intent behind it. And also, better understand your own intent and perhaps the assumptions you've made and explain, "Look, this isn't just a blue link. This is why I chose a blue link. I chose a blue link because it is a convention that is used across the web that is identifiable to many people. I chose it because it fits with our brand colors. I chose it –" you find these ways of being able to communicate your work. And I think that that's actually probably the most useful thing that going to art school taught me. 

And really, less of it was about history and rules than I actually anticipated. I really wanted to be told, "Hey, this is how you use spacing. This is how you use typography. These are the rules that will always work." And a lot of it's actually more self-directed. You try it out and see what works for yourself and learn for yourself how to do it. 

[00:14:45] JG: One of the difficult things about the web, too, is that it's constantly evolving. Even if you were to have a set of this is how you do it, this is how you don't, that might not be applicable in 5 years or across a different set of screen sizes and types. 

[00:14:57] LK: Which is exactly how learning computer science and going to art school equally as useful or not useful for working in tech. 

[00:15:06] JG: You can learn the primitives, the foundations and the ways of thinking things. But you're going to have to always apply them in new and creative ways in the industry, right? 

[00:15:13] LK: Yeah. And I think that's the benefit of experience in tech is actually being able to learn from the good things you've done and the mistakes you've made. You get a better way of understanding how you might waste your time by diving too far into something that's not really a solution and getting an overview of, "Oh, this is how these trends seem to go. Oh, maybe I won't jump on this bandwagon this one time." 

[00:15:39] JG: I want to iteratively go through your history as you've got a lot of interesting stuff there. You mentioned accessibility. You wrote a book about accessibility called Accessibility For Everyone. It has a beautiful green cover. Can you tell us a little bit about that process? What was it like to write a book? 

[00:15:53] LK: Yeah. I wrote a book with a book apart. And so, I am probably one of the luckiest, most spoiled authors ever. Because they are an absolutely wonderful tiny independent publishing company. They specialize in books for people who make websites. And their books are reasonably short. But mine is on the longest side but it was on a way longer side before an editor got to it. And they are easy to read. They are not dry. They're usually written with their author's voice to some degree or other. 

I mean, it is in American English. Of course, I write in British English. So, I did have to get used to that. But they didn't make me do that. They did it for me. But they have a really wonderful editorial process. So, you can be sure that a book apart book is a mark of quality because it really has been properly – they've had tech edits and proper edits for English and everything. I would highly recommend them. 

And they approached me because I'd written a few blog post articles about accessibility. And they were looking for – they wanted an accessibility book for their lineup. And I never really thought I'd write a book. But I was really excited to give it a go and see what I could do. 

And I'm really glad I wrote a book about accessibility as well. Not just because it's really important to me. But also, it's lasted a long time. A lot of tech books will go out of date very quickly. But accessibility is a fairly slow-moving field. And so, a lot of the advice particularly because a lot of it's focused around writing semantic HTML and experience design and writing good content, those things don't go out of date so quickly.

[00:17:33] JG: Suppose I'm a new developer to HTML and I have no idea what anything you just said meant, what is semantic HTML? And how does that relate to accessibility? 

[00:17:43] LK: In HTML, you can use pretty much a lot of what you would build in your apps. The way that you would render it on the page is using a div, which is just a little dividing element. A way of breaking elements up on your page. You might use some spans as well if they're in line. But you'd use divs for your block-level elements. And these are great but they don't actually tell you very much about any additional information about how that thing is rendered. 

A lot of people use assistive technology to access the web. And the most classic example of this that most people have heard of are screen readers. And what screen readers do is they read the content of the web to you, especially if you can't see it. Not always. A lot of people who use screen readers can see what is being read to them. But a lot of them can't. 

For example, screen readers can be very useful to blind people. And so, if you use an HTML element that's not a div or a span that has some more meaning attached to it, that way, the assisted technology can pick up on that meaning and explain that meaning to the person who is trying to access the page. 

For example, classic example of this is a button. You could make a button element using a div. You could also make a button element using the HTML button element. And that tells a person, when they go to use this button, "Oh, it's a button." And there are loads of other benefits to using the button element as well because it comes with a huge amount of behavior that's built into to the browser where it understands that it can be disabled and it will render it appropriately. It can understand that it can be clicked. That you can fire different events off of it. And so, you get a lot of bonus things through the browser from using that button element. That is the difference between semantics. 

You can also do things headings, paragraph text. The simple humble link. The benefit – the basis of the web. All of these things are providing more meaning to your markup and making it easier for it to be interpreted by other forms of technology that aren't just visual. 

[00:19:54] JG: What is the number one most common mistake or at least the first that comes to mind for people writing markup when it comes to doing it properly with semantics that you've seen? 

[00:20:07] LK: Are you using divs for everything is a bit – they call it divitis if you use divs for everything. I also think one that is often lost to people who work a lot on apps is the benefit of using good headings. And so, a lot of the time, you want your text to be bigger and bolder when someone looks at it on the screen. And so, you might give it a big size font and you might give it bold, like font-weight bold. 

If you actually give it an H1 heading if it's the first one on a page and then use hierarchy so that you can use an H2 heading for something that follows an H1. And if it follows an H2, you'll use an H3. And these not only give people landmarks on your page if they're using assisted technology. But it's also a huge benefit to search engine optimization and things like that because it's telling your search engine, "Oh, this element is high-value compared to the other text on the page. It's a heading." This is something you want to pay attention to. This is what the content is all about. 

And you could also use headings inside of apps. I think a lot of people think about headings in terms of documents. But I think it's also valuable. If you've got different panels and things like that, you can use headings in there to tell people what the high-priority information on the page is. 

[00:21:21] JG: We've talked about semantic HTML. And you've also worked with responsive design. There's a trend in web dev, especially these days, the last half-decade or so, of folks embracing standards in the web and embracing using the web's native APIs for stuff such as responsive layouts and styling. Do you think that there's a strong correlation between sites that do accessibility well and sites that do responsive design well? Or at least in the tooling that makes those sites? 

[00:21:47] LK: Oh, I absolutely do. Although I would challenge you on the idea that folks have been more into web standards over the last five years. I think it really depends on the areas that you move in. Because, for some folks, it has always been a challenge. And they have not really known much about web standards. But when I started out, I learned from people who were already into web standards. And that was a long time ago. I think it can really depend. 

But, yeah, I think a lot of the idea of giving up absolute control over how something is displayed benefits both accessibility and responsive design. If you are letting the browser do what it does best, choosing how to render things depending on all the different factors that the user is throwing at it, their viewport size, whether they're using light mode or dark mode, whether they're zoomed in or out. If you try to give as much of that control up to the browser, telling the browser how to interpret your design based on those things rather than trying to absolutely control the intersection of all of those different perspectives, then you're going to have a lot easier time of it as well. 

It's actually better for efficiency, too, if you're trying to work with what the web does well rather than overly control it. And I think there are a lot of other folks who talk about this a lot better. One person who comes to mind is the event that we were at last week, Josh, where – Jeremy Keith, who I learned a huge amount from as I was just starting out even. And he was talking – I guess he's calling it declarative design. Jen Simmons calls it intrinsic design. And Andy Bell's been writing about it a lot about not being the browser's micromanager. Yeah, I think those folks. They word it all better than I do. But I agree with them.

[00:23:36] JG: One of my favorite parts of your book was in chapter 4. You talk a lot about using the web's standard conventions in ways that people typically already do. Earlier you mentioned having an underlined link blue or purple being the common standard. You mentioned the concept of affordances and conventions. Could you define the difference between those two things and how they're relevant for accessibility here? 

[00:24:01] LK: Yeah. Conventions are the rules whether they're spoken or unspoken, explicit or implicit that we already use across the web. And so, it becomes how folks understand that the web works. I think a good example of this is what we might call the hamburger menu. Those three lines. The icon that we use that signifies some kind of menu somewhere. Now, I personally would prefer it if it did have the word menu alongside it. I think that would be more useful. But that is besides the point. The idea is that that is used in so many places now that we can kind of say that's a convention. And if you choose to use that in your design, generally, the user will understand how to use it. 

The difference with affordances is I guess an affordance can be a convention. But an affordance doesn't necessarily have to be a convention. And an affordance is something that tells you how something is used in its design. And so, I guess a link is an example of that because it has an underline and we know the convention of underlines is, "Oh, that means it's something that's clickable." 

If you have text that you've underlined and isn't a link, that's going to really confuse your users. And so, you can probably create your own affordances if you can come up with some smart, new way of explaining how something works through how it looks. 

I'm thinking of when skeuomorphism morphism became very popular and we decided to design everything so that it looked like a physical item. Your buttons were all rounded and had shadows. And when you hovered over them, they indented. Looking like you'd press them in. You can do that kind of thing. 

But a lot of the time, going with the existing conventions, as much as it makes you feel like, "Oh, I'm just copying everyone else." There's a reason why we do it. And I think good design is not necessarily about doing something that is completely new. It's about using what exists in the most effective way possible.

[00:25:55] JG: That statement applied both to visual design and software development. 

[00:25:58] LK: 100%. 

[00:26:01] JG: State machines are a good way to describe how your application state exists and flows between different areas. But could you describe to us what actually is a state machine, especially in the context of software development? 

[00:26:13] LK: And state machines can be a really useful way to model how your overall application logic is supposed to go. You can visualize absolutely everything that connects together all your microservices. Every little bit of your app. But it's also very useful for managing the state on much smaller component level. 

One of the examples I give all the time is just an audio player. You can use it to manage the playing state and the pause state. And you can say, "Hey, when there is an event fired off that says play, go from that pause state to the playing state. And if there is an event fired off that says pause, go from that pause state back to the playing state." And that's one of the simple demos that I've made that just works really nicely with the web audio API. Even though the web audio API, yeah, it doesn't deal with stop and start. That's why I have to use play and pause. Because pausing is not the same as stopping.

[00:27:11] JG: That's the type of delineation that you'll get from someone who works with web APIs standards and also with state machines. That there is a severe difference between pausing and stopping that most people probably do not get impacted by on a day-to-day basis. 

[00:27:25] LK: Yeah. Just something that gets stuck in my brain because it frustrates me. Yeah. 

[00:27:30] JG: What is the difference between play/pause and stop/start? 

[00:27:36] LK: There's not actually the concept of stop in the web audio API to my knowledge. It is always just pause. Because if you're thinking in terms of audio players we have maybe in our day-to-day lives, for some reason, I started thinking cassettes and then realized that is not going to translate to a vast majority of your audience. 

But, yeah, if you think of a CD player. Hopefully, there are still people that used CD players. And this would even maybe work for music apps. But, yeah, the idea is that pausing would stop in the middle of a track. Whereas stopping would go to the end of the track or would stop the track completely. If you press play after pressing stop, it would start the track from the very beginning. And that would be what I would consider the difference between stopping and pausing. But, of course, you don't really have that concept on the web. It's not necessary you're always just pausing. And you can start the track again in a completely different way if you wanted to. 

[00:28:35] JG: For software though, there are always going to be little shared assumptions and affordances in how an app works. Is it possible to document all those things in, say, a state machine? Is there ever an excess that has to be done in AppLogic or outside of the state machine? 

[00:28:50] LK: I think it really depends on how you want to use it. I think that it is really useful to actually have that logic modeled in one location. Because, often, the alternative is that your app logic is actually implied and you don't actually have it explicitly controlled anywhere. You might just have a variety of conditionals throughout your app that decide where state happens or when you transition from one state to another. And there's not really a central location where you look at it. 

And again, I'm not saying that you need to use a state machine for one giant state machine to control the whole of your app. But just having a location that may be from a very abstract level controls the state. Maybe you have a lot of smaller state machines that can communicate with each other. That is one of the benefits of using state machines is that you can have much more broken-down logic into much smaller pieces that can communicate with each other and a lot more maintainable. 

And so, at least having it modeled can really benefit you. And it can also help you when you come to the debugging phases and things like that, that you can look at, "Oh, I'm actually missing a state there." Or, "That state is impossible to actually get to. There's no transitions that get me there at any point." Or, "That's an undesirable transition." State machines can help you a lot with that. And so, the benefit when you're collaborating with everyone else is that you're on the same page. And I think that's really the key benefit that you get out of it. 

[00:30:19] JG: Let's say I have an app that's not wired up with any kind of state machine. It's a whole bunch of Booleans or strings in state. And I want to, let's say, take the shared button component and turn it into a state machine. What would be the next set of steps that I might take? 

[00:30:33] LK: Well, for one, you want to get XState in there. XState, great. Anywhere that JavaScript runs. And TypeScript. I have to be specific when Josh is around. And, yeah, you can just start building a state machine into a tiny component like that. You don't have to completely rip up everything that you've got already and reimplement it with state machines. I don't think that was ever good advice for working on any project. If you're having to tear something up and start again, there's something fundamentally wrong. But it's quite easy to start with from a little component basis. And you could build out a little state machine. 

The way in XState that state machines are formatted is just as a kind of a JavaScript object that tells you what the states are and tells you which states you can then transition to. What your source state for a transition and your target state for a transition. But you can also model it very easily using Stately, which is a drag-and-drop way of modeling state machines visually. And that's a much easier way to get into it if you're starting off for the first time, especially if you're a visual person. 

And I say visual person. Not designer. Because I think that a lot of people who write code are also very visual people. And it can be a lot easier to process a lot of information in one screen without having to scroll. That's one of the benefits that I find with visualizing it.

[00:31:58] JG: There's a parallel here, I think, that when you set up a document, let's say, semantically, you're encoding in the structure of the document. These are the ways it's meant to be. These are, let's say, the sections, the headings, and buttons, and links and so on. And then similarly, if you set up the app states or the way that your flow is supposed to work in your app in a way that is semantically representable, such as with a state machine, you can then build a visualization on top of it such as with Stately. 

And I think there's a trend here of, as we better understand how to build our software, we get better at doing things in a predictable, representable manner. It's very exciting to see that there's work being done on representing that stuff visually. But I imagine, it's probably a very difficult design and engineering problem to get it working in the abstract for just any arbitrary user or state machine.

[00:32:46] LK: I absolutely love that you managed to pull that as a thread. Because I've never actually thought about that being the reason why state machines appeal to me. But almost certainly why. Yeah, it is a complete representation. And I think one of the other things that is similar with writing things that are semantic or using the web APIs as much as you can. Making use of what the browser does best. A lot of what that comes down to is actually having a fundamental understanding of how these things work. It's about really understanding the platform that you're working with and understanding your medium if we're going to compare it to working in design and art, which allows you to do a lot more powerful and complex things while simultaneously not having to do as much work, which is something I always appreciate. 

[00:33:37] JG: There's got to be a good phrase for this. Developers are lazy. But lazy has a negative connotation. It's that we're efficient. It's that we are optimized. Something like that.

[00:33:47] LK: Yeah. There's definitely a word out there. And, yeah, it's about being lazy in the right way. About knowing where you can cut the corners or being more efficient is not really cutting corners if you're making things incredibly semantic. But a lot of the time it also comes as a kind of a trade-off between you have to actually learn how the thing works in order to be able to use its power. And that can be tricky. Because sometimes it can be really tempting to go with a library or a framework that adds a level of abstraction on top of what you're doing, which takes you a little bit further away from the web platform but may also give you other benefits as well. Understanding what the right balance is there and where your efficiency is best used.

[00:34:32] JG: Do you ever worry building a visual representation on top of your state machines that you're making that exact pitfall that you're taking people away from understanding how it actually works? 

[00:34:41] LK: Fortunately, not with Stately. Because it is built on XState. And so, because the rules around state machines are so strict, the things you're able to do, you're restricted to specific things you can do with a state machine. You're pretty restricted in where your states can go. What your transitions can do that's allowed? 

And because of that strictness, because you're giving it so much clarity, it allows the code that it produces to be very explicit and clear in itself. It's kind of not like a no-code tool in that sense. Because one of the problems with these no-code and low-code tools is you can produce a great-looking website really easily using a drag-and-drop tool. But you are going to miss out on all of the great semantics of writing great HTML. You're going to miss out on a lot of the power of responsiveness because you're not able to describe in enough detail how something should change when it moves across viewports. It can produce really junk code that is completely inaccessible. 

Whereas, because state machines are so strict and because it's built using SCXML, which is a very strict rule set as well, you know that the code that's being produced can be that clear. And also, because it's got some of the smartest engineers I've ever met working on both the XState and the Stately side of it to make sure that what your writing is accurately represented. 

I mean, yes. Sure. We could always make junk state machines that don't work particularly well. But it's in the same way that you could always name stuff really badly in your code too. It's no guarantee you're going to make great things. But it certainly makes it easier to author those things much better.

[00:36:26] JG: Speaking of naming, what is SCXML? 

[00:36:30] LK: That is State Charts XML. And it is web standard. This is how I think about web standards as a person who doesn't tend to read all of the documentation myself because it's very dry. And I like to wait until a very clever person interprets it for me. I'm willing to admit that. But it's people who really have taken an interest in state charts and been able to put it into a standard that can be interpreted by many other people, which has the benefit of making it interoperable. And so, that it can then be used in many different languages and many different applications.

[00:37:05] JG: That's fascinating. One wonders, there's got to be some way to transfer between paradigms. Or if you represent your core app state in this SCXML standard, you could then have the same logic be represented in completely different UIs and, say, a mobile phone, versus a tablet, versus et cetera.

[00:37:22] LK: Yeah. Totally. Although, I mean, you can do that with JavaScript. And so, you don't need to go all the way back down to SCXML. But, yeah. The idea is that, with standards, you're teaching the platform how to interpret these things so that other people can build things on top of it and interpret it in their own way. And that's one of the cool things about web standards.

[00:37:45] JG: One issue that I brought up with the state machines sometimes is that they are intentionally restrictive. You're setting up a very delineated pathway that people are allowed to walk within. If I'm a Wild West kind of developer, I'm annoyed that I can no longer just willy-nilly set my state to do whatever ever I want. What am I doing wrong? Or how am I thinking of state machines wrong so that I'm getting annoyed using them? 

[00:38:09] LK: It's hard to think of how you would want to Wild West your states to the point where you wouldn't be able to represent it using state machines. Because you could still do some pretty wild things with state machines. But I think it's mostly a case of, I think if you're worried about it being too restrictive, it's probably that you've got a problem with your state management to begin with that maybe it's quite fragile. That you've got your stay dependent on a lot of different cases. Maybe you're not actually sure about where the transitions are supposed to go. 

I think it's like with a lot of things. If you've built a very complex thing, when you just keep adding more and more on top of it, it's just become very confusing and complex web and you're too scared to unpick it. I could see that probably being the scenario in which you're like, "Oh, I don't want to try and implement this using a state machine. Because it actually requires me to understand how it's working in the first place." And that may well be your problem.

[00:39:05] JG: Yeah. We have a similar line in the TypeScript land where the introduction of types rubs people the wrong way sometimes at first because they're no longer allowed to just change anything anywhere. But by giving those constraints in, by restricting you, you're more free to experiment, to be validated when you know something's wrong.

[00:39:23] LK: Totally. That probably explains that why, when I got such a great introduction to TypeScript from you, I was like, "Oh, yeah. This makes sense to me. I like it. This is semantics." 

[00:39:34] JG: Yeah. Yeah. TypeScript, it's semantics for your JavaScript logic and type shapes. It all blends together. There's a great Stravinsky quote actually. I had to look it up, "The more constraints one imposes, the more one frees oneself of the chains that shackle the spirit." 

[00:39:49] LK: Oh, that is very nice. Yeah. I mean, this is something that's said about design a lot of the time as well, is that your enemy is the blank canvas. And the second that you actually provide yourself with restrictions, rules, constraints, you can actually be more creative. It constraints the root of creativity or something like that. I'm sure someone very smart said that and I can't remember their name. 

[00:40:10] JG: Someone. Let's switch topics a little bit. We touched briefly that you are the co-founder of the Small Technology Foundation. What is Small Technology and what is your foundation trying to do about it? 

[00:40:22] LK: Small Technology is the opposite of big technology. Big tech is the idea that we have a lot of business in technology that is based around selling people's personal information or exploiting people's personal information for financial benefit. 

A lot of the time, it kind of manifests itself as you want to use a cool bit of software online. You want to use an app, product, and it's free. And why is it free? It's free because your data is what's actually beneficial. Whether people can sell it onto another company, like an insurance company. Whether they can utilize it to provide advertising that might manipulate you into buying products. 

And so, we wanted to look at other ways that you could build technology that doesn't do that that is sustainable from a business perspective. But also – and not just business obviously. But all of these other things that you can do that aren't business. Like, nice, not-for-profit, free and open. Things like that. But also, making sure that the technology that we build is actually designed to prevent that from being able to happen. 

Part of that is building technology in a way that could be completely private so that people can use it. And no matter if you wanted to start a business that went bad and decided to exploit someone's data, we've architected it in a way that they cannot actually do that. Things encryption. Being able to do peer-to-peer. 

And, yeah, trying to build things that are true alternatives to, say, Facebook but in a way that have the same experience as something like Facebook. Being able to log in and sign up without having to have a huge amount of technical knowledge. But underneath it all, it respects your privacy and it respects your human rights as well.

[00:42:09] JG: How do you build that into the technology itself though in a way that the end developer isn't able to violate those ideals? 

[00:42:17] LK: Well, I mean, you always could if you're a developer. You can build something that works in a completely different way. But the idea is to provide developers with tools and frameworks that enable them to build really good stuff really easily, which currently can be quite difficult. 

Right now, it's really easy to start integrating – bringing a lot of centralized services together. Bolting them together. And, "Tada. I have an app." Whether this app is tracking someone in a lot of different ways, it's passing data to all of these different services. How do we architect things where decentralization is a benefit? And if we build tools that enable people to be able to put things together as easily as you can, the rest of the web. But by default, it is doing all the good stuff.

[00:43:04] JG: There's a phrase in developer tooling, "The pit of success." Right? Where you make it easier for people to fall into the right things and harder for them to climb into the bad ones.

[00:43:11] LK: Exactly that. Y eah. And that is a huge amount of what building things for developers is nowadays. It's your well – ironically, we're manipulating developer behavior by trying to build things that encourage them to have good habits. But also, it's for people who care about these things who want to be able to build things that are accessible and build things that are private and want to be able to do so in a way that doesn't use the existing tools on the web that might push them in the wrong direction.

[00:43:39] JG: There are some pretty strong financial incentives though to be evil to sell data. For example, you can get money for data pretty easily if you're a big corporation. How do you compete with that? That financial incentive? 

[00:43:51] LK: Part of it is the difficulty of the model in technology is that a lot of it is backed by investors that want infinite growth or want exponential, really fast growth. And one of the things is that rejecting that to some degree. Thinking about how you want to build technology in a way that is small and sustainable. It might be able to sustain you as a person. It might be able to sustain a small team. You don't necessarily have to sustain hundreds of thousands or millions of users and make huge amounts of profit year-on-year for your massive board and all of your investors. 

I think it is about one of the reasons why a small technology is thinking about it, why does it have to be that big? Why does it have to be there for everyone? You can make it available to everyone but you don't necessarily want everyone to use it. What if we think about technology in terms of we're thinking about social networks? We want to use social networks with interesting people we want to follow. There might be a few people. But also, our friends and our families. And those are actually quite small groups that you want to communicate within. You don't need to be connected to every single person in the world. The people that really benefit from that are the people that like the data of you being connected to everyone in the world.

[00:45:06] JG: Can you describe then what the small web is as an example of one of the small tech initiatives? 

[00:45:12] LK: You, to some degree, have to get my partner, Aral, on to talk more about this in detail. Because he has been the person who has been really working on implementing this. But the small web is the idea that you can deploy and build your own small websites that can communicate with each other very easily whilst that you have control and ownership over all of your data and how it works yourself as an individual person. 

It's a single-tenant web. It's very different from maybe having a service that you start up and you host all your friends on. That's where it varies from things like Mastodon where, say, everyone joins a particular Mastodon server. It's like more like each of us having our own Mastodon server, which I do, by the way, that can communicate with each other.

[00:46:01] JG: Yeah. I had the pleasure of watching a demo of Kitten, which is the web framework used for small web being shown off. And it really blew my mind that a lot of the design decisions around small web kit and so on are made around the assumption that you don't need to scale to big tech levels. Where a lot of frameworks we see these days are architected so that, yeah, you can get started with your little thing. It's good for that. But really, if you need to scale to millions of users and trillions of petabytes of data per microsecond, it'll work for you. But most of the time, that's not actually necessary both from a moral standpoint and also just from a practical logistical standpoint.

[00:46:41] LK: Yeah. Absolutely. And it's quite funny actually how a lot of people might start building and architecting things to begin with as if they're going to scale to millions of users even though they haven't got any uses yet. It's definitely optimizing a little bit early on in that case. But yeah, it's designed that way on purpose in order to discourage people from trying to scale at such a rate. And also, because when you architect things in that way, you can get a lot of other benefits. 

Yeah. The small web is very deliberately architected in that way to try to prevent this need to scale. Because we don't need to scale it. And we're often just optimizing things unnecessarily early by saying, "Oh, I'm going to build this so it can scale to a million users." 

I mean, you even think about how we build things in teams. A lot of the time, we're optimizing things and then we're actually rebuilding it pretty much a lot of the time from near enough scratch every six months or so. And a lot of the time, we need to think about what we're optimizing for and when. And whether we're being unrealistic about the longevity of our code. 

[00:47:47] JG: Yeah. There are times and places where it's very reasonable to write unit tests. Get extremely high coverage. Have perfect type safety. Have perfect linter presets. But if you're running experimental code, that's time spent that may or may not be worth it in the long run. Are there particular strategies that you employ when trying to decide on how much level of investment or scaling you want to take on a particular project? 

[00:48:08] LK: This is I suppose what everyone says is it's continually difficult to be striking that right balance. One of the things – because this is also something that comes up in accessibility is the idea that, "Oh, well. We don't need it to be accessible yet. This is just experimental. Or this is just an early stage." And it's really knowing for yourself on your principles what your minimum viable product is. Not just in terms of what features it has or how it works. But who is allowed to use your minimum viable product? Is your minimum viable product private? Is it something that respects people's privacy? Have you actually given thought to that? Have you got consent for the features that you might need to get consent for? And also, is it accessible? 

If you decide, "Oh, my minimum viable product that I am releasing to the public. But I've chosen not to pay any attention to how accessible it is." Well, that's quite a strong position to take. And so, I'm kind of – well, I suppose I was going to say, even on performance, I can be quite flexible. Scaling, maybe that's something you need to balance. But also, performance and scaling, not the same thing. Because, of course, if you have something that takes forever to load, that's also going to impact people that may not have the money to have really fast internet connections or it's not available where they live. A lot of the decisions we make all the time are decisions that can exclude particular types of users in a way that might even verge on being discrimination. 

[00:49:42] JG: Well, legally speaking, oftentimes, what we might consider verging on discrimination in fact is discrimination, right? We haven't actually mentioned that, in addition to the moral and financial incentives to be accessible, there are actual laws such as the ADA in United States that stipulate that companies that release something publicly need to make it accessible to all. Yeah. 

[00:50:03] LK: Absolutely. And whilst I think I like to treat people with the carrot of accessibility being available to as many people as possible rather than beating them with the stick of you might get sued. But also, because the carrot is more likely to come about than the stick. The number of people that have been sued for a lack of accessible websites are relatively few. Although, notably. Beyond, say. It depends how you frame it. It's the same as I don't really like to frame accessibility in terms of, "Oh, your business can make money because you suddenly have this much wider audience of disabled people." It's kind of better to think about it in terms of, "Oh, hey. You're actually deciding that you're willing to exclude this person. And that is not a cool perspective to have on life. 

I always say that if you're building something that's as widely distributed as the web, then you have a responsibility to make it accessible to everyone. I mean, yeah. Sure. If you're building something for three people and you know exactly what their needs are, knock yourself out. You don't need to make it accessible. Although, you may not be aware of the accessibility needs that they actually have.

[00:51:12] JG: That's very true. The way that you have to optimally describe accessibility is very different on not just the target of who uses the product but who you're even explaining it to. A financial decision-maker for a company may unfortunately be primarily or even solely motivated by the making money. Whereas someone who acts more like a, say, human being might be motivated by the moral side of things a little bit more.

[00:51:35] LK: Yeah. I like to think that sometimes there'll be financial people that are also human beings. But yes, you're right. You pick your argument depending on who you're talking to. I guess we do that with all different kinds of areas of technology. You tailor your explanation to your audience. And, yeah, it is the same for accessibility. 

And I do think that, broadly in the mainstream, an awareness of inclusion is increasing. And that in turn is increasing awareness of accessibility and that hopefully will filter down to the industry as well. 

[00:52:07] JG: I think it has been. Perhaps not at the rate that we would like it to. But there's certainly been an uptick. As you said, more than just the last 5 years of folks interested in this stuff. And I wonder, do you see a similarity with state machines? Where now that people are starting to see the benefits, both the carrot and the stick of proper state management, do you think this is going to be more of a trend over the next decade or two? 

[00:52:26] LK: I mean, I'd like to think so. But of course, I'm in the Stately bubble. To me, everyone loves state machines and are using them already. But yeah, I'm starting to see increased awareness. 

It's interesting, I always ask at the beginning of my talks about Stately-related things or state machines. Who here has heard of state machines? Who here learned about state machines? Because they studied computer science. Because that is often people's way in. And I suppose the new question I need to ask is who here has heard about state machines? Because they use XState? Because they follow David Khourshid on Twitter? Or DavidKPiano as most people know him? Because it turns out, even a lot more people that I come across have actually learned about state machines from him then even learned about it from a computer science course. 

[00:53:14] JG: There's a sweet irony that you, as an art school person, know significantly more about state machines than what is probably the vast majority of people who learned about it in computer science class and then never used it after graduation. 

[00:53:26] LK: I think that's how education works though, isn't it? We learn things and we forget about them pretty quickly. And then, suddenly, we're like, "Oh, that term sounds familiar." I think, also, I can really see the value in state machines for not just developers but everyone else on the team as well. Think about it from a designer's perspective. It's really hard to know what states you have to design for. You often forget to design for error states, and edge cases and things like that partly just because of the way that design as a discipline has evolved out of more of a print design way of looking at things a lot of the time. And we're often envisioning things as screens or views. It's very easy to forget about all of those not happy parts. 

I think that they're really valuable in being able to identify those for designers. And I think if we look at it alongside the requirements that you might have for an app that you're building, you can develop those into a state machine pretty easily and it's something you could do as a team. And that way, everyone has a much better idea of how things work together. That's one of the things that also really appealed to me about state machines was how it could bring our different disciplines much closer together. 

[00:54:36] JG: Do you see a future where there could be some kind of halfway point or hodge podge of Figma-style tooling? Visual design with very nice collaborative features and Stately where you can represent those states with each other and collaborate on them? 

[00:54:49] LK: Oh, 100%. These are things we're already working on for Stately Studio as well, is the idea that, "Hey, maybe you want to have different Figma-like mockups in inside of your states to show how that state will look or work." Yeah, it makes sense. It's one of the biggest requests we get is how do I plug my Figma into Stately or my Stately into Figma? 

[00:55:13] JG: What is Stately Studio? 

[00:55:13] LK: Stately Studio is state machines as a service. Although, you can do a lot more with designing flow. State Studio is how you visualize your state machines. It's a tool. It's free to use. You can have as many public projects as you want. But there are some extra cool features if you want to sign up as pro or teams as well. So, you can have shared projects and private projects. Or you can generate flows from text descriptions. With the wonder of AI, you can also even generate React UIs nowadays from your state machines. You can put the two together and go from a text description to having a react UI for your prototype very, very quickly. But, yeah, there are lots of tools and ways to import and export your state machine so you can use them in your projects in a way that works for you.

[00:56:02] JG: How long do you think it'll be until we're setting up, let's say, a state machine to start and then scaffolding an entire application or most of an entire application on top of that semi-automatically with AI? 

[00:56:16] LK: I would pretty much say already in Stately Studio. The features from the last week. Yeah, you can do a huge amount. And, yeah. Right now, you can generate a UI that's button – if it's got lots of buttons and interaction that way, you can generate that. 

But, yeah. We're not far off. I still think it's probably useful as a starting off point. Or for prototyping, it's really great. I think if you're trying to build the entirety of your app from one state machine, you might be overdoing it with the state machines. Or you've just got a really simple app. In which case, that makes sense. 

[00:56:47] JG: It's nice to have a simple application to represent. Although, I fear most apps that start simple do not remain that way. 

[00:56:52] LK: Yeah. Even in a really simple demo that I've been doing recently that's just a little white noise machine has some buttons that you can press. I've ended up using two-state machines for that. One for the audio aspect and one for the UI. Because it makes sense to break that logic into something a bit more modular and maintainable.

[00:57:12] JG: That's a lovely point to make. And for the technical portion of this interview, I'd like to dive into random unrelated questions about you. Is there anything else you'd like to cover on next state, or state machines, or accessibility and so on before we move on? 

[00:57:26] LK: Just to say that I do a lot on education around Stately and XState. And the docs are something that I've worked on a lot. We have cute examples that have puppies in and things like that if you're really new and you want it explained in a way that will be easy to understand regardless of what your background is. 

But also, if anyone is learning and needs some help or wants to give me any feedback on how they're finding it, please let me know. I hope you can tell from this podcast. I'm a friendly person. And I'm really up for hearing from any people that want to progress with it. I want to make these things better for everyone. That's my point. 

[00:58:02] JG: At the top of stately.ai/docs, you've got this nice warm welcome. These docs are in beta. Please give us any feedback in our Discord documentation channel. Have you found that people do that actively? 

[00:58:13] LK: Yeah. Y eah. This is me coming from an art school background. It's often really around their specific use cases. Like, "Oh, why do you not describe my exact use case here? And how can you help me do that?" And so, sometimes you have to filter the feedback in the right way. But I think that a huge number of people come to us for support. And I always use that to try to improve the docs. Because we have a really great team for offering support. We're a really tiny team. Not many teams you'll get the CEO regularly giving support every day. But we do. 

We always try and filter that back into the docks and be like, "Oh, someone's struggling with this. It's probably because we don't explain this concept well enough. And how can we make that better?" 

[00:58:59] JG: I know we're running short on time but I really want to emphasize and plus one what you just said. That when someone is struggling with something, it's so much more often an issue with the documentation of the product. Not that that particular person is a buffoon or whatnot, right? That's such a good way to get docs feedback from users.

[00:59:16] LK: Yeah. Because you want your docs to be easy for everyone to use and understand. And good docs are so underrated as well. It might not be fun for a lot of people to write docs. I personally find it really fun and satisfying to write good docs. I do think it is a really good skill to develop. But I think this also comes from me often feeling quite an impostor in engineering and struggling because I don't understand what a particular concept is because I missed that part of whatever the fundamental education that people don't really get. But somehow, everyone else knows about this thing and I don't. And these docs are so hard to understand because I don't understand this particular thing that everyone's referring to. And so, I'm quite sympathetic to that perspective. And I want to make docs that you could be a developer who is pretty new to development and I want to help you understand what a state machine is without any prerequisite knowledge. 

[01:00:13] JG: Excellent. Let's move on. Laura, you have lived in the UK. You now live in Kilkenny, Ireland. Are there differences or different phrases you've picked up in these different places you've lived that make you happy? 

[01:00:28] LK: Well, because I'm very British person, I love very distinct Irish phrases. Ireland does have its own Irish language. But most people in Ireland speak English but with a really distinct Irish flavor. And I think one of my favorite things is, when something is good, Irish people will say that's grand. In fact, they'll say it for a lot of things. And I just love how it's so exaggerated. It's not just good. It's not just great. It is grand. 

And the other one that I love is, as someone who – I love a bit of casual exaggeration and hyperbole. And the idea that when you say thank you, I'm one of those people who will say thank you so much. Because I mean it. But Irish people will say thanks a million. I love it. It's like saying almost infinite amount of thanks. So much thanks. A million thanks. That's one of my faves. 

[01:01:25] JG: That's great. We happened to intersect a NodeConf EU over in Kilkenny. And I picked up quite a few Irish phrases. And I want to give a shout-out to John Allen for teaching me quite a few that unfortunately cannot be repeated on a nice podcast. But one that was really cute was someone who still has their communion money. They're very stingy or frugal as a person, as a phrase.

[01:01:46] LK: And that is because you're given money when you take your communion, which is Christian. But largely Catholic in Ireland. And so, you'd probably take your communion. Now, I'm not personally Catholic. But I was brought up as a church of England Christian person. And so, we did – I think communion is usually maybe 11 or 12. If you've kept your money that was given to you at your communion that long, then you're very stingy. 

[01:02:15] JG: That's such a cool way to get to a phrase. Also, one last question for you. How much of your clothing do you make yourself? 

[01:02:23] LK: At this point, probably 90%. I'm still working out the skills for underwear. Oddly quite tricky to make underwear and socks. I don't think it's worth – you could probably knit socks. It's quite time-consuming. But yeah, I learned how to make clothes during COVID. I had a sewing machine. And I needed desperately to get away from the computer. And so, I've found it's a fun new skill. And I really enjoy making things that I guess is a form of self-expression. But largely, it's just really nice to make stuff that fits me properly better than all the stuff I can find in the shops and in the colors and fabrics that I like.

[01:03:01] JG: Has there been a particular color or fabric that you've been binging recently? 

[01:03:05] LK: I'm on Orange. And I only recently realized that I have made loads of items of clothing that match my car. Because my car is orange. You don't normally think about the color of your car when you're making clothes until you stand next to your car in said clothes and look absolutely ridiculous. 

[01:03:23] JG: There's a running joke in the world that people look like they're dogs. You have a dog named Oscar who you do not look like. For you, it is your car is what – 

[01:03:31] LK: Yeah. I look like my car rather than my dog. I wish I look like my dog. He gets so much attention. Because he is a very beautiful dog. And he really knows. He is a husky-malamute cross. He is a very noble-looking beast. And is massive as well. And, yeah, he has been my best friend for 12 years now. I've had him since he was six weeks old. And he is a great companion. 

[01:03:57] JG: Is he why the Stately docs refer to dogs? 

[01:04:00] LK: Yeah. I've probably always got something about dogs in the back of my mind. There's a lot of dog people at Stately as well. There's a lot of dogs on the Stately team. Although, there are cat fans as well. I have nothing against cats. I think cats are great as well. I just have a dog who is an only child. 

[01:04:17] JG: You've learned the hard way, I'm guessing, to mention you're okay with cats to not turn this into a dog versus cat situation. 

[01:04:24] LK: Yeah. Especially when I'm conscious that you are very much a cat person as well.

[01:04:29] JG: This is true.

[01:04:30] LK: There are only so many people I've met who would go and feed the stray cats. Go and buy pet food specifically for the stray cats in a place that we're visiting, which is a very lovely quality that you have, Josh.

[01:04:42] JG: Thanks. This is a general tip for anyone attending a conference abroad or in a place that they're not previously familiar with. Buy some cat food and then go feed the cats. It'll make the locals love you. It'll make the cats love you. It's a legitimately fun and reboarding activity. And it gives you an excuse to walk around. Highly recommend. 

Anyway, all that being said, this has been an absolute pleasure. Is there anything else you'd like to talk about, Laura, before we hang up? 

[01:05:08] LK: Not that I can think of. But I can tell you, if you ever want to say hi to me, I'm Laura Kalbag. And I'm findable everywhere. Because I have a very search-engine-friendly name. To my knowledge, entirely unique. 

[01:05:22] JG: You are the only Laura Kalbag that comes up in the first three pages of Google. Fun fact. 

[01:05:28] LK: Yeah. And I expect subsequent results are, yeah, other people with the same surname as me. There aren't very many of us in the world. 

[01:05:36] JG: Great. Well, this has been a fun interview. Thanks so much, Laura, for hopping on. And I hope to see you at another conference.

[01:05:42] LK: Thank you very much for having me. I had a great time.

[END]