CoRecursive: Coding Stories - Burn out and recreational coding with Jamis Buck

Episode Date: January 25, 2019

A decade ago Jamis Buck was not loving his job. He was an important open source contributor. He worked for the hottest trendiest software company at the time, 37 signals, creator of ruby on rails. He was on top of the world but also he was burnt out. Today Jamis talks about how he overcame burn out.  We discuss how his struggle lead him to write a book about generating mazes and another about building a ray tracer. His books are great fun, and all about recreational programming.  You will learn to build things with a focus not on the latest trends in software development and not even a specific programming language.  The focus instead is on fun.  

Welcome to Code Recursive, where we bring you discussions with thought leaders in the world of software development. I am Adam, your host. One of my life's goals, I think, is to help people remember what they found in computer programming originally. That is Jameis Buck. A decade ago, Jameis was not loving his job, even though he was an important open source contributor. He was also working for the hottest and trendiest software company at the time,

37signals. They were the creator of Ruby on Rails. He was on top of the world but he was burnt out today i talked to jamis about recreational programming building mazes building 3d renderings he has written books on both of them if you like the podcast subscribe to it tell your colleagues when you are telling your co-worker about the strange 3D rendering engine you made in a couple pages of code over the weekend.

Tell them you heard about it on the Code Recursive podcast. Jameis Buck, welcome to the podcast. Thanks for joining me. Sure, thanks for having me, Adam. I have one of your books here uh mazes for programmers like in my hand and i've been also been looking through your other ray tracer book that they're like super fun books and i'm and i'm really excited to uh to to talk about them uh and then as i as i got this book and i started working through it I started internet stalking you a little bit

because I was like, who writes a book just about mazes? I noticed that for a long time or in the past you were the maintainer of very practical and important open source tools and then it seems like you kind of stepped back from them and now you're doing more kind of like, yeah, I don't want to say frivolous, but more more fun focused programming. So yeah, recreational recreational. So so what what led to that?

I mean, I've always loved programming. And I've always loved recreational programming. It was back in high school when I first even learned you could generate random mazes. And I've kind of been in love with that and ray tracing for a long time. So that part isn't new. But I had a dream job working for what was called 37 Signals at the time. It's now called Basecamp. And I really loved everything about it. The people were amazing.

The job was amazing. The work was amazing. The environment was amazing. The work was amazing. The environment was amazing. The compensation was amazing. There's nothing that was not good about that environment. But I just started feeling a lack of motivation, a lack of drive. I couldn't make myself focus over the course of a few years. And at first I thought, well, maybe I just have too much on my plate.

And so I started letting go of some of those projects like Capistrano and NetSSH and some of these other Ruby libraries that I'd been working on. And it didn't make much of a difference ultimately. Ultimately, I wound up leaving that job and taking about a year off. And that's when I wrote my maze book. And I basically discovered that what I was suffering from was burnout. And it wasn't a lack of my ability to work. It was more a psychological block that I had to, had to work through. And, uh, how did you know that you were burnt out on, on software or, or work or,

um, software used to be something that I loved to do as a hobby in addition to professionally. So I, I always had a dozen things going on the back burner, just on the side doing this, playing with different ideas, experimenting with different technologies. It was just always something I was very passionate about. And then over the course of about four years, my desire to work on any of that just dropped. And it really wasn't until, well, probably until the last six months at Basecamp when I stumbled on some article that

was talking about burnout, and it really clicked for me. this is what I was struggling with and what I was suffering from. But by that point, I'd already like divested myself of all my side projects and just couldn't focus at work, couldn't get myself motivated. It just wasn't fun anymore. And it was really frustrating because I loved the people there. I loved my bosses. I loved the work. It was really a great place, but it wasn't fair to them that I'd be pulling a paycheck when I couldn't do the work. So that's kind of like in retrospect,

like looking back on it all, um, well, burnout is an interesting thing. People get this idea that you burn out because you've worked too hard. You burn out because the workload is too heavy and, and you, you work too hard and you lose all your motivation and then it goes away. And that's what causes burnout. And it's true that that is one thing that can cause burnout. But there's actually a lot of different factors that can play into it.

And so that wasn't my story at all. For me, it was, there's another factor, like a lack of control is what it's called. And for me, it was this perceived lack of control over my environment and situation that I think actually triggered it for me. Back when I was working on Capistrano, which was a tool I wrote for Basecamp for 37signals for deploying and managing multiple remote servers. I wrote it as part of my job, but then Jason and David, my bosses, gave me that tool to be my own, to do what I want with, to manage it and maintain it. And so that was really cool, very generous of them, and I worked really hard on it. And I lined up a gig where I was going to be able to go and do some training with it, and i worked really hard on it and i lined up a gig where i was going to be able to go and do some training with it and i was really excited about that

but when david heard about it he pointed out that there was kind of a conflict of interest there that um you know was i working for base camp or was I working for myself doing training and pulling money that way? So he basically discouraged me from doing that. And when I learned about that, it kind of took the wind out of my sails. And over the next couple of years, I found myself losing the desire to work on anything. And it seems silly to talk about it like that because it wasn't that big of a deal. But it's the kind of thing where it was a psychological injury, I guess. It just took me by surprise, caught me unawares,

and I never quite got my feet back under me after that. And it was far too late by the time I realized what was going on and what was happening so anyway that's that's kind of my burnout story my you know if I were to do it all again I I don't know maybe if I'd known more about how it worked and what burnout was and what what my struggle was maybe I could have recovered sooner. But it's been a good path for me overall. I've learned a lot and I've grown a lot and I've done a lot of things I probably wouldn't have done otherwise. Like, did you know at the time, like, how much this would affect you

or is it more of a, like, under the surface type of thing? It was really subtle like I said at the time when I was told I couldn't do that training for Capistrano I was frustrated but I got over it you know I recognized that I probably did need to focus my priorities and choose one or the other. And so at the time, it didn't seem that career-threatening. It was only in retrospect that, you know, as I pondered the path and the pieces all came together that I saw how that all worked. Yeah, I don't know. I don't know that I had any inkling at the time where it was going to go.

Even at the darkest time of my burnout, I don't know that I really realized what was happening. That sounds like the trickiest part of the whole thing, to be honest. You can't see it it is really subtle the whole the whole process is it's not like falling off a cliff it's like walking down a gentle slope until suddenly you're you're way down in the valley in the dark and you're wondering how you got there and you're not sure what the problem is and you're not sure what the solution is and you know for me it a better part of a year to recover. And I still, like, I don't have the same desire

to do software all the time that I used to. And probably that's healthier. Have a little more balanced lifestyle. But, yeah, I mean, it changed me. And for better and for worse, I think. How did you recover from this? Well, the first step was for me to quit my job, which was terrifying. We had some savings set aside and we could, we knew, and then my wife started teaching some music classes to supplement,

but we were okay. But it was still terrifying, you know, wondering how we were going to do health insurance. We had young children, four young kids. But, you know, that's what I had to do. I had to get away from it all for an extended period of time, try a bunch of different things, and really kind of, you know, think a lot about it, get to the root of what the problem was and how I got there. Eventually, I, you know, I wrote

that book about programming or mazes for programmers. I wrote a little online novella about algorithms and exploring algorithms. And I did a few little quirky side things and gradually kind of got my feet under me again and hung out a shingle, and I've been doing freelance ever since. The reason I ask you about this, it seems very personal, but I found when working through the Maze's book, which is the one I'm most familiar with, it seems to be invigorating, almost, you know, an antidote for burnout. And I wondered if your experience had informed these books. I hope so, because that was really part of my journey after quitting base camp,

was kind of thinking about the things that used to excite me about computers. And I thought back to high school when one of my classmates first showed me a program that he'd written that generates a random maze and just being like blown away by that. And just the joy I remembered from tinkering with ray tracers and ray tracing. And it all just kind of came together with the maze book realizing, you know what? I think I, cause I wrote, I wrote a whole series of articles on my blog about the maze algorithms and it

all kind of came together during my year off, basically. And I was like, you know what? I probably have something to say about this. And it really is in large part, I want people to remember what brought them to computers. And not everyone came to it because they found something recreational to do. You know, a lot of people come to it because they want to make a career out of it. They approach it more businesslike. But for a lot of us, writing your first computer program was like discovering that you can cast magic spells and realizing that, wow, if I tell the computer to do this, it'll do it.

And it's like discovering the superpower that you didn't know you had. And that was a really exciting thing, I remember. And I want to help people recapture that. That's amazing. Yeah. So I think the first thing I built that was like really legitimate was like a Yahtzee game. Awesome. And it would like keep score, Like you would roll the dice,

you know, and then it would, the trickiest part was like, it would figure out, I forget how Yahtzee works, but like figuring out which score thing applied to give you the best score for your dice. Yeah.

Awesome. Yeah. I think I did a, I think I did a war game back in high school when I was first learning to write software. And I did a bunch of choose your own adventure things you know it was awesome it was it's so fun to discover that stuff there's a certain I feel like there's a certain like narrowing down of like what I've done um

you know like when I first played around with computer programming and like there there was so much amazing stuff um but I feel like a lot of professional software development now, it seems to be like there's some sort of data store and you're updating it or reading data from it. Or maybe you're just knitting together two APIs into another. The domain has become very restricted. Yeah. There's a lot of specialization now.

And you start your career with the whole world at your feet, basically, and you get your first job, and then suddenly that's your specialization. Maybe it's developing web apps. Maybe it's sysops. Maybe it's whatever it happens to be. It becomes harder to break out of that because that's what you do all day. And I think it's easy to lose track of what originally brought you to the field. And that's where I hope books like, you know, Mazes for Programmers or the Ray Tracer Challenge, I hope those can help people either remember or rediscover

or find something new to love about computers. So let's dig in. So I'll start with the Mazes book. So what's a maze and why would you write a book about mazes and maze generation? Well, let me start with your last question first i wrote the book because i loved generating mazes and i was huge into dungeons and dragons back you know around 1999 2000 and it was right around the time the third edition of D&D was coming out in 3.5. And I wrote a lot of software around Dungeons & Dragons back then.

I wrote a character generator. I wrote a treasure hoard generator. And I wrote a dungeon generator. And I used some of the stuff I remembered from high school about generating random mazes. And I put that online. And it was surprisingly popular. People were really thrilled about that and it made me happy and I loved to work on it. So, you know, that's kind of where, that's where my history of mazes was, like little bits and pieces along the way and all of it

associated with happiness, you know, hobbies and bits and pieces along the way, and all of it associated with happiness, you know, hobbies and discovery and making other people happy. And so there's a lot of pleasant associations there for me. As far as what mazes are, it took me longer to embrace the, you know, the math behind it all. Because there is a lot of math behind the theory of mazes. And the happy thing is you don't have to know any of it in order to play with mazes. But if you do know it, it's like another world that's kind of revealed behind the mirror, you know, like it all kind of comes together. You know, maze is a tree, which computer programmers tend to be familiar with because we use those in a lot of contexts. But it's a tree that's been laid out in a particular way, okay, what if I take this tree, which is really a graph,

and I add loops to it so that you have cycles you can make inside the maze. Anyway, once you know the theory behind it, it kind of opens up a lot of other ideas. But you don't have to know any of that in order to start playing with it or even get pretty far down that road. Yeah, I'm surprised about how deep it is. Let's back up. So, we were talking about mazes.

This is just a maze like in a children's activity book. You start in one spot and there's paths and you find your way through. And then when you describe it as a graph, I guess I never thought of this before the book. I guess I haven't thought much in depth about mazes before. So it's like if you take your path through the maze and you consider each stop like a node, then that forms a graph, right? As you spiral out through the maze.

Is that the best way to describe it? Sure. I mean, that definitely fits the bill. Yeah. And there's so many different ways to construct mazes with different features. Like you can make a maze that's very windy with very long passages, or you can make a maze that's more direct with a lot of short little side passages.

That's one of the things, as I wrote the book, I didn't know most of those algorithms until I started writing the book. And it was so fun to discover them and think of how to describe them and how to implement them. I think it's very much a kind of puzzle in itself. People think of mazes as a puzzle that you have to solve, but mazes are also a puzzle that you can build, which is a really pleasurable way to approach it too. And in your book, you say that a maze is a spanning tree.

What's that? Yeah. A spanning tree. So a tree is basically, you're going to make me cover set theory here, graph theory. A graph is a collection of points called vertexes and edges that may or may not connect. Well, edges that connect vertexes. And not every vertex needs to have an edge, but every edge has to have a vertex at either end of it. So it's like lines and dots, right?

Mm-hmm. a vertex at either end of it. So it's like lines and dots, right? A tree is a special kind of graph where there is only one path between any two points in the tree. So you can't, without backtracking, you cannot cover more than one path between any two points. And that's what, it's called a perfect maze as a spanning tree, as a perfect maze is a spanning tree.

So a spanning tree is a special kind of tree that covers every point in the graph. So you might have a graph with two trees in it that don't overlap. But if you have a graph and every point is part of

a tree, that tree is called a spanning tree. And that's what these mazes are. These perfect mazes, uh, unless you add some, you change the rules a little bit because sometimes that's fun to do. And then you can wind up with other, other things. If I have a maze and it's like okay let's say it's five by five so it would have 25 cells so like in the graph theory world that would be like 25 nodes and then uh yeah uh so a tree a spanning tree is a tree that that connects all of them in such a way that um there's no loops is that did i get it right? Right, exactly.

So you can't find yourself walking around in circles in a perfect maze, which is a spanning tree. There's only going to be one way. And the only way you can walk in a circle would be to backtrack, like retrace your steps. And so you go through different ways to build mazes and so they're all really just at some level like finding this tree um finding well i guess there's many there's many possible trees right of a set of points and then yeah like if you think of even just a 2x2 graph, right?

Four nodes. You could enumerate pretty trivially all the possible quote-unquote mazes on a 2x2 graph. But as it gets bigger and bigger, that number grows very quickly. So like a 5x5 graph is going to have a very large number of possible spanning trees associated with it. And you're right. The task of generating a maze from a graph like that is effectively like reaching into a giant bag full of all these different mazes and picking one of them out at random. And some of the algorithms do a better job of being truly random about it.

Others tend to have biases, like might tend toward certain kinds of trees more than others. But yeah, it's like you never know what you're going to get until you reach in and you pull it out. like isn't the ultimate algorithm then to just like just iterate through that, that, you know, uncountable set of how many, I guess not uncountable, but. Yeah. Yeah. That, that set of all possible mazes for, or all possible trees for a given graph. Exactly. And there's only two that I know of that do that. They're called, it. When you do that, it drawback of those is they tend to be fairly inefficient in terms of speed. And that's why we tend to go with those, the others that have biases, because they are faster, especially as you get to larger and larger graphs.

Yeah, so an interesting thing, as I'm learning about mazes from your book, is this notion of biases. Where, like, you know, you walk me through an algorithm for generating a maze, and it's random, right? But as we generate it, the way that this algorithm constructs them actually has like a visual representation in some sort of bias. So how would you describe bias it's easiest to to describe bias by giving examples um for instance there's one algorithm the binary tree algorithm that the way you build it is you only ever choose between two directions at each node in your maze. And so because of that limited choice, your maze will always kind of run diagonally. It'll tend to have big, long diagonal runs through the maze. Another form of bias is like the recursive backtracker algorithm, which will generate these big, long, winding

passages. So the maze has a high degree of, it's called river, when it has a lot of long, winding passages. So that's another kind of bias. It's like if you go to a fast food restaurant, right, and you always order the same thing, or you know maybe one or two or three things that you always order eventually the people there are going to have your order ready when you get there because they can predict what you're going to do you you may randomly choose between those three things on the menu but they're still they know it's a pretty good chance they're going to be able to guess what you're doing and that's's, that's like bias. Whereas if there's someone who goes every day to the, to McDonald's or something and chooses something perfectly random from the menu. Yeah. You know, the people there may know their name,

but they're never going to be able to guess what they're going to order. Yeah. It'll just be, here's that guy who picks things completely strange items. Exactly. Here's that weirdo again are you taking things from from graph theory and applying them to mazes is that how you is that how you got here with the book i cannot take any credit for the algorithms in that book um there's a wonderful website called think labyrinth um walter poland is the author of that website, and he's done a lot of thinking, a lot of work on mazes and algorithms. He's compiled a list there, which is where I was first exposed to them. There's also, you know, some of the algorithms are more commonly referenced than others in different places.

The PRIMS algorithm and recursursive Backtracker, those show up pretty often, just even online, people talking about generating mazes. That ThinkLabyrinth website was really a wealth of information. I still had to, like, he doesn't give you actual implementations of the algorithms, so I still kind of had to puzzle out some of them. But yeah, his website was invaluable. But you're right that as far as graph theory,

like understanding graph theory, if you want to develop your own algorithm, you're probably going to have to really understand graph theory and what it means. You look at the researchers like Aldous and Broder and Wilsons who generated these algorithms that, you know, have their names attached to them. They're researchers and university professors and, you know, that level of academia. It's going to be a lot harder to accidentally stumble on a new algorithm, I think. What are mazes like teaching us about algorithms?

That's a great question. I mean, what is an algorithm, right? It's a series of instructions that tell you how to accomplish some task. And we're exposed to them all the time, not just in computers, but in everyday life, right? Whether you want to make dinner, right? You make something you've not done before, you're going to find a recipe that's going to tell you the steps to follow to do it. And that's an algorithm. So algorithms are ubiquitous and they're everywhere.

One of my favorite things has always been to find like a data structure, like a bee tree or something like that, and learn the algorithms associated with that data structure, like how to insert something into it or delete something from it. And I've always really enjoyed the puzzle of turning a description of an algorithm into a working implementation. So that's one of the things I love most about the whole maze generation is it's a collection of code recipes, basically, that teach you how to create these really visual things. There's just something so satisfying about writing a program and having it produce something visual. So, you know, for me, mazes are like the, basically just the visual side of algorithms. They're a great way to get excited about the puzzle solving side of algorithms because you can see them. There's something immediate about that. For example, like you had in the book, like Dijkstra's algorithm for...

So I had had to learn about this in the past, this algorithm, but I don't think it ever really clicked for me what it was. But in the context of a maze, it makes sense, right? It's like starting from a certain point of the maze and kind of like heading out in all directions. Yeah. You know, that's another thing I love about not just maze generation, but learning in general. When I was in college, I took a linear algebra class and I hated it. Oh my gosh, it was the worst class I've ever taken in my whole college career.

But the next year, I took a computer graphics class, and it was amazing. And the professor spent two weeks reviewing linear algebra, and it made sense to me because he gave me a context in which to relate it instead of being all these abstract ideas about like matrices and and series and all this weird stuff that just didn't click for me suddenly was like oh if you have a point and a matrix representing a transformation then you can do these things and it clicked and i had a lot more fun with it to me that's like dykstra's algorithm because i'd read about it too you know back in college but it wasn't until i was using it to navigate and analyze mazes that i was like okay this is where it's clicking for me and so it's like the more you learn the more things you have in your head to hang other bits of knowledge on and it just enriches your life so much yeah i'm not sure like

if everybody thinks or learns the same way, but like understanding these concepts through like very practical examples, at least for me, it gives me something to kind of hang on the concept. And then, you know, I can abstract from there. Maybe I can see where it applies in more in other scenarios, but it's helpful to have this like concrete vision of an algorithm, for instance. I liked this one, Hunt and Kill. Yeah, I mean, that was the very first one I ever learned. That was the one my classmate showed me back in high school.

And so for years, that was the only way I even knew how it was done. But yeah, it's a novel approach where you search linearly through the maze for the next available place to start carving passages through your graph. So yeah, I got the maze book. I don't know how I came across it. think i found it on amazon and then i ordered it and uh like it's it's beautiful and uh like it's color and it's full it's full of uh visualizations um and now you have this ray tracer book i don't even think it's released but i bought a pre-release copy or something um yeah it's just in beta right now so And so now you've taken this visual component to a whole new level. So now you're writing a book on 3D rendering.

What brought you to that idea? Well, like I said, I've loved ray tracing, which is a method of 3D rendering. I've been involved with that for a long time, just on the side. There's an open source ray tracer called POVRAY, P-O-V-R-A-Y, which a lot of people know about. And I've never actually contributed code to it. But, you know, 20 years ago, I used to hack in the code and like add features for my own use and experiment and see what would happen if I changed this or did that and yeah it was a lot of fun I really loved doing that and then actually let's see it was probably about two years ago my oldest son who was 15 at the time he's like dad will you help me write a program I want to learn how to write a program. I'm like, okay, sure.

So, you know, after a bit of thinking, I thought, you know, a ray tracer could be fun. It's been a while since I've done one of those. And so in Ruby, which is what I do for my day job, and I think is a great way to, you know, it's a very accessible programming language. So I wrote out a simple curriculum that he and I were going to do together. And we worked through this retracer and got it rendering spheres. And then I kind of went off on my own and was like, you know what, I could turn this into a blog post or something. So I outlined it all. And I was like, this outline could actually be another book. So that's kind of how it all started.

Because, you know, I've just always, you know, I guess that's a theme between my two books, right? It's the visual nature of, you know, getting that visual feedback from something new. And, you know, there's just something spectacular about rendering your very first 3D sphere. It's a good feeling yeah there's a theme of your books that they're visual there's the theme of them like you use the term recreational i really like that like they're like fun uh little things there's another theme that i don't see too often it's like they're they're

language neutral so your book isn't focused on like whatever learn capistrano which i'm sure you could write but instead on on like a specific like domain and you just you just go deep yeah like i i uh i mean that's kind of the way i am too i'm a generalist in a lot of ways i i like to be exposed to a lot of different things. And my regret is that for my maze book, I did it all in Ruby, which I find to be pretty easy to read, easy to pick up language. But I've had a lot of people push back on the book and say, you know, I was going to get that book, but then I saw it was in Ruby and I changed my mind, which made me sad. So one of my big goals with this Ray Tracer book was to make it completely language agnostic so that there was no actual source code associated with it.

There's just tests and pseudocode to really let you go, you know, in any language you want. And, you know, people have used my maze book to write mazes in a lot of different environments. So, you know, I've heard people doing it in Swift and C Sharp and Java and Python and, you know, Elixir and various others. But even just before this Ray Tracer book's even been out, my beta readers and my technical reviewers, they've been embracing all sorts of different languages and very successfully too, using just tests and pseudocode to base it off of.

And so that's been really exciting to me. And I want to see if i can find other ways to to do that to help make it more accessible to uh you know more people this this idea of recreational programming yeah i think it's great and like to me the maze book seems fairly neutral because like yeah you have it written in ruby but like uh i guess the thing is it's not a gigantic problem like it has a lot of different pieces that you can dive deep on but like it's easy to think about how i could recreate this you know using whichever technology i choose right and that's that was kind of my goal like both with the mazes and with the ray tracing one of the things that i

really am attracted to with them besides the visual aspect is the just how rich a domain they both are for exploration and experimentation there's a lot of room for playing what-if games like okay the algorithm said to do this but what if I change it this way or you know what if I combine these two ideas into one thing? There's just so many ways you can go. And at heart, I guess I'm an explorer in that sense. I like to try things and experiment with things and see what happens. So I guess we should describe Ray Tracer. It's like a 3D rendering.

Yeah. Some pictures in your books. So I guess we should describe a ray tracer. It's like a 3D rendering. Yeah. Some pictures in your books. I'm looking at one now. It's like a red glossy globe sitting on like a checkered background. And there's kind of reflections. And I'm sure people have seen these kind of ray tracer pictures before. They have like a, they always seem to me like almost more detailed than like reality yeah hyper realistic is a term that's often used to describe them yeah how how do you

build a ray tracer you know that's the thing people look at pictures like that especially if they have zero experience with computer graphics they'll look at pictures like that and say it's magic right yeah um but with any image like, you do it a pixel at a time. And with a ray tracer, you do it by taking a ray of light, and you follow it backwards from the hypothetical eye that's pixel in the scene. You follow it and if it hits something, you bounce it or whatever until you figure out the intensity of the color at that particular pixel. And then you do it again for another pixel. And then you do it again for another pixel. And so it's not fast.

I mean, there's been a lot of work done recently, especially for real time ray tracing, but this book does not talk about in any sense, real time ray tracing, but this book does not talk about, in any sense, real-time ray tracing. It's really just introducing people to the concept and showing them that, you know, with a remarkably small amount of code, you can actually create some pretty spectacular pictures. You're finding these domains that are very, like, fractal. Like, once you get into them,

there seems to be, like, you can go deep in any direction yeah yeah good description that's that's it exactly so in the maze book it feels like we're exploring algorithms and computational complexity through this visual medium of generating mazes yeah in some ways yeah so if that's the case about the maze book, what is the ray tracer book covering? Well, one of my goals with the ray tracer book was to take a very mathematically intense domain. Because there's no getting around it. There's a lot of math involved when you're taking a line and intersecting it with different shapes and primitives. And then trying to calculate the intensity of light arriving at a particular point. Like, there's a lot of math. But my goal was to present it in a

way where no one had to be a mathematician or a physicist to understand it. It could be more recipe-driven, where, you know, if you want to see if this ray intersects a sphere, here's the algorithm. And the algorithm, you know, uses a square root, and it does this and that. And if you're mathematically inclined, you'll recognize the quadratic theorem in there and things like that, but you don't have to be. And you can still create these things. and you'll be exposed to a lot of these concepts like find the inverse of a matrix which might seem very intimidating but i've tried really hard to present it in little bite-sized pieces and step through and you wind up wind up building this this whole thing from scratch it's pretty cool I was sitting here over my Christmas break and I'm like typing up some code

and you know, my wife's like, what are you working on? I'm like, Oh, I'm going to make these like 3d, uh, pictures or whatever. She's like, Oh, it looks like you're doing math. Well, I mean, I think that I'm actually writing a function to do the dot product of a matrix. So I think that that she i think you've tricked me i think it was all uh you've you've created a book about linear algebra or something yeah it really i think uh especially the first few chapters are probably the most intense that way

but i it's the kind of thing where i i do want people to kind of look back and feel tricked but in a good way to look back and go, oh my gosh, I just, just, you know, one little baby step at a time, instead of, you know, tie it back to what we were talking about at the beginning, instead of walking down that slope into a dark place of burnout, you're walking up this slope into this sunny place where you're like, look what I did without even, without even realizing where I was going kind of thing. Yeah. I hadn't heard this term before we started talking, recreational programming.

Is this a term you've coined? I don't think I've coined it. I'm sure I heard it somewhere. In fact, it seems like I've Googled the term before too, and there's stuff out there about it um i haven't found a lot of materials like especially published books about it though um and i'd like to see more i you know i hope i hope more people will uh see the value in exposing people to programming concepts in recreational contexts but what's what's the magic behind recreational programming?

Why do you think it's valuable? Let's say that. Well, for me, speaking for me personally, I think recreational programming has been a big part of helping me get over my burnout, to rediscover not only that I can still write software, but that I can still have fun doing it. And that's really my hope with these books is to help people see that, you know, maybe your job's not thrilling you right now,

or maybe you're pushing through a hard spot on a project, or maybe you're struggling with burnout too. But it's not the end. It's not like you're never going to be able to write software for fun again. That all it takes is, you know, a little bit of time and it's like going outside, right? Getting that breath of fresh air and remembering that there's a whole world out there and you're not stuck in this little domain where you are for, you know know eight or ten hours a day yeah i think you've really accomplished that job i think like for me as a professional developer

i really appreciate that i think that there must be also like some merit for like um like getting people into programming but in a more fun way. Yeah, with the Mazes one, I really wanted to do that. I wanted it to be very much a beginner-level book. The Ray Tracer one, I have to admit, is really targeted at people who have programming experience because it is test-driven. So you need to have a foundation in some programming language, and you should probably have some experience with writing unit tests as well.

So as much as I'd hoped to be able to target that one at beginners, that's probably not so much the case. But with the maze one, yeah, that was really one of my goals. Have you thought about taking this out on the road and like teaching people um like i was thinking about there's all these coding boot camps seem to be in vogue now and like but they're all very focused on like getting a job right so it's like learn how to whatever retrieve and pull things from a database and you know get a github account and make sure you have a portfolio of things you created but But like, what about just teaching people to do cool, fun things? You know,

like, I think that's, I think that would be a lot of fun. I don't know that I could support myself doing something like that yet. It was just as, you know, an important part of the decision, just given that my wife is currently in school right now. But I would love to see that. And part of me has hoped that eventually someone else might do that too, like using my books to teach a curriculum or something. I was able to speak at one of the classes. I live in the Logan, Utah area right now, which is where Utah State University is. And one of the computer professors there has invited me a couple of times to speak to his game programming class, which has been a lot of fun. I've been able to share some of the maze generation concepts in creative ways with them. And it's always been really fun to see their eyes

kind of light up as they hear these ideas for the first time and realize that, I mean, obviously they're in a game programming course, so they're expecting to write something fun and creative. So that's, that's a leg up for them right there. But yeah, it's, it's a lot of fun and I really do love teaching. I love presenting. So I don't know, maybe I will start looking for a way to take the show on the road, as you said. Yeah, well, I just, I found it to be a lot of fun. So, I imagine, like, myself being in a room with other people working through this would also be a lot of fun.

I think it would. I think there'd be really good energy in a group like that. Yeah. And the books are all, this is just an interview where I'm just like a fanboy the entire time. But the books are all color. Yeah. Like, how did you come up with that idea? Well, originally with the maze one, I mean, with the ray tracing one, it almost has to be color because that's the whole point. But with the maze one, originally it was going to be a black and white book. But then I had this idea for using Dijkstra's algorithm to visualize the structure of the mazes using shades of color.

And my editor, she was like, you know what, we need to propose a color book for this so that you can include these. Because originally I was using shades of gray so it would all be compatible. But it's just so much more spectacular in color, even though the book itself doesn't need to depend on color so much but so those those visualizations are a lot more spectacular in color i'm glad i'm glad it worked out to be in color because i think it's a lot better yeah yeah like it's not it's not like a glossy magazine but the places you use color it adds something is it maybe something that I didn't realize was missing in other books. One of the issues with the color is colorblind, you know, being sensitive to that. And I honestly, I don't know how friendly my books are to the colorblind.

So I have been a little concerned about that. But in general, I think adding color for visualizations really does add a richness to recognizing the patterns and the biases like we were talking about. Yeah, so I can provide you with some information here. So I am red, green, colorblind. Oh, okay. Yeah. How's the book for you then? So I think it's awesome. Like the,

the maze book, especially like, I think the way it uses color is not like a lot of colors combined. Okay. So, yeah, I know I found it great. And like the ray tracing,

the ray tracing book is beautiful. I don't think like, it's not like certain things turn on, like, you know, needing to identify if this is a shade of red or shade of green. Right. Yeah. Okay. Well, that's good to hear.

Thanks for setting my mind at ease a little bit there. Yeah, no, I think it's great. I feel like you must have some other domains in your back pocket. Like you're just, you're next, you're going to write one about, I don't even know. I've actually been asking myself that same question. Like right now at the end of this journey with the Ray Tracer book, I'm feeling pretty drained.

I'm working on a couple of bonus chapters that I'm publishing online. I've got one published online already, working on another one about bounding boxes as an optimization. So, I mean, I think those will keep me busy for a few more months. But I mean, like I've always been a thinker and I'm sure I've got some other things that can find a way to present. Part of me is kind of wants to rewrite the maze book in the same format as the ray tracer book with the test driven and pseudocode. But I don't know. I don't know if that'll happen or not we'll see yeah like my vote would be for another

domain because it's just fun to to explore these things and i don't know where to look for them but i mean maybe so what's your secret uh do you just like something catches your eye and you just go really deep on it and then it turns out yeah that's it exactly i i tend to get really compulsive about things like that oh what was it is It was probably 10 or 11 years ago. My wife brought home a little book about Cat's Cradle for our kids to play with, the string game that you play with a loop of string. And I got to wondering,

I wonder what other patterns you can make. And so I went online and discovered that there's a whole community and that there's an international string figure association. And I dove really deep on that. And it's kind of hard to write an algorithm book about. So I mean, things like that, I tend to get really obsessive and compulsive about that. Like really, something catches my eye and I'll go really deep on it and then uh so i don't know i have to i'm sure something else will come up i don't doubt that

i'll have another book idea eventually i can't give you a timeline though don't worry i'm not you're the the thing that's fun too um so um like a lot of times in in writing software i don't know a lot of things tend to be about sort of like uh just like modeling concepts like kind of you know breaking out concepts as like classes or data structures or or whatever um and um the implementation of your like at some level you, you end up with just kind of like raw data structures, I guess at some point I'm just, you know,

I'm throwing around a raw arrays or, or tuples or something. One of my goals really is for people in any, you know, with exposure in any, any environment, any programming language, any discipline, any, you know, with exposure in any environment, any programming language, any discipline,

any specialty to be able to come to these and find something that they can do. And, you know, that's one, like I said, one of my regrets with the Maze book is that it really, it does almost mandate a particular architecture in Ruby, but it's easily adaptable. But with the Ray Tracer one,

I've tried to leave it a lot more up to the reader as to how they're going to architect this. You know, the tests do dictate to some degree how that goes, but you're right. Like a lot of times I try and refer to just these raw data structures and then leave it up to you, the reader, to say, you know, this might be better encapsulated this way or combined with this other thing this way. Yeah, and the maze one, for instance, like, so I would say the way the maze is designed is, is like somewhat like object oriented, but I don't think that like,

I don't think the algorithms need to be, I was trying to envision this in my mind, how I would write it and maybe like a more functional or immutable style. I haven't really clicked onto what that would be, but the interesting thing about the problem domain, right? Is it, is it can be applied to different styles of programming.

Yeah, absolutely. And it makes me happy to hear that it's got you thinking because that's the goal, right? You don't close the book and that's the end of the story. It really needs to go on. And that's totally up to the reader to, you know, what ideas it sparks in their in their heads and and where they want to take it yeah so like myself um let's if i'm if i'm learning something new like a new piece of technology like obviously like hello world everybody does kind of like a world right um but then like what's after that i guess is something I think about. Right. And so like, I guess for me, like oftentimes it might be like some sort of like web scraper that like pulls some information from somewhere or, or some sort of like light web app or something.

Um, but like, I don't have too many ideas for what these are and I feel like you've given me some, like the, the maze generation generation or or a ray tracer is like one of these like it could be a project that you throw at something new uh to learn it yeah yeah in fact after i'd finished the ray tracer book and sent it off for the the first production phase i uh i sat down with oak camel which is a language I'd always wanted to learn and used my book to learn OCaml. And it was, I'm sure my implementation was wonky and weird to an experienced OCamlist, but, but it worked. Like I was able to write a ray tracer in OCaml using, using my book.

And that was a big validation for me because like you, like when you start in a new environment, a new language, new whatever, you kind of want something to dip your toes in and get a feel for how the language works. And that's definitely something I've hoped people would use these books for as well. So how, is this how you learn as as a programmer or how do you think people should

learn well i'm not gonna i'm not gonna claim i know how people should learn i know how i learn and i learn by doing like um i do not learn well from i'm gonna shoot myself in the foot here and say i don't learn well from books. On one hand, that's true. Like I don't think I would learn a new programming language from a book. I do learn techniques and like refactoring ideas and, you know, things like that, larger concepts. I do learn those well from books, but for a programming language, I have to do it.

And so I learn best by looking at other people's code, by reading through the API documentation, by referring often to Stack Overflow, and just sitting down and starting to build something. And yeah, mazes have been my go-to for a long time with a new language. Now perhaps a ray tracer. When I first learned Ruby, one of the first things I wrote was a simple HTTP web server. Just something to get your feet wet, you know. And so you think this is like is like a peculiar thing about yourself? No, I know there are other people that do it, but I also acknowledge that there are people who would say, I learn better by, you know, reading through a book and picking it out a piece at a time that

way. There's going to be a lot of different ways people approach it. But if you learn like me, then, you know then I think these books are going to be a fantastic way for you to pick up a new programming language, a new programming style, new techniques, new strategies. Yeah. When I got these books, I found mazes and ray tracers. They're like two problem domains that you can really go deep on.

And really, with a lot of code, you can kind of produce interesting results and have challenging outputs. Problems like this, they can be great. There's something bigger than Hello World, but manageable to play around with in a new language or in a new paradigm. And they're super fun.

So I found, like, I think that, like, as you described it, Burnout is real. And having some fun side projects that are kind of divorced from what you actually do day to day, it can be like very invigorating. So I thank you for that. Thank you. That warms my heart to hear because that truly is one of my life's goals, I think, is to help people remember what they found in computer programming originally. Whether it's to help prevent burnout or whether it's just to give them a respite from their day job or whether it's even to find some of these concepts that they can include in their day job. I don't know.

I really want people to remember what it was to be happy while writing software. That's great. That's a great mission. Thank you for coming on the podcast. And thank you for these books. Everybody should check them out. Thank you very much, Adam.

I've appreciated this. That was the show. I hope you enjoyed it. Adam. I appreciate it. Andy V in Canada. Great review. Thank you very much. Somebody, I'm just going to spell this, A-T-S-J-I in Norway. Great review. Thank you very much for the five stars. Cold Russian Wind. That's a great name. Thank you for the review. And everybody else, keep the reviews coming.

They help the rating, supposedly. I don't really know. And yeah, thank you also everybody who you know responded to things on twitter who gave me feedback about the show um who joined the slack channel by the way there's a slack channel please join it uh if you have any suggestions for the show let me know until next time see you later