Welcome! Thank you for taking the time to talk with us! Please introduce yourself so everyone else knows who you are as well.

Sure. I’m Jamis Buck. I wrote Mazes for Programmers (Mazes for Programmers: Code Your Own Twisty Little Passages by Jamis Buck) and The Ray Tracer Challenge (The Ray Tracer Challenge: A Test-Driven Guide to Your First 3D Renderer by Jamis Buck). I currently work for Basecamp as a software developer using Ruby on Rails.

Tell us how you chose these topics and what went into developing the books.

I wrote Mazes for Programmers around 2015. I had been suffering from burnout at work about that time, and had to walk away from my dream job in order to reset. I took a full year off from work to try and figure out where my passions were and what I was, what excited me.

As I was taking that time off, I did some writing, and I wrote a little quirky online novella about a fictional character, a wizard named Basil, and his manservant Fabian, who went on an adventure that involved path finding algorithms. It was really different and got my mind turned back towards programming again, which was exciting. As part of that, I remembered back in high school being introduced to maze algorithms by an exchange student from Italy, who introduced me to a way to generate random mazes. It was really interesting and exciting, and it really sparked my imagination.

In 2009 and 2010 I wrote a series of blog posts about maze algorithms that were surprisingly well received, and at one point someone was like, “You should write a book about those.” I laughed it off, but after writing this little novella online, my mind turned back to those maze algorithms. I realized maybe, maybe, there is a book in me, maybe there is something there.

So I went looking to see how you even find a publisher. I’ve always admired Pragmatic and what they do and how they do it, and so that was one of the first places I looked. I found the “How to Be an Author” page, and I wrote up my proposal, and the rest is history on that one. It came together pretty quick in about nine months, I think.

What surprises me about the Mazes book is how much people responded to it on an emotional level.

(laughs) Yeah. I’ve really been very pleasantly surprised by how well that book was received. I knew going into it that by doing all the code examples in Ruby, there would be some pushback. And there have been people who have criticized the book because the examples are all in Ruby. But invariably, for every criticism of the book that it’s in Ruby, there’s a handful of people that come back and talk about how Ruby wouldn’t have been their first choice either, but it’s surprisingly readable or they had no trouble translating the examples to the language of their choice, or whatever it is. The recreation aspect of that book, the idea of generating mazes, not because it has any practical example for their current job or anything, but just because it’s fun, that idea really resonates with people, I think.

One of the readers called it a book of nerdy algorithms.

(laughs) Yeah. I love that.

Others talked about rediscovering the joy of their work.

Mm-hmm (affirmative).

Of their coding work. And why do you think that people responded in that way?

I think for me personally, coming from a place of burnout and mental exhaustion, I think I really tried to imbue the book with that sense of discovery that mazes instilled in me. These algorithms and the playful nature of them are what really helped me rediscover programming after my burnout. I really tried to put that into the book, and I think it came across.

I think that a lot of what people are responding to is the playfulness of the algorithms, and how easily you can explore and vary what I present, to find all sorts of different domains. People have, of course, done online maze generators, but I’ve been contacted by people who have made iPhone apps, iPhone games using these algorithms, people who have just really gone different directions than I ever imagined with them. It does my heart good to see that people have made it their own, and found the joy that I hoped they would find in them.

You mentioned the playful nature of algorithms. In today’s development jobs, I see people working really hard in production, and a lot of them almost become JIRA-turnover-automatons .

Yeah.

Where you get a ticket, you resolve the ticket, you get a ticket, you resolve the ticket. How have you found that just production jobs have stripped away some of that playfulness and joy that brought people into programming?

First of all, I wanna make it clear that I don’t think there’s anything wrong with having a job where you’re churning through tickets. There’s a place for that. But as you’ve noted, there’s a danger in the mindless nature of it. I shouldn’t say “mindless,” because where you’re troubleshooting and trying to solve problems and resolve a ticket, there’s a creative aspect to that. Like anytime you’re trying to find a bug, it requires the creative side of your brain to kick in some. So it’s not truly robotic in that sense, but the same thing over and over.

When I burned out, I likened it to a repetitive stress injury of the brain—of the mind—and it wasn’t even necessarily due to the nature of the job. Like I said, mine was my dream job. I loved working at Basecamp, and I’m so glad that I finally found my way back there again.

But burnout happens for lots of reasons. In my case, it happened because there was a trauma, almost an injury, like mentally, that kind of festered. And I tried to push through it and I tried to get over it and I just couldn’t, and it got worse and worse until finally I had to take drastic steps and leave my job. There’s lots of other reasons for burnout, but I feel like doing the same thing over and over can lead to the kind of repetitive stress, mentally and professionally, which, you know, can burn people out and lead them away from a job that they maybe used to love. And I think that’s why—not that everyone should program on the side—it’s important to have some kind of outlet where you can remember what brought you to the profession in the first place.

For me, in the beginning, it was the magic of being able to tell a computer to do a thing and having it do that. It really made me feel like a wizard, (laughs) right? Like having some magical power. And, you know, here twenty-five plus years later, I don’t know that I’d say I feel like a wizard anymore when I’m writing software, but it’s good to remember that and to go back and find something that feels just a little bit magical. And I guess the mazes were that way for me. I don’t know if it’ll be that way for everyone, but I think it’s important that people find something that can remind them of what brought them to the career in the first place.

So how did you discover programming?

I was a junior in high school, and my mom got a Tandy computer, and I remembered vague experiences from elementary school where we were doing turtle graphics in BASIC on Apple IIs. And I found the manual for GW-BASIC that came with my mom’s computer and just started dabbling and realized this was something that really fascinated me. And so I took a “computer science” class in high school. I use that phrase very, very loosely because it was really just word processing, but I was able to convince the teacher to give me free rein, kinda let me design my own curriculum. And just every project I completed, everything I learned, pointed me more and more in this direction. This is the direction I want to take my life, and this is what I want to do. And yeah, it’s been a bumpy ride at times. It hasn’t all been roses, and I haven’t always been as enthusiastic about it as I was at the beginning. But it’s definitely treated me well.

So how do you avoid repetitive stress injuries to your mind, and how do you warm up and keep your brain limber and ready to work?

I think the biggest takeaway from my own burnout is to recognize that there is life outside of the computer. Prior to about 2015, I did a lot on the computer. A lot of my interests were related to programming and software development. I did a lot of other things too. I learned how to make chainmail. I did wood carving, different things like that, book binding, but I do a lot less on the computer now than I did before. I think it has been healthy for me. Obviously it’s still important for my career, for my job, for supporting my family, that I spend time on the computer. But as far as keeping limber and warming up, I think the most important thing for me has just been balance. Recognizing that it’s okay to turn off the computer and be unavailable when I don’t need to be available.

Even while staying away from computers, I think it’s healthy for me to be aware of what other people are working on. I don’t follow a lot of people on Twitter, but some of the ones I do are doing generative programming, or writing procedural algorithms, or I don’t know, basically just using software and algorithms to do things that I wouldn’t have thought of before. Even if I don’t learn how to do that myself, being aware that people can do these things kind of opens my eyes and keeps me looking in new directions, which I think has been important for me.

What advice would you give someone just starting out in terms of finding that work/life balance and that existence away from the keyboard?

When you’re first starting out, that’s probably the hardest time to find the balance because you’re so excited about what you’re learning. When I was first hired for my first full-time job as a programmer, I remember taking the software home that we were using to write the programs we were doing. I remember taking it home and installing it on my personal computer, with their permission, so that I could experiment and play with it. When I was first hired by 37signals, now Basecamp, I remember just wanting to breathe in everything we were doing, constantly. It was hard, especially working from home. It was really difficult to draw a line and say, “Now I’m going to not do work.” Because it all just felt like my hobby and my passion. So I get it. When you’re new, when you’re just starting out, everything is exciting and you just want to drink it all in.

There’s a place for that. But I think it’s important that you be intentional about it, recognize that you’re doing it and maybe intentionally try to budget some other things in as well. Go for walks, read a book, watch a movie, do something that takes you away from that flame that’s so fascinating to you. Just for a little bit. But, like I said, stay intentional about it. Be aware of what it’s doing to you, because every moment you spend doing that, as exciting and passionate as it is, is a moment that you can’t spend doing something else. Be aware of that trade off, that would be my advice.

Tell us about the ray tracing part of things or how did that happen?

Okay. I was in college, so this was me not having very good balance, but you know, everything related to software was fascinating to me. And I had discovered a ray tracing package called POV-Ray, which many may be familiar with. It’s been around a long time, it’s a pretty neat little package, a lot of fun to play with. But what fascinated me was more than just making pretty pictures. It was understanding how it worked. And so, because it was all open source, I was able to crack open the lid and look inside and play around with it, which is kind of a theme for me. You look at the Mazes book and the exercises in there, how much they are all about, “Okay, you learn how to do this. Now, what happens if you change it like this? Or what if you do this variation?” Same sort of thing—looking in the source code for POV-Ray, learning how the ray tracing algorithm worked and how this package worked its magic was a lot of fun, like digging in and experimenting. And I learned a lot about how ray tracing works by looking through POV-Ray.

Now fast forward. I had finished the Mazes book. It’d been a couple of years, and I’d kind of been thinking, “I might like to write another book, but I don’t know what I would write it about.” And at that time, my oldest son—he was probably 14 or 15 at the time—asked me, “Dad, would you teach me how to write software? How to program a computer?” And I mean, that’s huge. Where do you even start? And so I thought about it and I was like, “Maybe we could write a ray tracer together.” So I outlined it first to get an idea of how to present it. And then he and I sat down, and we started writing a ray tracer in Ruby. And as I worked through this and polished off that outline, I realized, “You know what? Here’s an outline. I’ve been wanting to write a book. Maybe I could write a book about ray tracing.” And, as I thought about it, I tried to figure out what angle I would take, and how to present that. It all just fell into place, and I submitted another proposal, and it was accepted.

How do you compare the creative process of coding versus the creative process of writing?

That’s a really fascinating question. I’m fascinated by both coding and by writing. Ever since I was a kid, I’ve always wanted to be an author, and I never imagined myself writing a non-fiction book. I always wanted to write science fiction or fantasy, and ironically, I’ve never really published any science fiction or fantasy, but now I have done non-fiction. So this last year, I set myself a challenge. I wanted to write a thousand words every day for a hundred days. And I did really well at it, up until I realized there was going to be an obstacle right at the end, like at the very end of my hundred days, that was going to ruin my streak and I wasn’t gonna be able to finish a hundred days. It totally killed my momentum, but I got through about seventy or more days in a row, writing a thousand or more words a day.

When I’m writing that regularly, I’m not worrying about quality, I’m just worrying about quantity with that challenge. It becomes kind of a mechanical thing, and you start to discover, “Okay, I wanna write a story in a thousand words in an hour and a half.” And I got to where I could sit down, and within the first couple of sentences have the kernel of an idea of where I wanted to go, and then the rest would just come out. And I feel like it’s the same way with writing software. At first, the possibilities are daunting. Like you’re looking at a blank page. Whether you’re trying to write a program or you’re trying to write a story, it’s the same fundamental block that you feel. and either way, whether you’re doing software or you’re writing fiction or nonfiction or whatever it is, the solution is always to put something on that blank page. And to accept that it’s going to be garbage. You are not going to get a hole in one. Statistically, it’s just not going to happen.

But if you wait until you have a hole in one before you write anything, you’re going to write nothing. So you have to give yourself permission to write garbage and acknowledge that. “I’m not going to show this to anyone, I’m just going to start writing something.” And then once you can get past that, I feel like the rest of the process, it’s self-constraining, right? When you’re looking at that blank page, there’s an infinite number of directions you can go. The moment you write one word or one command on that blank sheet, you’ve constrained the realm of possibilities significantly. And so your brain is no longer so overwhelmed. You’ve directed it in a direction. And so then you put another word down and then another word and each word constrains that universe of possibilities a little bit more. I think that’s the key for both writing software and for writing in general: to just constrain yourself by giving yourself permission to write garbage and just starting to put things in place.

How do you make software beautiful?

That’s an interesting question. Beauty is in the eye of the beholder, right? Personally, I cannot stand Python.

(laughs)

I can’t stand to look at Python code. It just offends my personal sense of aesthetics, but there are a lot of people who feel that Python is beautiful and expressive. And I will not deny that it is a powerful language that a lot of powerful things can be expressed in it. These people who think that Python is beautiful, believe that it is beautiful, they are not wrong. Right? And I am not wrong in believing that Python is ugly as sin. So how do you reconcile that, right? How do you reconcile that we can both be right and yet completely contradictory? And I think that is part of what makes beauty beautiful. It is recognizing that someone else can believe differently and still be right.

So for me, what makes code beautiful? First of all, I love something that doesn’t use significant white space, (laughs) but again, that’s me. I love code that is refactored nicely into small pieces. I like code that describes itself. I like explicit blocks, so that’s why Ruby appeals to me. I love explicit “begin” and “end.” Like, there’s something about having both of those together that speaks to me.

Other people hate that. And that’s why a language like Python appeals to them more where you have the implicit block, open, close, based on indentation.

I’ve always loved C. Probably, partially because of the curly braces and how they explicitly delimit blocks of code as well.

I don’t like code that is too clever. I hate it when people use two exclamation marks in Ruby to convert a value to a Boolean. I know why they do it. I know exactly what that does in the code, but it’s the kind of idiom that I find ugly. Others don’t, and that’s okay. But it’s not an idiom that I would use myself. I don’t know.

Trying to explain why you think one thing is beautiful versus another, that’s a topic for an essay, I think. And I don’t have a good off-the-cuff answer for that, but maybe I’ve touched on it a little bit.

What about mazes? (laughs) What makes mazes beautiful?

Well, that’s another interesting one. There’s a lot of different levels to answer that one. The most superficial: What makes the maze visually appealing? I personally like long, winding passages. With mazes where there’s a bunch of short passages and lots of dead ends, it feels “prickly” to me. I guess that’s a way to describe it, when I see those kinds of mazes. I mean, beyond that, like having spent a lot of time generating mazes, I can kind of get a feel for which kind of algorithm was used based on the look of the maze. I’m not always right. There are a lot of algorithms, and some of them are pretty similar and overlap in different ways, but knowing which algorithms I prefer, and knowing how I would implement those algorithms can also affect the way I perceive a maze. Which is kind of fascinating to express that just now; I hadn’t considered that before.

But, to me, I think if someone were to say, “You know, I made this maze using Aldous-Broder,” or whatever, that would probably affect my perception of the maze versus if they said they came at it with the Growing Tree algorithm or Recursive Backtracker or something. And then some algorithms too, like the recursive subdivision algorithm, which allow you to add a lot of visual interest by adjusting how deeply the recursion goes or, or even just with a regular maze like, changing the sparseness of it. These can add a lot of beauty as well, I think, by just changing the expectations that you have when you look at a maze.

How can people best follow you and what you’re up to?

I’m @jamis on Twitter. That’s probably a good place to start. I don’t have a lot of other social media presence.

Do you have any ongoing projects or appearances or anything that you think readers would be interested in?

Not right now, sadly. The pandemic has definitely put a damper on all of my conference attending, and I’ve really fallen out of the habit of looking for opportunities to present. I do need to get back into that, though. I always found it invigorating to talk about some of these things.

Great questions! But I’m not much of a futurologist, I’m afraid. I know where my own interests lie, and what I’d like to dig deeper into (procedurally-driven world-building and story-telling) but if I could guess what would be hot or interesting to a large number of people, I’d already be writing a book about it!

As for Ruby itself, I’d love to see how it might become more appealing to data scientists and machine learning researchers. Python fills that niche very, very capably, but as I mentioned in the interview, it’s not my favorite language. My previous job was writing machine learning algorithms in JavaScript, but I would have been over the moon if Ruby had been a serious option!

That was great! Thank you, Jamis.

Complete your collection of Jamis’ PragProg titles today! Don’t forget you can get 35% off with the coupon code devtalk.com!