Jorge: 0:00

it is critical for people who design anything to understand the capabilities and constraints of the systems that they're designing for. And for me, it hasn't even been a question about whether designers of software need to learn to code. I consider it essential. Like, it's, like, it's, it's not even a question.

Harry Max: 0:38

Hey, Jorge

Jorge: 0:40

It's good to see you

Harry Max: 0:42

Yeah, it's, it's always a pleasure. I'm glad we get to continue this conversation

Jorge: 0:46

Well, I'm hoping that we will talk about heady subjects. I-- We've had a couple of episodes where we've gotten into, like, capitalism and stuff, and I'm like, “Oh my gosh.” So I brought what I hope to be kinda lighter reading today.

Harry Max: 1:02

Oh, awesome. All right

Jorge: 1:03

But it's actually, I'm gonna say it's lighter reading, but I think it's an important subject. Without telling you what this is, I'm gonna say that this is a bit of text that is very important to me.

Harry Max: 1:19

Hmm

Jorge: 1:19

It is from one of the books that has most influenced my career, one that I read as a kid, and which I haven't revisited in many years, but the ideas in the book stayed with me. And this is one of the ones that I keep bringing up in conversation. I thought, “I'll bring it to the, the conversations with Harry.”

Harry Max: 1:40

I can't wait

Jorge: 1:42

All right Games must be designed, computers must be programmed. Both skills are rare and difficult to acquire, and their combination in one person is even more rare. For this reason, many people have attempted to form design teams consisting of a non-technical game designer and a non-artistic programmer. This system would work if either programming or game design were a straightforward process requiring little in the way of judicious trade-offs. The fact of the matter is that both programming and game design are desperately difficult activities demanding many painful choices. Teaming the two experts together is rather like handcuffing pole vaulter to a high jumper. The resulting disastrous performance is the inevitable result of their conflicting styles. More specifically, the designer-programmer team is bound to fail because the designer will ignorantly make unrealistic demands on the programmer while failing to recognize golden opportunities arising during the programming. For example, when I designed the game Energy Czar, an energy economic simulation game, I did not include an obviously desirable provision for recording the history of the player's actions. During the final stages of the game's development, virtually everyone associated with the project suggested such a feature. From technical experience, I knew that this feature would require an excessive amount of memory. A non-technical designer would have insisted upon the feature only to face the disaster of a program too big to fit into its allowed memory size. Another example comes from Eastern Front 1941. While writing the code for the calendar computations, I realized that a simple insertion would allow me to change color register values every month. I took advantage of this opportunity to change the color of the trees every month. The improvement in the game is small, but it cost me only twenty-four bytes to install, so it proved to be a cost-effective improvement. A non-technical game designer would never have noticed the opportunity. Neither would a non-artistic programmer.

Harry Max: 4:00

I am 100% certain I've not read this

Jorge: 4:03

I would be very surprised if you had. It's, first of all, it may be clear from the references to, memory limitations, and he even said, like, 24 bytes, right? It may be clear that we're talking about personal computing, uh, in, like, very early on in the history of personal computing, right? So this is a book called The Art of Computer Game Design by, I, by Chris Crawford.

Harry Max: 4:35

That's right

Jorge: 4:36

People who are listening to the podcast might not see this, but I'm holding up for Harry to see a copy of the book, which is inside a Ziploc bag, an ancient Ziploc bag, because this is my original copy, which I acquired shortly after this book came out. This book was published in, I believe it's 1984. Yeah, so the copyright is 1984, so the pages are yellowing. It's not, it's, you know, it's the kind of paper that degrades, and I wanna protect it. It's very precious to me, if for no other reason because it's inscribed to me by Chris Crawford. Uh, I had the great privilege of inviting him to speak at a conference where I was the program chair, and I told him, “This book changed my career, and I would love for you to inscribe it,” and he wrote,“Jorge, look where this got you.” Which is awesome, right? Uh, but anyway, th-this book changed the course of my career. It, um- I'll say this. I bought it not understanding what it was, and I read it, and then I reread it, and I must have reread this book maybe a dozen, maybe a couple dozen times. It's a short book. But it opened up to me a completely different understanding of design, computer programming, and games, something that I was very interested in as a kid. All three of those things I was interested in, but I was more interested in games and programming, and this book kind of opened me up to design as well. But I'll say I wanted to bring this particular piece here because he's talking about two things that are very important to me. One is the power of constraints and the fact that constraints are our friends, and that's something that I learned in architecture school. I think that when we start out, I think we naively understand constraints to be problems to solve, when in reality, constraints are opportunities to do things in different ways, in ways that might even be better. Um, so that's one thing. And the other thing is, what I took him to say here, and this is something that again, was formative for me, was it's very important for you to understand the constraints of the system you're working with if you want to have creative control over those constraints, and you can only get acquainted with the constraints of the system by going hands-on.

Harry Max: 7:50

Mm-hmm.

Jorge: 7:51

And he's talking there about craft. The relationship between craft and constraints is what I wanted to, to bring to the table here, because I think it's an underappreciated subject when talking about gaining traction

Harry Max: 8:06

Uh, I l- I mean, I don't even know where to start. I mean, let me just… I have so many different thoughts. The first thought I'll just share with you, the one that popped into my head, is that we could have a whole episode on, you know, what is the book that's changed the trajectory of your career, right? And I mean, just talking to people that we know, all of us have books like that, right? And, and in fact, weirdly, like when I'm interviewing people for some kind of role, often, you know, involved in the hiring process, usually for senior people, one of the questions I ask is-- one standard question is,“What book have you given away or recommended more than any other book?” Right?'Cause that really says something about the person. And, um, for me, that book is Finite and Infinite Games by James Carse, right? Which is very deeply related to the Crawford book, but in a more abstract, back to heady, maybe a book that we don't wanna get too much into the content of. But, I, I interacted with Chris back in 1987 when I was started writing my first-- my, my very first book, the book I really wanted to write, which was on information architecture. And it was just before, Information Architecture for the World Wide Web came out, I think. And I was, you know, trying to, you know, take all of my experiences at Virtual Vineyard/wine.com and the design and development of the shopping cart and moving people through information spaces, and I started scanning the literature of people who had written really potent things about wayfinding and game design, and stumbled not intelligent enough to have read his book, but intelligent enough to have found him and reached out and talked to him about stuff. So what a neat guy, too. Yeah.

Jorge: 10:03

Incredibly thoughtful

Harry Max: 10:05

yeah, really, really, just… One, one friend of mine says, “Just an incredible specimen of humanity,” you know?

Jorge: 10:13

Well, and to locate folks who might not have heard of Chris, was one of the original Atari game designers,

Harry Max: 10:21

Mm-hmm.

Jorge: 10:22

right? And we're talking for the original home computer, so not the 2600 console. I think that he was working, exclusively, if I'm not mistaken, with the 8-bit computers, the Atari 400 and 800. So, and I'm calling that out because, even though by today's standards those systems look incredibly limited, they were very powerful computers at the time, right? So the sort of games that he was talking about here, Energy Czar and Eastern Front 1941, would not have been possible on something like the Atari 2600. But even so, like, he had to deal with these constraints. And it feels like we should have an episode devoted solely to these kind of career-changing books. Finite and Infinite Games is one of mine as well, but to your point, it does feel really abstract. The, um… it’s a book, it’s a philosophical book, right? It’s a book on how to see the world. The reason why The Art of Computer Game Design had such an impact on me that I bought that book Because I wanted to learn how to learn how to make better computer games. I heard someone say once that, us, Gen Xers are the first generation that grew up with computers as playthings.

Harry Max: 11:49

Mm-hmm. Mm-hmm.

Jorge: 11:51

I got involved with computers very early on, and I got involved in computers because I loved video games, and I wanted to make video games. And I would go to computer stores and look to see what I could-- what information I could get. There was obviously no internet. What information I could get to help me make better computer games. And this book had, you know, the title of it, “The Art of Computer Game Design”, like it seemed-- I thought like, “Oh my gosh, this is what's gonna teach me how to make better sprites and, you know, my thing is going to be much more attractive and colorful,” because I had this naive understanding of art and design. And I started reading this book and I'm like, “Oh my gosh, there's no source code here. It’s only ideas.” And these were ideas that, um, that were about how to approach the craft of of designing computer games. And for him, as you heard in that passage, the craft of designing the game was intimately tied to the craft of programming the game. He saw them as one and the same, right?

Harry Max: 13:06

Mm-hmm.

Jorge: 13:07

A few years ago, I'm sure you remember, one of the incendiary topics among designers was whether designers needed to learn to code. I don't think that people talk about that much anymore. My position on day one has always been that it is critical for people who design anything to understand the capabilities and constraints of the systems that they're designing for. And for me, it hasn't even been a question about whether designers of software need to learn to code. I consider it essential. Like, it's, like, it's, it's not even a question. and it has and that has been informed by this book, and it's one of the reasons why I got so heavily involved with artificial intelligence when it became clear that that was where things were going because, this book implanted in me the idea that if you are to design anything, you have to have intimate knowledge of the material, and you only gain that knowledge by building things

Harry Max: 14:25

I'm so curious what your perspective on craft, design, and implementation is in this era of AI, generative AI, and the ability to build things by thinking about them where our constraint is our imagination now

Jorge: 14:41

Yeah, it's tricky. My takes on this are informed by the work that, uh… Well, one thread is the work that Jolie Forlizzi and her colleagues in Carnegie Mellon have done. They wrote a paper, I'll link in the show notes, where they talk a-a-about AI as a material of design and a tool for design. I'm not using the language right, there are, like, several ways in which it can be approached, So one of the curious things about AI, but I think it's also true of other computing technologies, design, and it is a tool of design. Having a material is not the same thing as having a tool, and in this case, the same thing can be both. So that's, that's a little tricky. But the other thing I will say is, if you think of AI as a tool to help create a new system, write software or design software or what have you. I see it as a tool as being part of the continuum from working with the kind of bare metal up higher levels of abstraction, right? So the first computer programmers had to literally flip switches to turn bits on and off.

Harry Max: 16:13

Mm-hmm. Mm-hmm.

Jorge: 16:15

Very quickly, people realized that you could layer on abstractions like assembly language and higher-level programming languages like C and interpreted languages. And then, you know, there are other abstractions that you layer on top. And when I'm working with something like Claude Code, it feels like the latest iteration in that stack of abstractions, where, like, now I'm not even dealing with the source code. I'm, you know, I'm interacting with a thing in English, right? Uh, and it is taking care of the source code in much the same way that you write source code in Swift or C or something like that, and then use a compiler to turn it into something that's closer to the metal.

Harry Max: 17:04

Yeah, I had a bun-- Did you know the, the term Atari is, is actually, the word Atari is a term of art in the game of Go?

Jorge: 17:12

Yeah, that's-- I think that that's why they named the company that, right?

Harry Max: 17:15

Yeah, I just learned about that. Uh, we have family in town, and one of our-- Craig, who's, uh, you know, in the extended network of family, is an expert. Like, like really, like he's like apparently one of the people that was involved in the making of, um, AlphaGo calls him to moderate games in Go or to witness games. I don't know exactly how that works, but I thought that was interesting, in bringing us all the way back around to… I-- Have you seen AlphaGo, the movie?

Jorge: 17:47

No, I have not

Harry Max: 17:48

Oh, it is totally worth watching. Like it-- There's-- Anybody, anybody listening to this should just go watch AlphaGo. It is totally amazing, and it came out a long time ago, but it was really about, that development effort and how it landed, and it's totally cool. Um, but it reminded me… This discussion reminded me of this concept, whereas English or our language, maybe not just English, but at least for us, English, as it relates to Claude and some of the other AI systems, is, you know, this l-l-- The-- Our, our spoken language has become the interpretive language that we're using to communicate with the computers now, and it reminds me of something my friend Dan French. He's a rhetorician. He has a PhD in rhetoric, of all things. It's crazy. He's also a, an award-winning stand-up comedian, based in Austin at this point. But he's-- he talks about language being the first prism, you know, where like a prism where you look through it and it breaks up into the different colors. And but, you know, I don't have the best hearing, and when he first mentioned it, I thought he said language is the first prison, you know?

And then he laughed, and he was like: 19:06

“Wow, I guess both things are true.” Because the abstraction layer or the interpretive layer that we're programming these systems now is the language that is both its constraint and limitation and also an infinite palette of opportunity to communicate what we imagine is possible in these systems today.

Jorge: 19:44

You know, before we go down the path, because I’m worried that

Harry Max: 19:54

And not get back to craft.

Jorge: 19:56

Well, craft and also I have in the back of my mind what does this mean for gaining traction? Because it might sound like I'm talking exclusively about developing or designing software,

Harry Max: 20:08

Mm-hmm.

Jorge: 20:09

And I'm not. Because for me, I took the lesson from this book, this particular… And I have that image of these two athletes in different disciplines handcuffed to each other. It's such a powerful image in my mind. And I think that that applies this notion that you should really get hands-on with whatever field you're acting on. It's something that I've taken to heart whatever I'm doing, and I don't remember which CEO it was would do things like rotate through the call center, like receiving support calls. I'm a big fan of that kind of thing

Harry Max: 20:53

Totally

Jorge: 20:53

where it's like you're, okay, you're going to be making decisions about how this organization is structured. Maybe you're going to be making decisions about how the service is going to be provisioned. Um, it behooves you to really get close to the ground to understand really what is going on. You know who is great at this? Walt Disney.

Harry Max: 21:16

Mm-hmm.

Jorge: 21:17

When they designed Disneyland, he, they-- After that park was opened, he didn't stay in his office in Burbank and issue commands from there. Like, he walked the park, right? And he would note where people were queuing, where they were getting hot, where people were dumping, I don't know, I'm making stuff up, but like popcorn boxes or what have you, right? And he would direct the shape of the environment through what he was observing on the ground and, you know, and was very close to the construction of that thing. And I think that the quality of our decisions is different if we're acting at a very abstract or removed place from where the decisions are enacted. Uh, I think it's very important to be very close to the action. That doesn't mean don't delegate and do all the stuff yourself because you obviously cannot do that. I think you should be very careful to not detach yourself from the reality on the ground. That's the lesson that I took from this chapter of that book. And, and it's 100% spot on, right? I mean, the reason that I'm a player coach as an executive coach, and I really work in product design, development, IT, you know, security. I work in all these areas, not in finance typically, not in marketing and sales, right? And by player, it is to actually get hands-on and to be involved in the conversations, the decisions, the activities, the commitments, and dealing with the implications of all of that. Because going in and standing outside of it, arms folded and telling people what to do doesn't work well. It, it certainly-- At best, it works slowly, and at worst, it makes a m- a m- it mucks things up, right? And the way to be good is to really be hands-on, but not necessarily be so hands-on that you're trying to do everything all at once all the time Yeah, that's the delegation thing. And it's something, frankly, if, if I were to call out like the dark side of this, I think that I've had trouble in my career delegating stuff because I have this attachment to understanding. I, frankly, I also get joy out of, like, learning new things And, and doing things. Um, but it is a potential risk, right? That, uh, to your point, you want to have that hands-on understanding about the areas that you're going to be deciding on, but you also don't want to take on the work yourself. And I'm wondering, again, with the spirit of slapping snow chains on it, you are a player-coach. Do you have any suggestions for me on how one might strike that balance? How I might strike that balance?

Harry Max: 24:37

Well, I'm gonna, I'm gonna lean on a saying that I picked up along the way. Rather than trying to talk about delegation, there are lots of different ways of, you know, Michael Hyatt, and there are lots of people who have good models for delegation. But the saying that I learned was, “Being clear is kind. Being unclear is unkind.” And the job of the leader is to be clear. And there are tools for being more clear versus less clear. Precision questioning and answering from Dennis Matthies’ work. The desired outcome model, which is documented in my book from the field of neuro-linguistic programming. The work that Scott Selhorst is doing on problem definition and problem framing. There are ways of increasing the fidelity of what you're communicating to be more clear with people and more on the nose, as they say in the movie industry, and less vague or ambiguous or, you know, hand-wavy. Being clear is kind. Being unclear is unkind

Jorge: 25:55

And now that you've brought up communication, I'll say one of the tricky things about this is that you don't want to-- When you communicate with your team members, you don't want to step on their toes, right? Like, uh, one of the risks of understanding of the craft is that you can end up, like, over-managing or micromanaging. Um, you don't want to do that. But also, if you do understand the minutiae of the systems that you're talking about, you can talk much more credibly with your team members

Harry Max: 26:30

That's right

Jorge: 26:31

They'll realize that you're not, you know, you're, you're saying the things that you're saying because you understand the system. So, uh, that's something to aspire to. Anyway, I was very excited to bring this to you. It's a special book for me

Harry Max: 26:45

I love it. I'm actually gonna go dig up-- I'm, I'm sure they're still available new. I'm probably gonna go get myself a copy just to have it on my shelf to take a look at

Jorge: 26:52

Yeah, if, uh, do get it as in physical format. I bought it as a Kindle e-book a few years ago, but the formatting is not very good on Kindle.

Harry Max: 27:00

Okay

Jorge: 27:01

So if you find it as a physical book, snatch it up. It's really great. I mean, the references have aged obviously, but I think the principles stand

Harry Max: 27:11

All right, man. It was really, really great to see you. Thank you so much for bringing Chris Crawford back into my life

Jorge: 27:16

Awesome catching up as always