XO Ruby Atlanta 2025 - Play with your code by Rachael Wright Munn

What is discussed, and when

1. 0:00 – 5:00: Upcola, Battlesnake, Exopunks, One Dreamer
2. 5:00 – 10:00: Exopunks, One Dreamer
3. 10:00 – 15:00: Battlesnake, One Dreamer
4. 15:00 – 20:00: One Dreamer, Battlesnake, Dragon Ruby, Exopunks
5. 20:00 – 24:19: Bit Burner, Code Romantic, Exopunks, One Dreamer

Notable quotes from "XO Ruby Atlanta 2025 - Play with your code by Rachael Wright Munn"

• Hi everyone, I'm Rachel Wrightman and I have a question for you all. why are programming games more fun than our day jobs? But before we can really answer this question, I think we need to.

  about Rachel Wrightman · at 0:05

• And then this one is exopunks. So, it's really rad. You are infected by a disease that is slowly turning your organic parts into machine parts. And you an AI is giving you these.

  about Exopunks · at 1:00

• So at the beginning of One Dreamer, Frank is working for a soulless game studio. He gets an email from his boss.

  about One Dreamer · at 2:38

• First of all, we've got LSPs, but there's also ways to include it inside the engine itself. So Dragon Ruby will actually put tutorial games inside the engine and their…

  about Dragon Ruby · at 15:45

• I'm going to base this on the conversation that we had earlier. There is this game called Bit Burner where you are optimizing and hacking servers and you can write it's like I…

  about Bit Burner · at 22:11

• Code. do you like romance? on the easy get into game development side, Code Romantic is actually focused on teaching people to, code. It's made by a developer who used to be…

  about Code Romantic · at 23:03

Who and what is mentioned in this episode?

People

• Rachel Wrightman — Person · 1 mention · first at 0:20

Companies & orgs

• Upcola — Company · 2 mentions · first at 2:45
  They've got a lucrative new product deal with Upcola and he has to make an NPC mention UPCA and then display a billboard. Delightful. So, let's see what that developer experience is like.

Products & tech

• Exopunks — Product · 7 mentions · first at 1:00
• One Dreamer — Product · 7 mentions · first at 2:38
• Battlesnake — Product · 4 mentions · first at 0:49
  Experience. And they can look very different. So for example, this one is Battlesnake. It's a multiplayer snake game where you have a server, they send you the board state and…
• Dragon Ruby — Product · 1 mention · first at 15:48
• Bit Burner — Product · 1 mention · first at 22:15
• Code Romantic — Product · 1 mention · first at 23:08

Concepts & topics

• Ruby — Concept · 3 mentions

Full transcript with timestamps

0:20 Hi everyone, I'm Rachel Wrightman and uh I have a question for you all. Uh why are programming games more fun than our day jobs? But before we can really answer this question, I think we need to answer another one which is like what are programming games? So a programming game is any game where creating or modifying programs is a core mechanic and they really make programming fun through a playful and joyful developer experience. And they can look very different. So for example, this one is Battlesnake. It's a multiplayer snake game where you have a server, they send you the board state and you respond with the move that you would like your snake to make in under 500 milliseconds. So, your snake just keeps on trucking along.

1:00 And then this one is exopunks. So, it's really rad. You are infected by a disease that is slowly turning your organic parts into machine parts. And uh you an AI is giving you these nonsensical hacking tasks in exchange for medicine to slow the progression of your disease. So, you're writing programs for these tiny robots. Those are called X's. Your documentation is a hacking zen and you need to program your new machine parts to function as your old ones did. So this red gif right here, that's you reprogramming your hand. This last one is the most beautiful atmospherics dorydriven programming game that I've ever seen.

1:34 It's my favorite and that's not because I'm in it. I played the demo, loved it, got involved, not the other way around. So you're playing as Frank, who's this disillusioned indie game dev who's following in the footsteps of Jumbo, a game dev with the same experiences. So, you're kind of on this search for meaning and understanding like what's happened to Frank. And you're playing through and fixing his indie game and trying to kind of remember what made you want to be a game dev in the first place. So, this one mostly involves setting and copying variables and getting really creative with your with their usage. It's got heavy puzzle game vibes. And uh in this one, you get to walk, which is very rare for a programming game. All right, so now that we know what the games look like, uh we can start to talk about what makes them more fun than our day jobs. And uh to answer this question, we can actually

2:19 look at the games themselves. So a really common theme is contrasting the player's drab work life in the opening with a joyful in-game experience later. So this version of work is going to be very exaggerated, but it provides a good contrast to clearly see the developer experience improvements that they build out in the games themselves. So at the beginning of One Dreamer, Frank is working for a soulless game studio. He gets an email from his boss. They've got a lucrative new product deal with Upcola and he has to make an NPC mention UPCA and then display a billboard. Delightful. So, let's see what that developer experience is like.

2:54 All right. So, we're going to shuffle through some files. Ah, there are billboard sprites. There's the upcola one. All right. Uh oh, and here's where we go in and we modify it. Okay. That's probably where we're going to put the dialogue. Probably should turn the NPC on. That might help. Uh, let's see. Oh, and this is going to be the dialogue, of course. It looks like we've got some character named Snow, I guess. And this is what he did before the battle. There's our upcola ad. Well, that's kind of subtle. Oh, never mind.

3:26 Well, okay, that's uh we'll just update this. And let's see. Green checkbox. And we're done. Well, okay. We knew that was going to be the drab and soulless experience. So, let's take a look and see how we contrast that with the actual in-game experience. Oh, so here we can actually interact with the NPC immediately. And we've got all of the code that's needed to uh modify our NPC and our dialogue options. And we'll go through here, look at all the dialogue options. Uhhuh. Go back. We've got our interact here. We'll go ahead and set those. Uhhuh. Pick our index and our file. Ah, there's that beautiful glitch effect and we're immediately interacting with the new code that's been modified.

4:13 On the surface, these two interactions are really the same. We're going in modifying the dialogue of an NPC. But I think there are key elements of the developer experience that change how it feels to do these interactions. First of all, at work, we're receiving tasks through email. In the game, we're self-directed. We're choosing what it is that we want to do and the interactions that we want to make. At work, there's no feedback. We don't see the NPC, but in the game, we have the immediate feedback. There's that beautiful glitch effect, and we're interacting with our newly modified code. The work one is uninspiring. We're adding an ad, and it's something that we choose in the game. We're missing context in our work example here. Who is Snow? Right? Like, what scene is this? Who's playing the game? For Borderlands, it might make sense to include a promo code, but it sure doesn't for Dragon Age or Skyrim.

5:07 Meanwhile, we have the full context in the game. We can see the world. We can see the NPC. We can interact with them. And we know who's playing the game. We are playing the game. And our last point is that obviously One Dreamer is beautiful and it's colorful and it's gorgeous. And our work one is pretty gray and drop. But this is just one example of what a developer experience looks like and a contrast that's in the game. Exapun is even more dire. So in Exapun, uh we're doing data entry. Yay. That sounds fun. And if we get it right, 10 cents.

5:43 That compares to the Exopunks experience that we see here where we can see what's going on. We can interact. It's bright. It's colorful. It's dynamic. We can see the world. Now, we've looked at how to contrast these two experiences, particularly in the games, and I think now we're really ready to dig in to what lessons we can learn from programming games and take back to our day jobs. We're going to cover five topics. We're going to cover that immediate feedback, color documentation purpose and autonomy. For each topic, we're going to explore examples from programming games, and then we're going to talk about how to apply it to your day job with concrete tips and examples.

6:19 So, let's talk about immediate invisible feedback you can get to games, you can get from games. So, we're going to analyze this scene again, right? We're walking up to the NPC. When we edit the code, we have access to all of the code that's used to modify it. We have access to what in Rails would be the controllers. We have the config files. We have the full experience to modify that. This is the equivalent uh equivalent. This is the equivalent experience to clicking a button inside of a UI and opening up all the files needed to modify it. We have that beautiful glitch effect, but we also have a summary of changes that shows up in that lower left to tell you exactly what's changed. And the way that it hot reloads means that you are immediately interacting with your changes in your code. There's no delay. There's no in Ruby, we don't have to deal with compilation, but there's no delay between when you make the change

7:06 and you get to experience it. This is a beautiful developer experience that drives you to explore and interact and want to modify the world around you. Now, let's look at Exopunks. So this is code execution in Exopunks. It is an incredible debugging experience because at any given moment you are aware of what line you're on, every single register value. You can see what file your Exa is holding. You can see what field inside that file is being modified. And you've got this visual representation of your code's execution and what's happening. In fact, if we look at that digicam feed, you've got a visual representation of what's happening in the real world. like that tape deck, the correct one starts spinning when we access it. So this is a dream developer experience. You have this immediate feedback and unparalleled visibility into execution. Now let's get into the core of this talk. How do we

7:59 apply this to your job? So first off, a great way to get better and more immediate feedback is test driven development. So I'm not saying that you have to write a hundred tests like an exopunks, but TDD is one of the most satisfying ways to code. you have clear feedback, easy to manipulate arguments, immediate regressions, and you don't have to write tests at the end. Next, I want to talk about live reloading. So, when I work on my Jackal blog, I will put my code and my live reloading site side by side, which means every single time I make a modification to my code and I save it, I can immediately see the changes and see what's happening on the actual site itself. Last, I want you to think about your debugging tools. So, like how close can we get to seeing each line execute like an exapunks and all of the values and what they're set to. So, if you've just been dropping puts in your application or trying to debug in the

8:49 Rails console, I want to show you something. So, this is binding.b. It comes with Ruby. You don't need any additional libraries or packages. Um, once you've got your test set up, what you can do is drop a binding.b anywhere in your code. And when you run your test, it'll open an interactive Ruby console right where you are. So, you can call methods and variables and modify your state. So the first thing that's going to run is where am I to tell you exactly where you've placed that binding. Local variables will give you a list of all of the local variables that are defined at that location. Instance variables gives you all of the instance variables that are defined at that location. This is really helpful for example if you're debugging controllers because you can actually see everything that's defined from the action controller um in before actions and everywhere else as well.

9:33 Show source and a method name is going to bring the source of any method into that terminal for you to review it right there. And then IRB show commands is a list of commands that are just as helpful as this one. Last but certainly not least, ls is going to give you the closest experience to exopunks that you can get inside of Ruby. It's got every single method defined in that context and its source. And it's got every variable from local to global. So these are all ways to get more immediate and visible feedback evoking the developer experience that we see in exopunks and one dreamer. Next I want to talk to you about color. So I got a really interesting comment after I gave a lightning talk version of this one at Railscom, which is I didn't know programming games could be so bright and colorful. And I don't think there's any doubt or confusion about why that's the case. They're bright, they're colorful,

10:24 they're beautiful. And so let's talk about how we apply this to your job. Now, I hope when I talk about bringing color into your developer experience, you think about terminal themes because we love editor themes. This is mine, by the way. The number one question on my Twitch stream is currently, "What is your editor theme?" It's Horizon by Jalalai. And uh if you haven't noticed, my editor theme and my slides match. If you take a look at those first three colors, we're going to talk about color today. We've already talked about editor themes. Now, let's talk about beautiful applications because it's more funny.

10:59 It's more fun to work on a pretty app than an ugly app. And last, but certainly not least, how do we bring those colors in? If you're looking for fun ways to bring bold and bright and beautiful colors into your developer experience, you can put them into your application. So, this is my application meet another day. And if you haven't noticed, it matches my editor theme. All right. So our last topic is going to be a little bit more serious than those last few which is CLI clarity. I want to talk about how we use color in our CLIs in order to provide clarity. And I'm going to use CLI because it's really short but this is going to apply to any terminal output output from rake tasks logging anything that you're working with. The first example that I want to show is RSpec. I think RSpec does a really great job of this. It's easy to differentiate passing skipped and failed tests and it's easy to differentiate

11:49 your error versus your stack trace. I'm going to take a quick minute to note that they use more than color to indicate this because there are people who are color blind and terminals without color. But I think the color really helps people who can see it. I want to look at a comparison of two outputs and discuss how color impacts them. So on the left here, we have a get status inside of an interactive ad. And there are layout changes here and more information. But I think that it's pretty clear when we look at the option on the right, which is a regular git status. It's easy to see what changes have been added and what changes haven't been because we already have this understanding of green versus red and what's included. I'm hoping that after this you're thinking about how can I add color to my CLI, which again shortcut uh is a shortcut for any sort of terminal output. And uh I have an answer for you.

12:38 So what we have here are an color codes over here on the left. And you can add these to any terminal output that you have from your log files, rake tasks, etc. And uh you do not need any additional libraries. This works if you're working with bash, if you're working with Ruby, if you're working with files, anything because it's parsed and understood by the terminal. So we have the colors on the left, reset code on the right, and then that method in Ruby is all that is needed to add colors to your output. Now, these eight colors on the left are very, very special colors. The reason being that if you use these eight colors when you have your output, it will match your editor theme.

13:18 There was a reason for that joke earlier. So, uh I hope that after this you add some bright, bold, beautiful colors to your developer experience. All right, so we talked about color. Let's talk about documentation. uh documentation is obviously going to have like some of that color theme coming through it. Uh so documentation is often considered dry and joyless but obviously in programming games um we want the experience to be fun. So let's explore how programming games have made documentation fun. First of all I want to talk about Battlesnake for here. I really feel that the color that they're bringing in is the main thing that they've done to make it fun. And I don't mean to be mean here but I feel like this is the experience that we normally have as developers. there's a big example request, there's an example response, and it's really not clear how those values mutate, how they change,

14:10 and what the decision-making is there. And I think that that's hard to read. One of the ways that Battlesnake gets past this is they create starter projects and templates so that you can immediately get up to speed. Generators would be a good example of ways to like jump past this. And what that allows you to do is skip past the part at the beginning of the project where you're actually reading through the documentation and trying to understand it. But I think that we can do better in One Dreamer. The documentation is visual. It's clear. It's contained within the editor for EDC access. Our example here is concrete, not abstract with a before and after. You may question the wisdom and separation of concerns involved in setting a lamps enabled state to the radio's enabled state, but One Dreamer has some fun spaghetti code aesthetics to it because it is a rushd game demo.

15:00 Our next one though is the one that I kind of teased at the beginning. Exapunks has a hacking zen for its documentation. Now, the really cool part about this is it's got stories, it's got demos, it's got documentation with like real style to it. And the cool part about this is you're able to modify what your format is in a Zen to match whatever it is that you're trying to teach. So, you can actually use something more visual. You can use something that looks a little bit more like command documentation. instead of trying to force all of your documentation through something like our doc or API documentation or blog posts, you're able to modify it and mix it up inside one specific scene. So let's talk about how we apply that to your job. So the first topic is getting documentation in your editor like one dreamer. So first of all, we've got LSPs, but there's also ways to include it inside the engine itself. So Dragon Ruby will

15:51 actually put uh tutorial games inside the engine and their documentation. So when you're accessing the engine, you can access the tutorials, the documentation, and everything else. I think LSPs uh as well have been helping with that. They're having a real moment in um Ruby right now. We've got Herb, we've got Ruby, we've got Rails. I mean, even Rubocop has them. So I think it's worthwhile to take a few minutes and see what LSPs are available for the libraries, frameworks, and packages that you're using to see if you can get that documentation inside your editor. All right. Next, I want to talk about tutorials, templates, and concrete examples. As I said before, it's really challenging when you just give someone a giant hash and expect them to understand what your request and your response is and how it should mutate. Um, I think that we should focus on building out template, starter projects, and

16:38 tutorials like we see in battles and exopunks. And I think that it's helpful to make it concrete like when dreamers and visual with images. One of the common pieces of advice that I see with documentation is that you shouldn't include images because they'll go out of date. Uh but I really feel that those concrete examples help to anchor people. I think documentation should guide in addition to just explaining. Last but not least, I want to talk about Zen and games and alternate forms of documentation. So these are wizard zenes by Julia Evans. So these are actual Zen documentation that exists out there for topics like git for the shell for ls. So it is possible to build real zen documentation like we could be coming to inerson events like these and swapping zen that discuss how to use different libraries frameworks complicated technical problems. Um and I think that that would be really cool. So there are

17:31 so many ways that we can learn from games to make our documentation more fun and interesting. And this is just some of them. All right. So next I kind of want to get a little more meta and kind of talk about purpose. So in games there's always this larger purpose or story that you're taking part in. So for example in One Dreamer you're drawn through all of these tasks and puzzles because you want to understand and explore what happened to Frank. And at the end you want to help him save his demo in his game. There's a greater purpose behind your actions. At work, Frank is adding DRM and selling up cola.

18:04 But in his game, he's able to focus on telling stories and connecting with others. So, if you'll recall from the beginning of this talk, in uh Exapun, you're being turned into a machine. At one point, you have to hack your heart into working again. Survival is a pretty good purpose. In fact, I'd say it's probably the one that brings most of us to our day jobs in one way or another. But the purpose I want to talk about for this one is actually curiosity. discovering who the AI is and what it wants. I think curiosity is what really drives you through the story. So, how do we apply this to your job?

18:38 One, you can talk to customers. You can talk to product owners and start to understand how your work and the changes you're making are impacting people and making their lives easier. Next, you can do meaningful work. So, I always feel really good about contributing to Ruby for good and all of the nonprofits that they support because I know that I'm helping to make the world a better place. You can learn something new. So sometimes we can't always do something that's inspiring or helpful to the world, but maybe you can at least work on something that's interesting to and new to you. All of these points are really about caring about your work.

19:11 Because if you don't care, aren't you just working to survive? So our last topic here is autonomy. This one is very, very meta. When we're sitting down to game, we're choosing to do it. It's never forced or compelled. It's not for survival. Um, the best game I can think of to represent this is Battlesnake because this is the developer experience. It's your repo. It's your deployment. It's all you and the choices that you have made. I think if you've ever worked on Battlesnake, Advent of Code, side projects, or open source, you'll understand this aspect of it. That autonomy, the freedom and agency to choose how you spend your time is part of why it's fun because it's more fun when you have a choice.

19:59 Um, I kind of want to come back to this topic of open source because I think that this topic of autonomy can actually be a really big cause of burnout in a lot of us. In particular, I think that maintainer burnout can start to happen when a project becomes an obligation. And yeah, so how do we apply this to your job? And the truth is that I don't know. Sorry. 20% time work in open source freelancing entrepreneurship. To be honest, I have no idea. But if you have ideas, please let me know. I go by Chill or Rachel. I use she her pronouns.

20:32 You can find me at chill codes on most social media sites. Chill. For the specific ones, my email is hello@chale.codes. I stream on Twitch Thursdays at 1500 UTC and you can come talk to me. And also I am looking for work right now resume at jail.co/links. I want to thank you all so much for your time and attention and I appreciate you being here today.

21:00 Are there any questions? Does anybody want a programming game recommendation? Yeah. Okay. Kylie, uh, let me ask you a quick question. Do you want a crunchy game or like an easy casual game?

21:18 Complicated and like hard rules and difficult programming concepts. So, the one dreamer one I would describe as like pretty easy because you're mostly modifying configs. Exapun is pretty crunchy because it's based on telescript and you have to actually write and execute and the problems are harder to solve. Crunchy. Okay, cool. Um, do you like story driven or do you like uh more like less story? You'd like a story driven one? Okay, so we're looking for a crunchy story driven one. Yeah, I'm going to actually go with Exopunks. The reason I put it up there is because it's one of my top five games. It's very story driven and it's very crunchy.

21:58 Does anybody else have questions? Justin, you'll take a shot. Third grader. um third grader who likes puzzles. I'm going to base this on the conversation that we had earlier. There is this game called Bit Burner where you are optimizing and hacking servers and you can write uh it's like I think it's either TypeScript or JavaScript. Um there was a free version of the game last time I played it, but it's focused on like optimizing servers and going out and hacking them. and you can kind of scale from um there's like a really low-level version of it where you're just like writing a short little script to go hack the servers and then there's a much higher level version where there are people who have open source repositories. There's one called Overmind where they will import in a management software to like go in and hack all of these servers and like Yeah, it's kind of wild.

22:55 No problem. You have a question up in the back of the camera. Easy game. Okay. Okay. Easy game for adults who want to learn how to code. Um, do you like romance? Um, on the easy get into game development side, um, Code Romantic is actually focused on teaching people to, uh, code. It's made by a developer who used to be at, uh, Minecraft and it's got kind of like a storydriven thing. Uh, the robots have become aware and they're invading the world. And the main story line is about um Mina Love Lace and uh his name is like Leon something and the two of them are like going out and they're fighting the machines and so it's all about like let's learn about if statements and stuff like that and it's really straightforward because you're focused more on the syntax side of things. Um other games to learn how to code.

23:44 There's a couple of like learn how to get and stuff like that. Those are fun. Um, and yeah, elevator saga is another good one because it's like JavaScript. It's in the browser. It's easy to do and you can kind of like scale up with it. Other questions? Okay. Uh, thank you all so much for your time.

Questions about this episode

What is discussed in "XO Ruby Atlanta 2025 - Play with your code by Rachael Wright Munn"?

In order: 0:00 Upcola, Battlesnake, Exopunks, One Dreamer; 5:00 Exopunks, One Dreamer; 10:00 Battlesnake, One Dreamer; 15:00 One Dreamer, Battlesnake, Dragon Ruby, Exopunks; 20:00 Bit Burner, Code Romantic, Exopunks, One Dreamer.

What is mentioned in this Confreaks episode?

9 people, works and ideas are mentioned, including Exopunks, One Dreamer, Battlesnake, Ruby, Upcola, Rachel Wrightman. Each one on this page links to its own page with every episode that mentions it.

How long is "XO Ruby Atlanta 2025 - Play with your code by Rachael Wright Munn"?

The episode runs 24 min; the transcript is about 4,560 words in 34 timestamped sections.

More from Confreaks

• All analyzed episodes
• Books mentioned on Confreaks
• People mentioned on Confreaks
• Topics mentioned on Confreaks