Logo

Software Developers Journey Podcast

#262 Chris Zimmerman and his story of the Sucker Punch game studio

Resources

Highlights

[05:16] Starting the Programming Journey

Chris Zimmerman began programming at a young age, starting with the Apple II. From his first programming experience, he learned the importance of **understanding how things work and debugging issues**. His first major project was a game, which he released to a community of Apple II users. His advice to junior developers: **start with small projects and gradually build your skills**.

[14:08] Working on Word Processors

Chris talked about his work at Microsoft before the gaming industry. He mentioned the importance of **developing a problem-solving mindset**. Despite the difference in the industries, he found many similarities in the way problems are approached and solved. He suggests that junior developers should **embrace challenges as opportunities for growth**.

[20:54] Transitioning to the Gaming Industry

Chris discussed his transition to the gaming industry, founding Sucker Punch Productions. The team initially mapped Microsoft practices and culture to Sucker Punch. His experience showed that **adaptability and the ability to learn new things are crucial** in software development, especially when moving between industries.

[27:35] Building Infamous

Chris emphasized that **the collaboration between story writers and developers is vital**. He suggests that junior developers should also **learn how to work effectively with other teams** and understand the interconnection between different aspects of a project.

[32:20] Developing Ghost of Tsushima

For Ghost of Tsushima, Chris pointed out the significance of **combining technical skills with creativity**. Building a game is not just about programming; it also requires creative storytelling. He encourages junior developers to **cultivate their creativity alongside their technical skills**.

[38:10] Importance of Iteration

Chris stressed the **importance of iteration in game development**. He explains that it's rare to get things right in the first try. Hence, he encourages junior developers to **embrace the process of iteration and continual improvement**.

[44:25] Making the Player's Experience First Priority

Chris emphasizes that game development is all about the player's experience. A feature might be technically impressive, but if it doesn't add value to the player's experience, it's not worth it. He advises developers to always **keep the end-user's experience in mind** when developing software.

[54:05] Responsibility and Being a Self-Starter

Chris insists that programmers need to take responsibility for their code. If something doesn't work, it's your fault. Furthermore, he values self-starters in his team and encourages aspiring developers to **start making their own games and projects**. As a junior developer, the initiative to create and complete projects will not only enhance your skills but also increase your employability.

Enjoyed the Podcast?

If you did, make sure to subscribe and share it with your friends!

Post a review and share it! If you enjoyed tuning in, leave us a review. You can also share this podcast with your friends and family and share lessons on software development.

Become a supporter of the show. Head over to Patreon or on Buzzsprout.

Got any questions? You can connect with me, Timothée (Tim) Bourguignon, on LinkedIn, per email, or via my homepage.

Thank you for tuning in!

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Chris Zimmerman 0:00
Here's the thing that I think is awesome. When I see it on a resume, it's when someone decided that something should happen. And they went and did it. Right. So it's like, I made this game. And I published it on Steam. And yeah, I've sold 75 copies, it doesn't matter, right? The thing that matters is they actually did it, they actually decided something was going to need to happen. They went and did it. They made it happen. They push it all the way through. And they're they're done. Right? I think that is super cool. And so if I ever see that on a resume, and by the way, I'm not in charge of evaluating resumes at this point. So it was nice isn't very useful. If I ever see that on a resume, I'm like, Okay, that's a person that I absolutely will talk to you because they're going to make stuff happen. And that's what we want to have at sucker punch. We want people who are going to see that something the game would be better if this if something happened like petting a fox, and they'll just go do it, because that's how our games get great.

Tim Bourguignon 0:54
Hello, and welcome to developer's journey, the podcast, bringing you the making of stories of successful software developers to help you on your upcoming journey. I'm your host team building you own this episode with receive Chris Zimmerman, Chris learned to program in the late 80s and early, late 70s and early 80s. Dan wasn't born and thought he was a hotshot programmer. But fast forward a few years he graduated from Princeton, started to work in Microsoft got to work on fun stuff right away. And His word was put in charge of a team way too early. But fast forward even more years, he co created the gaming studios sucker punch, a video game development company that created games you might have played, for instance, the famous franchise, and the recently ghost of Tsushima. And 26 years later, he's still there in the studio, as with a new title now studio head Emeritus, working part time there and writing books. I am thrilled to have you on the show. Chris, welcome to the afternoon. Thanks, Tim

Chris Zimmerman 1:59
said it's good to be here. I can't believe that it took me 40 years to go through that journey, and you encapsulate it so, so definitely 30 seconds. So

Tim Bourguignon 2:09
because it's you, I'm gonna give you 45 minutes to talk about it.

Chris Zimmerman 2:13
Yeah, it's gonna be the same thing just in more detail. So.

Tim Bourguignon 2:17
And we're all about the details here. You know, that's, that's right. But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the dev journey lights up. If you would like to join this fine crew, and help me spend more time on finding phenomenal guests, then editing audio tracks, please go to our website, Dev journey dot info, and click only support me on Patreon button. Even the smallest contributions are giant steps toward a sustainable dev journey. journey. Thank you. And now back to today's guest. So first things first, as you know, the show exists to help listeners understand what used to really look like and imagine how to shape their own future. So let's go back to your beginnings. Where would you place the start of your journey?

Chris Zimmerman 3:09
Oh, gosh, like mid 70s. I'm like 11 or 12. This is about when personal computers were invented. My dad was a chemistry professor. And he had computers in his lab as part of as part of the work he was doing. So I kind of knew they existed. But then he got an apple two as part of the equipment for his lab. And I was allowed to program it at about the time when I was capable of learning how to program. And so I did I taught myself how to program and basic, build a bunch of stuff. Did some did some game programming dad night together built some chemistry educational software that we sold, which was kind of fun. Wow. And that was kind of my intro to computing. i It was it was so long ago I you know, it's it's still the same in some ways, right? But it was so different. It was the 1970s Right? People asked me like, What was your first video game experience? I was like, No, you don't understand. There were no video games. When I was your age. They did not exist yet. Like I remember them being invented. That's how long ago it was. So I you know I did. I did learn how to program by making video games for myself. I was, you know, I'm like a teenager and Indiana in the 70s. I don't have any money at all right? So it's not like even though you could buy games for the Apple two, I didn't have enough money to buy games like now 40 bucks. Are you kidding? So I had to make them for myself to play. It also wasn't quite like a frontier child braiding a doll out of a corner. I did have to make my own games to play. And that's kind of how I learned to program which was I was a fun way to learn how to program right? So it's immediate feedback, right? You type something in and it happens right away. It was very rewarding in that way. And then you had something fun to play. It was it was good time.

Tim Bourguignon 5:00
So you got hooked enough to really go through the moves and really go all the way to creating the game and being able to play it.

Chris Zimmerman 5:08
Oh, absolutely, absolutely. In fact, we got, I we like I almost got to the point wasn't quite good enough, as a programmer as a game creator at that point to make something that was commercially viable. Up close, I had one. At one point, I was like, oh, I want to do that. And I didn't make a game, it was called snow bunny was the name of this game all 6502 assembler kind of like a 2d for our like a Frogger with things going in multiple directions. So I would very dated reference to father, because if everyone knows what Frogger is, like, if it was like a, like Frogger, but everything was going in all directions. It wasn't quite good enough to sell. But it wasn't, it wasn't embarrassing, but it wasn't quite good enough to sell. And after that, it was like, I you know, I'm 17 or 18. There are other things going on in my life like girls and sports and cars. And so I did not have the focus to actually make a video game for the next few years. I was busy with other things.

Tim Bourguignon 6:13
And I totally understand. But but you kept the the it vibe,

Chris Zimmerman 6:18
didn't you? That I'm sorry to say again,

Tim Bourguignon 6:21
you kept this this development and it vibing Oh, yeah,

Chris Zimmerman 6:25
absolutely. Yeah. Which was, you know, it was it was, I was lucky in that I knew what I really liked doing. I really did like computers. I liked programming. That was great. I can't really understand why people don't like it. So when I went to college, I knew what I wanted to study, I flirted with doing other things, too. But I didn't really come close to doing anything other than majoring in computer science, getting a learning how to program and then leaving school knowing that I was going to be doing something I love for the rest of my life. It's pretty nice, pretty nice. waited, I didn't go through this sort of like crisis of confidence during college when like, oh my god, what am I going to do? I knew I was gonna do it's kind of played out like I thought it would so. So that worked out all right.

Tim Bourguignon 7:12
Yeah, good. Good for you. Did you still have this this gaming idea?

Chris Zimmerman 7:16
Yeah. Kinda, but not really. I don't, you know, during college, I did some like gamey type stuff. And I really again, I was busy with other things. And then I did get a degree in computer science. And I started interviewing with companies, and none of them were GameCube. Zero, it wasn't a games business in the way there is now. And there were video games at that point, the 80s. But it wasn't a big business like it is now. And so was it like a career option, you didn't think of it as a career option, maybe it was, obviously it was for some people, but I didn't perceive it as such. So I entered with traditional companies, Apple, Microsoft, at&t. And I ended up taking a job at Microsoft, which ended up being a great decision. And working on non game stuff. For the next nine years, you know, off and on, I dabbled in doing something. But it really wasn't games, there's more about programming and about than about games. In, we eventually did get tired of Microsoft, retired my role at Microsoft, and decided with some friends that we wanted to do something different. And decided that, you know, from a practical standpoint, it was more plausible that we could make a successful company making video games than a lot of other things. And so that's what we ended up doing. And it's sort of weird to have someone say that making video games was like applause The most plausible thing I could think of to do, but you to us it the shape of the industry kind of matched what we thought we could do. As a group, we kind of knew about product design, we knew how to design software, we knew how to build software, when you how to run teams, well we didn't really know is how to run a business. And, you know, talking to customers and accounts receivable, and all this stuff's like we really didn't know any of that stuff. And at that point, that video game business was kind of built around a constellation of small independent companies making games, and a separate ecosystem of companies, publishers who would take those games and then sell them to people. And this seemed great to us, right? We're like, Okay, this, this lets us build a company that's focused entirely on product development. All the real business happens in somebody else's company. We just get paid to make product and we know how to do that. So let's do that. And is it still the same as things have changed, you know, 25 years, but at the at that point, it really was a practical idea of what we can do. It also happened to be fun and let us all get back to our roots because all of us had made games and played games and He was trying to get back to that.

Tim Bourguignon 10:03
That's very, I'm not sure what the word is. Forward Thinking, clear for youngest is the word I have in mind. But I'm not sure if it's if there's an equivalent in English, or what the equivalent in English is, is really thinking of what are our strengths right now? And how can we put all threads really in perspective and see where were we missing something? And, and which plays in industry is matching the exact constellation we have? Yes, really analyze this, in those terms back then, or you retrospectively telling you,

Chris Zimmerman 10:38
maybe it's hard to know that I think actually we did. And there are some decisions that we were very explicit about at the time that were kind of like that, where we thought we tried to think pretty objectively about where we were, and how we might succeed, because we were coming into the games industry without a lot of recent games experience. And that was a disadvantage, obviously, you know, that's not typically the way games companies start. The wave games companies still start now typically what happens is, it's like, game game companies start by subdivision. So what happens, somebody will be working at a game company, and they will be having a great time doing it, but they will get mad about something. And they will have another person around them that they're friends with that is also mad about the same thing. And then it'll be something dumb. It's like, I can't believe we put a ponytail on that character, right? So and we'll decide, forget this, we're going to do it ourselves. And it's going to be great, right? And two people from one company will kind of spawn off go off on their own, and they'll grow a company around themselves. This is the traditional way to start a games company. And we didn't do that, because we weren't coming from the games business. And the people we hired, were generally people that were veterans of the games business, but the founders weren't, you know, we had a lot of big company software development experience, which was useful. And we thought of it as useful, right? I think one of the things we thought, and we were really, you know, honestly, Tim, I'm not making this up. We were actually super analytic about it. Now that I'm thinking about it. We were like, Okay, well, here's our strengths. We actually know how to build big software projects, we know how to organize and run a team that's working for, you know, months to years on something, and not have it all fall apart. The games industry at that point was really just coming out of its GarageBand phase where it's like two or three guys to slap and stuff together. Like games were made without Source Code Control, like nobody had any, like, I just talked to a friend that was working at a company, which shall remain nameless, that made a game that was very famous in the 90s. And they lost like three months of the team's work, because when their hard disks crash, honest to God, they didn't have source code control at all, they didn't have backups at all. It was just like sharing floppies or something. And they lost three months of the company time, because the hard disk broke. It's like, how can you how can you do that? But they did. We that was, you know, we kind of I didn't know this was had happened it had happened was when we started sucker punch, but I kind of got the sense that it was a little bit cowboy out there in the games business and having a more professional software development background was going to be helpful. And and it was it, you know, there are things that we completely missed. It's like, you know, here's the things we didn't know at the time, right? I mean, we didn't know, okay, we know how to run a big team, right? We know how to hire people. We know how to train people, plus or minus. But we didn't know what we didn't know, right? And the things we didn't know, or how different it was going to be to manage a team that was full of creatives rather than a technical people. Now, Microsoft, we would say, oh, yeah, those are creative people. I work with graphic designers at Microsoft, I work with writers at Microsoft. And that was, in fact true. However, those graphic designers and those writers, we are the most technical graphic designers on the planet and the most technical writers on the planet, right? So, yes, they were a graphic designer, but they were really a programmer who was also a graphic designer, writer, there really are programmer was actually also a writer. And so when you're talking to them, you were talking to reflection of yourself as a programmer, right? They felt the same way you did. And so when we had a company where it was people that weren't like that, that were traditional, you know, pencil and paper artists, they don't think like you do at all right, the things they think are important are completely different. The things they care about are completely different. The things that motivate them completely different, right? So we had to we first we had to even realize this was happening, right? Because you're you're zooming along expecting that everyone's on the same page, but they're not right, they're there. They're completely not I'm thinking about things the way you are. And it takes time to understand that time to wrap, the way you think about things, to the point where you even realize there's a problem, and then you have to figure out how to solve the problem. And that's a years like, honestly, it was like three or four years in before I really truly understood how little I understood about this completely valid mindset that everybody the company had, that I did not have, right, so and so like, it was like all the mundane stuff. It's like, you know, how do we do performance reviews? Do we do performance reviews? And if we do performance reviews, how do we do them, right? Like, you design that really differently. If you're, if you're talking to someone who's mostly about doing concept art for your team, then you do if you're talking to a programmer, you just programmed to think about those things differently. And it took a while for us to redesign. You know, a lot of the stuff we did originally, were just transplants of things we'd learned at Microsoft, because the other cofounders of the company, were also Microsoft alums. We just transplanted Microsoft culture into sucker punch and started growing from there. And some of that was entirely inappropriate. And we had to kind of realize that back out of it and start thinking about how to build a culture, grow a culture that was more appropriate for the people that were there, because, you know, programming is an important part of making video games, but it's, you know, a fifth of the people at Sucker Punch 20%. So you don't want that 20% driving your culture, right? You want the, the 60 or 70% of the people who are are not coming at it from a from a purely technical background. To drive in culture, that's the important part of the company. So so it was it took time to realize there was a problem. And then it took time to redesign our way of thinking about running the company to match that. So it so like, I'll give you a mundane example. So like Microsoft's review, annual review process at that point. First, it was biannual, you do twice a year, not not once a year, and it was numeric, like you got scores on stuff like and at the end, you had a score that was assigned to you. And we're like, oh, we'll do that. And it turns out, that was a really bad idea. Like introducing numbers into it for someone that's coming at it from a kind of subjective and emotional basis, completely valid, pretty reasonable way to think about things. Like, that's not, that's not good. It's like I don't want to be reduced to a number. This is reductive and unfair, and I'm disempowered and it's not good at all right. And so we had to redesign our review process around thinking of it more as a collaboration between you and your manager and thinking of it as a journey of personal growth that was driven by you. But this was kind of a you know, as steppin the story of your career, is checking in to help you drive yourself to be better at what you're doing. And, you know, all the documentation of the things we were doing had to get redesigned around that new focus that it was less about your manager judging you, and more about your manager as your kind of friend and confidant helping you through this process, because typically, they've been through it themselves. And that was a lot more effective. I mean, it's for, you know, it depends, like for people that were, they've only worked at sucker punch, and we have quite a few of those people where we hired them at 22. And they're still there, you know, 15 years later, they think of this as natural. And they believe it. And for people that are coming in from other places where they've had a less positive experience with the annual performance review process. It takes a long time to let them trust again.

Tim Bourguignon 19:00
I know what you mean, exactly.

Chris Zimmerman 19:02
It's hard, man. A lot of this. A lot of what you have to do when you're bringing somebody into your company is to help them unlearn the lessons they've learned at the last company, which no longer makes sense, right? So yeah,

Tim Bourguignon 19:12
I had a realization. In the last performance review we did. The company I work for right now, where I was basically giving my top managers the blank check, freedom, reward and saying how you're you're meeting all my expectations, which is, I have no expectations for you, besides being what you are right now. Right? And they looked at me and we realize at some point, but this freedom is all we knew, we've grown into this company, so you're not giving me anything. You're just continuing what you believe what I had before and me coming from pretty traditional German companies. This freedom was very much the biggest reward you could get and When I finally realized this mismatch is holy shit, I've been doing this all wrong. Well, this company just doesn't work. And we put the whole process on set. And we went speaking about behaviors and saying what are the behaviors we want to see? And they're going away from the numbers? Good. I, like you said going away from from an analytical performance review and going more into what are the the Yep, the the behaviors, we want to see? What are the behaviors? And what do they match for kind of roles we have? And where do you want to go? And really having that discussion anywhere? It's way better now. But yeah, on the on the theory, I was on the on the on the energy, analytical side saying, well, numbers a number, I'm an engineer. Right? It took some time to unlearn that. That's yeah,

Chris Zimmerman 20:47
it's hard. And also, I think, I think a lot of the things. I wrote a book about programming, I'm sure we'll talk about that in a little bit. But one of the things that was interesting, right writing book about programming, which necessarily is going to represent my own views about programming, right, I'm writing the book. And those views are completely driven by the environments I've been in, whether that was Princeton, or Microsoft, or sucker punch. And writing the book kind of forces me as an author to confront the question of how many of those beliefs are only true in the limited experience that I've had, right? Like, what some of these are clearly true for the environments I've been in, or the environments I've created, but not elsewhere, right. And the same is true with like, performance reviews, right? Like, we can rebuild our process. So that it's about personal growth and about your journey, this makes a lot more sense. If you've got people that are going to be at your company for five years, or 10 years, or 15 years than it does if you're churning people through, right, like if people are gonna be there six months, and then move on, it's like, you're not going to worry about this, right? You're lucky if they even hit the performance review cycle, right? So there are companies that are like this, right? You have to do it differently, right. And I think that's true for a lot of stuff like we we, we have really good retention at SEC a bunch, we just don't have a lot of turnover. And that enables us to do things really differently as a development organization, because we all have this shared background, right. And we've all been through tough times together and come out the other side and had success. And so there's this really, really deep well of trust, and, you know, a bond between the people on the team because of all this stuff. And so you can run the company with a lot more autonomy and for personal decision making, when everyone is part of an organization like that, right? I mean, you just can and so like I can give advice about people asked me how to run a programming team and say, Well, this is what you should do. But the truth is that that advice works really well for environments like suckerpunch, where, you know, we can be incredibly selective about who we hire, and people stick around for a long time. And we're working on long lifecycle projects, and so on. And if you change any of those, then suddenly, a lot of the advice or a lot of the ways we do things are are suspect, right? They just don't, you're not going to work as well.

Tim Bourguignon 23:20
So I'm really glad to hear you say this. My former company, I switched up something like 18 months ago, and my former company asked me, Hey, can you come back and tell us about those 18 months? What did you learn? Yeah, and I'm analyzing a lot what we did, and trying to see better and strange to see best practices for agencies stuff that I could give them and say, Hey, this is what we did. It is work well. And I'm always hurt by the next sentence, which is, but it works in our context. Because yeah, and and if you don't have this context, the whole card, Castle, how do you call that House of Cards, guard, the whole house of cards falls down and just doesn't work. And you don't have this person who is key in our process, the whole thing falls down and it doesn't work. It revolves around them. And around this process, and around this key activity and around this domain piece. And if you don't have all this, then I'm just giving you bad advice and trying to to to weed out what is what is relevant and what is not just really, really hard. Yeah. How did you approach this in your book?

Chris Zimmerman 24:24
Well, i i One of the ways I approach it in the book is by writing a chapter called How to disagree with this book. Love it. Yeah. So here's the thing I like i It turns out that I called the book the rules a program is kind of a joke because that's actually what we call we call it the rules inside of sucker punch. And it's kind of tongue in cheek. They're not actually rules rules. It's not like anyone's gonna come around with a ruler and slap you on the wrist. We're not following them the guidelines right? You interpret them you have to understand them. So but I call the book the rules a program because it's a fun title. It turns out that programmers don't like being told what to do. Right? And so I'm like, okay, and I understand going in that, you know, some of these rules are really specific to the sucker punch environment, or companies that are set up, like sucker punch, and they're not gonna make mistake, they're not gonna make sense somewhere else, right? Like, let me give you an example. So like, one of the things about games that makes games fun to work on is there really isn't backwards compatibility for the kinds of games we build. Like, we build these single player games that are packaged and sold, their big games where we spent a lot of time a lot of money making them, but they're packaged up and sold, you know, every so often, every few years. And once that game is done, we're kind of done with it. We're moving on to the next game. So we don't have to worry about oh, what about backwards file compatibility? Right? What about all the scripts people have written against our old product? How are they going to run in the next version? We don't have any of that stuff, right? It's all it's all white sheet of paper every single time we build it on top of the last games technology, right? It's not like we throw everything away. But we're not constrained. And because of that, it means that we can be way more aggressive about changing things than you can if you're working, you know, if you're working back office at Deutsche Bank, right, you can't just change how the back office works. You don't want to drop somebody's deposits, right? That would be bad. Probably would not go over well, right. Anyway. So for us, we can we can change things. And so that leads to a different kind of engineering mindset, knowing that we can make big changes whenever we want to. And then that, then that's kind of a ripple, right? Because it's like, okay, well, how would you build your code? If you knew you could change it all the time, right? It's like, well, or if you thought you were going to need to change the language change things just to change things, we change things, because our first version of something sucks, right? And so we can't ship that we're gonna have to change it to something else. And guess what? Try number two also sucks. It's like, try three or four or five. Finally, it's okay. Right? Well, knowing that having seen that over and over and over again, during sucker punches history, we have to write our code and our systems in a way where worrying we know we're going to change it. And so everything in the whole ecosystem has to support that. Because we know the code is going to change, right. And so a lot of the things that we hold as kind of the core tenets of Sucker Punch development, like keeping things as simple as possible, come out of that basic idea that we're going to need to replace stuff because our first guess at what was going to be fun for the player is going to be wrong, because it's always wrong. And it's only after we see why it's wrong, do another version, find out why that one's wrong, that we get to something that actually works that we can make great. So it because it takes, you know, I don't know, think about that people don't realize about playing games, and maybe other games companies do this differently. Maybe other one other game companies are full of people who can predict the future better than I can't. But like people see something at the end, that's pretty good. And they don't see all the versions of it that were really bad that lead up to that. It's. So you know, we run the company around making sure that we can run through five versions of something before we ship something to customers. And that changes everything about how we do stuff as a result.

Tim Bourguignon 28:23
So what I'm thinking about is, is trying to find? No, that's not the way to put it. What you're describing is, is the archetype of the agility approach, saying, Well, we're going to we're going to be flexible, because we need to be flexible. We who's we don't know what we want to discover it. But what I've discovered for myself along the years is, it's really hard to duck feed your your own products all the time. I mean, I work in an elevator maintenance company right now. There's no big wave me too, really dark feet, everything we do, unless I'm really being violent on myself and trying to use the app that we built in a different context. Riot Games is an entirely different different piece of work, because you can duck feet this, I would assume that people working on games are gamers themselves and enjoy playing games. And so you have this loop and you really see what's coming out of it. And you really understand why it's not enough all the way that's not good enough. And yeah, and hence this, this positive spiral of of emergent design. And so what you were describing, well, let's keep it simple, because we know we're going to change, you really are dog feeding this seeing the effects of it and each rating list. And it's a very unique place. It's pretty

Chris Zimmerman 29:43
different. Yeah, it's, and it's something where I think one of the things that's interesting for me looking back the last 25 years of Sucker Punch is seeing how the company's attitudes towards things as philosophy has continued to evolve. You know, it's not like we're stat If we didn't figure it out at some point and and stop there and just keep rewriting the same same program, we've made big changes, we made a big change actually, after, when we started working on Ghost of Tsushima, we actually made a big change, we felt like the team was growing out of touch with the game that some people were playing the parts of the game they were working on, and not seeing the rest of it, or we weren't even playing the parts of the game they were working on, they were just building assets and checking them in not really seeing them in context. And so we switched to having every milestone we have kind of semi agile milestones were like on six week, six week cadence is what we are, every six weeks, we're done with something we're moving on to the next thing, we generally do our planning six weeks at a time, that's kind of a lie, we do some planning much longer than that, scheduling. Turns out that scheduling voice actors you can't do on the on the spur of the moment, they have other gigs, right? But coding, we tend to plan in detail six weeks at a time and kind of in general, longer than that. And every six weeks, the whole team plays the game, we have kind of organized play tests. We call them internal focus tests, I FTS, we just had one or we can have to go. And every six weeks we do that, and we'll identify some part of the game, we want everyone to play and test. And then we have a, you know, mechanisms for getting feedback from everyone surveys, in game surveys out again, surveys, et cetera, et cetera. And we use that partly as a way to help steer the game. Partly, it's kind of a temperature check on how we're doing, and partly as a way to make sure everybody's on the same page about what it is that we're trying to build. You know, I said earlier that one of the things we can do, because we have relatively stable staff is we can give people a lot of personal autonomy, we can help let people make their own decisions about how to do things, and sometimes even what they're going to work on. And that really doesn't work unless everybody's completely in sync about what the game is we're trying to build. And so that ends up being per company our size, one of your core challenges at the leadership level is how do you encapsulate the vision in a way that everyone can keep it in their head all the time, so that when they're left on their own, they're going to make the right decision? The decision that kind of best represents what you're all trying to accomplish as a group. So that that, you know, that's been hard, right? We've been, we've had to work hard at figuring out how to do that. So that everybody has companies gotten a little bit bigger, wasn't hard, and we were like, 20 people or 40 people, but you know, now that we're like, 150 people, it's, it's harder, and thank God, there were 150 people, because a lot of the companies that make games like ours, these sort of big open world action adventure games are like 1000 people, you know, how do you know how to think about that problem? Like, wow, 150 is tough. 1000 Oh, wow. I don't even know where to start.

Tim Bourguignon 33:02
Yeah, 150 is still still somewhat close to Dunbar's number. Yeah, exactly. It's a bit above. But

Chris Zimmerman 33:07
yeah, it's not an accident, not an accident. Right. And it's like at that point you get, it's not I mean, that doesn't actually represent the number of people that are working on the product, right, because there are things that we outsource these days. So we do some asset production offshore. We have people that are part of Sony corporate we're part of so Sucker Punch is a division of Sony, Sony Interactive Entertainment. But we have people that are a part of that are helping with the game that are working at Sony Japan are working at the main SAE offices in San Mateo, we have localization people that are brought in from outside are composers coming from outside, you know, so we have a lot of people who are working on the game that are not not part of sucker punch. And that's one of the ways we've tried to stay below Dunbar's number, right that we have a number of people that we can manage more easily, although that honestly, you know, you think about is that, that that the whole pandemic thing has really thrown a wrench at that, right? I mean, when we were 150 people, and we were all in the same office all the time we were a tribe right now is zoom and teams. And it is really harder, I think, for people to feel like they're part of a tribe. Because you're not you. Like if you're all co located in the same space. You see everybody, you see everybody in the 150 all the time, right? And so even if you're not talking to them, you're not interacting with them directly. You're still there in the same space being part of the same team, you know, you're getting drinks from the same drink cooler, you're sharing the same espresso machines, right? See them on the street, walking around going to lunch. And now with this more of a screens culture because we're kind of a hybrid work environment. Now. It's a lot harder to have that sense of, of, of team, because the people the only people you see are the people you're actually working with directly. You don't get any of this incidental, accidental contact. And I think that that's not I'd rather I miss it. You know, obviously, I'm an old guy, right? Um, it's hard for me to adapt to these new ways, newfangled culture. But you know, I missed it, I missed that I missed the camaraderie that we had when we were all in the same place. You're working hard to make something great together. That's still there. It's just harder to see it.

Tim Bourguignon 35:22
Yeah, it's different. I'm struggling with this as well. Although I'm one of the exhibits of being rebuilt, where the whole most of the team is still new friends. And I'm in Germany. One of the things that I haven't managed to replicate in a remote context is the kind of accidental wins that you hear somewhere in the background, somebody's cheering, having their endorphin rush and saying he did it. And then you rush over and look at this and say who that is cool. And then you add a moment. How do you do that? In the remote context? I haven't crafted

Chris Zimmerman 35:52
one. Yeah, it's tougher. And it's part of it is, you know, we have to push a little bit harder on on the like, the focus tests that we do as a team, because we all know that's a shared experience, right? Or, like one of the guys on the team. My friend Ted actually has this thing called our awesome stat time. And they're in the wrap up for each of our of our team meetings after one of these focus tests, where he identifies some goofy stat, or three goofy stats, and you're like, oh, this person, you know, whatever. I can't actually say what they are, because they're not supposed to talk about their findings, like during ghost, which is actually out it would be, you know, how many how many people? How many times did someone pet a fox, you could pet a fox and goes to Tsushima. You could you there were magical animal helpers and ghost of Tsushima. That was a level of magic we had in the game, very grounded samurai game, but they're magical animal helpers, kind of like a Walt Disney movie, but with samurai sword, so I don't really like Walt Disney movie, but their animal helpers anyhow, you could follow a fox and the Fox would lead you to some bit of treasure, right. And sometimes the Fox would stand still and let you pet the fox. afterwards. This is just a highlight squeals of joy. Imagine squeals of joy ringing throughout the world. 15 million ghost of Tsushima players, just loving the fact that they could pet the fox. And so that'd be the thing. You'd have an awesome stat time you'd say how many who pet it a fox the most during this play test. And so

Tim Bourguignon 37:26
I'm sure there's something that's emerged from from from your play test. I'm going to show you this. Right there.

Chris Zimmerman 37:33
It's definitely the Fox from Ghost of Tsushima. With a detachable Katana in its mouth magnet attached. I really am sad that your podcast viewers can't see this picture. For Fox because this is adorable.

Tim Bourguignon 37:46
Indeed it is indeed today's ID you really have a stuffed animal in your hand a fog with its mouth,

Chris Zimmerman 37:54
animal and a mask as well that you can put on the Fox as well, if you want to put them in, in in. I'm not allowed to say ninja. But ninja mode?

Tim Bourguignon 38:04
Was it something that's all that kind of stuff? Is it something that somebody thought through and say, Okay, let's try this? Or is it something that was just goofy? And we just did it and never thought that would become something?

Chris Zimmerman 38:16
I think that in that particular case, someone said it would be awesome if you could pet the fox and someone else said You are absolutely right. Let's make use with what you do. Yeah. And we put it in and it was awesome. I didn't even know about it. Like this is not this is autonomy, right? Like we don't like there are companies, especially the big ones. You know, if I'm talking about a team, that's 1000 people making an open world game, you got to plan or at least that's my impression of how they do it. They actually have a big plan. They have a huge spec, and they implement the spec and that is absolutely not the way Sucker Punch makes games were much more exploratory and iterative on things. And so at a big company, someone who said, Oh, yeah, look, watch Peppa Fox, and it'll be like a line item and the design document for us. If something were to happen, somebody was in there. They got to the end of the Fox follow. They had a fox capering around. They're like, Man, I really want to pet the fox right here. Like, I think we could let you do that. So they did. And it's not on all foxes, only some of the foxes let you pet the fox. And we didn't talk about it. Right. This was a secret. Like, it wasn't something where, you know, when we were talking about like the pitch for the game, or going out and selling the game, we're talking about mud, blood and steel, we're not talking about following foxes and pet them. But, in fact, there were squeals of joy ringing throughout the world when people got to pet the fox Oh, that's awesome. That's what you know, like, I so here's the thing, right? I, I, I struggled at points in my career with like, Am I doing the right thing, right? Where it's like, you know, I felt like I was changing the world. Maybe that's a little bit too grandiose. But I felt like I was having an impact. When I was at Microsoft, right? I was writing code that a lot of people were going to use and in some ways, it felt self indulgent when I decided to go make video games, right. It was like, I was doing it because I was burnout on Microsoft and I want Something more fun and less frustrating. And little did I know. But I was like, at some level, I was like, wow, I don't know, maybe this isn't really the right thing for me to be doing and some ethical sense. But then we got, it took me a while but eventually got to the point where I said, No, actually, Chris, you're putting smiles on faces. And that's got value, right? We'd get like, we get like, make a wish kids coming and wanting to visit the studio, we get people stopping us in the street, because they see, you know, logos on jackets, and you just get to hear over and over again, what a what a wonderful impact you've had on people's lives. And it's just so great. You know, it took me a long time to get to the point of realizing that what I was doing had real value. And you know, I felt a lot better once I once I felt that right. Once I actually understood that in the depths of my soul that what I was doing actually was valuable. It was it made the job more enjoyable. I was having fun before, obviously. But at that point, I was like, No, this is this is actually good.

Tim Bourguignon 41:08
Makes a lot of sense. And you have a big smile on your face if people cannot see you. But you have a big smile on the face when you talk about it. So yeah, this seems to be the place it. Yeah, did you see yourself doing this all the way to retirement. And even further,

Chris Zimmerman 41:23
I don't know, I don't know, you know, I got we worked really, really hard for a long, long time on Ghost of Tsushima. It took like six years for us to do start to finish, which was a long time. And I was a little bit tired. So I switched to halftime, I backed off to only working 20 hours a week, which was honestly a lot less than halftime 20 hours a week. So what I'm doing these days, and I can help at that level, I can still be helpful sucker punch, but I'm a little bit less emotionally caught up in the ups and downs of the project. And so I'm enjoying myself a little bit more. And I did that. So I'd still just hold my hands in it. I don't know that I could give it up. But I know I have time to do other things. So like I have a GO game project. I'm working on my own right now. We'll see whether that actually ever sees the light of day. But I spent a couple years after we I switched to half time writing a book about programming, which well, here's the story is called the rules of programming by Chris Zimmerman available wherever you buy books. And that the idea of it, the reason I wrote it was that we at sucker punch at Microsoft before then have always had a model for building our staff. When we hire a lot of really Junior programmers, a lot of people have just graduated from school, or maybe they've been working in the industry, maybe not the games industry, just programming of some sort for a couple of years. Because in our experience, if you take someone that's motivated and smart and willing to learn, you know, they can learn how to do the game programming part of it. And that's not really usually a challenge. The hard part is finding people that are motivated and smart and willing to learn. But that does leave us in a position where we have a lot of 22 year olds coming in, who are just like I was at 22. I wish I think maybe it was the peak age between how much I thought I knew minus how much I actually knew. So like that was when the gap like there's some point in my life where that that gap has always been very positive, right? I've always thought I knew more than I actually knew. But there was some point in my life where that was a really, really big gap. And it had or been about 22 or 23. Right? I think that's what my wife would say, that's like, that's where that it's getting better since then, I think. But man that whatever, anyhow, we have a lot of kids that are like that, that come in. And they're smart, they're motivated, and they're willing to learn, but they've got a lot to learn, right? They, they've they've programmed in college, which is different than programming professionally. They worked on small projects that were you know, right and throw away and they were done by their one single person, maybe two people and it was for some, you know, artificial problem that nobody cares about. Right. And so, the and they were taught by people generally, you know, a lot of people that are computer science professors have been in academia their whole lives, right. And so they haven't even had the experience of working on it, you know, 50 person team for five years to know what it is they don't know. Right. And so a lot of freshly minted computer science graduates do know how to program but they don't know how to program at scale, right? They know how to write a loop, but they don't know how to build a big product with a bunch of other people or how to work on a code base that's been evolving for 20 years. And they end up making the same mistakes over and over again, or at least that's what it felt like. It'd be like you'd have a new person coming in and make a mistake that you've seen other people that were in a similar situation, make before them and be like, you know, why do people keep doing this. And so, like, the example I'd use is that I think a lot of 22 year old programmers have heard over and over again through their academic training, that abstraction is good. And generality is good that a general solution to a problem is always better than a specific solution to a problem, you want your code to be as general as possible with deeply internalize this. And so when they come and work at sucker punch, a very common mistake for new soccer punches to make is to write to take some small problem that they have to solve. And write a very general solution that solves that small problem as like a subset of all the things it can do. And it turns out, we really don't want them to do that. You know, I said earlier that we are going to change our code a lot, right, we're going to throw things away, because our first attempt is rarely correct. So we don't want these big, general complicated solutions, because they're harder to change. We want you to keep it simple, so that you can replace it with the next simple thing. And, by the way, your guests about the other things you're going to use this code for probably wrong. Probably no one's going to use it at all, for anything other than you just why you just wrote it. And if they do want to use it for something, it's not actually going to work the way they need it to they're kept changing anyhow. So we see people making this mistake over and over again, again, this is all tied to sucker punch culture and the way we write things and the things we think are important, but for us, it's way better to write a simple solution that exactly meets the problem that you're trying to solve. And if you hit the problem, again, just cut and paste the code, do it again, if you to three times about that point. You were like, Okay, well, now I kind of see the pattern, I can write a general problem that that solves the the general problems that I have, because I've seen them actually concretely in practice. But before then don't don't try to generalize, don't try to guess what's going to happen next to solve the problems you understand. So we kept seeing people make this mistake over and over again. And I would say don't make that mistake, and they would do it again. Right, and the next person can then do it again. And finally, I actually literally, this is actually what happened. I said, Okay, new rule until you see three instances of a problem. You cannot generalize it. And it was like angelic course. Oh, right. It's like, obviously, I'm not gonna train vocalist. And I, and it actually worked, it actually works. Like, they wouldn't do it again. They'd be like, I don't have three examples. I'm not going to generalize this, right. And when someone new came in, I would say, Okay, here's the rule. First time I saw him do it in code review or something first time, so I'm doing like, Okay, here's the rule. Three examples, or you can't generalize. And it worked completely worked. And like, oh, well, that seems like a good answer. Right? Suddenly, I have this, not not just the rule, but the idea of a rule, right? Where it's like, okay, well, what else is there that's like that, what are the other things I can tell people, where I can take some idea, complicated idea, like, Don't generalize until you have three examples, and distill it down into a form that they can remember, right? Where it's like, Oh, I get I got this little thing in my head, right. It's like Haste makes waste, right? Like an aphorism is what they're called, right? It's saying that kind of just like distills down some some wisdom in this format, you can remember and then hopefully apply. And so we started thinking, or I started thinking about all these lessons, I was trying to teach new programmers in terms of rules, right? Not because they're real rules, not because they're super hard and fast things where it's like, oh, no, you absolutely can't do this, you have to break the rule. Sometimes everybody does. But you kind of want to know you're breaking it. So you're thinking hard about what you're doing and why. And so we started accumulating these rules about the things we think are important about code and how did how to how to write code in a way that's going to work well, on the circuit bench code base for the sorts of problems we have to solve, kind of distilled down to these easy remember rules. So like, you know, as simple as possible, but no simpler, right? That's a that's a really can use apply a lot for life. But it turns out that codes a good place to do it, or you need three examples before you can generalize or you know, and when I switched to half time, I decided that I wanted to write a book about this about the rules that we had and why we had rules and why putting things in a rule form was useful, because it makes it easier to remember and easy to apply. And, you know, whether or not the sucker punch rules are appropriate for somebody else, probably some of them are, some of them are right. That's why there's a whole book so you can understand what the point of the rules are, like I say, at some point when I was writing the book in my career So you just being stupid like, should you just like make a list of the rules, one sentence each and just post them on the internet? Because people have done this right? I went and looked and people have done this absolute it's usually like 50 rules, which points not useful at all right? 50 rolls, not useful. 20 rolls, that's okay. I would try it. And I was like, I'd read it. And I'd be like, yes, pithy, but I have no idea what they're talking about. So I did have to end up writing a chapter about each of them. So you understood what the point was, and enough that, you know, when you have the thought of what the rule was, you remember why it existed, and therefore, whether it applied or not, and how to apply it. And so it was okay, but man, let me tell you, if you ever write a book, first of all, writing a book, on a work ton of work, I would not recommend it. Secondly, when I started writing the book, it took me like a year before I could write something that didn't make me throw up in my mouth. When I read it back. I like write something I like, Oh, I'm dispensing wisdom to the world, right? And then I had read, write a chapter and read it back. And I'm like, oh, man, this guy is a jerk. I didn't want to listen to him at all. What an arrogant idiot. Like, unless not good.

Chris Zimmerman 51:14
It's not what I want to feel like when I'm reading the stuff I've written. So I had to keep trying and work on tone and work on it turns out that the thing that helped me as a reader and this reader but helped me as a reader, when I was reading my own, my own writing was to put in lots of examples. So I, the first versions of the, the chapters I was writing were mostly text. And then by the end, they were mostly code. Because that was the thing that grounded it right, it became less preaching. Less like hearing a sermon, you don't want to hear or getting scolded for something. And more like seeing the point I was trying to make kind of embodying and code and understanding the story of why you come to the conclusions that we came to, like, how did we get there? Right? Why do we think this is true? And it became a lot easier to, to read for me, I no longer felt like I was just getting preached at I felt like I was I was looking, I was being taught, I was being mentored, right, or I was being I was being guided or coached, right? Less, less, you know, pretense labs and rigid rules to follow and more, hey, I want you to understand why I'm telling you this, so that you can, you know, figure out whether it applies and at some point, make up your own rules, right, figure out what's important to you, or what's important, your organization and put that into practice. Because that's I think the real point of the rules isn't so much the rules themselves. But the idea of being introspective about your, the way you're writing code as as an individual or the way you're writing code, even more importantly, the way you're writing code as a group, right? Most of us work in groups. And you have to like, think about that. I think if you're going to be effective, you have to put together practices that let you work together effectively, because you're not working independently. If you are, you're not going to be you're not going to get as much done as if you were all working together. So anyhow, but because it's a lot of work.

Tim Bourguignon 53:17
I tried, actually, and I didn't finish it. It's just

Chris Zimmerman 53:24
be like, Chris, you can write another book. I'm like, I don't think so. Never say never, ever say never. But I don't think so it's like childbirth, Tim is going to take a while for the pain, the memory of the pain to fade. So

Tim Bourguignon 53:36
I believe early. It's been a blast. And I have the theme we could talk for ages. But I have to wrap this up. When so you said you wrote this book, basically, on the basis of all the advice you gave to newcomers 22 years old newcomers in in your game studio. So what is the advice you give nowadays, you give the book and say read it? Is there a one advice that you put on top of that, that is not in the book?

Chris Zimmerman 54:05
There's lots of stuff that doesn't fit in Chapter form, because it's just the thought is so true. But so simple. Like, I would say, the first rule of programming is that if something doesn't work, it's your fault. Like how many times have you had someone say, I don't know there's a compiler bug. There's not a compiler. It is not a compiler bug you you got a bug in your code. Like if you change something in something somewhere else broke, it doesn't matter that you don't think there's any connection, it was your fault. But that's not a chapter that's a paragraph right? So that's not a chapter in the book. But honestly, the advice I give people because the thing I get asked a lot is Chris are actually wick I'm old now people say Mr. Zimmerman, I'm like, Oh, God, please not Mr. Zimmerman. Call me Chris. Please. Chris, how do I how do I how do I get into the games business? I'm like, There's no then stopping you from making a game, just make a game, right? Download unity or download unreal, just make a game, you barely even even know how to program and make games these days. So just do it. Because you're not going to get good at it unless you do it. So just do it. And honestly, that's actually what, what one of the ask how do I get a job at sucker punch? Which is another question I get asked is one of the things we actually look for, I'm going to give away the store a little bit here as we look for people who are self starters. So like the thing that is most important to see your most impressive to see on I mean, it's like someone goes to it, like a fancy school and gets really good grades. Awesome. Right? That's great. Someone is great on our programming tests. That's great. Here's the thing that I think is awesome. When I see an iron resume, it's when someone decided that something should happen. And they went and did it. Right. So it's like, I made this game. And I published it on Steam. And yeah, I've sold 75 copies, it doesn't matter. Right? The thing that matters is they actually did it, they actually decided something was going to need to happen. They went and did it. They made it happen. They push it all the way through. And they're they're done. Right. I think that is super cool. And so if I ever see that on a resume, and by the way, I'm not in charge of evaluating resumes at this point. So if I ever see that on a resume, I'm like, Okay, that's a person that I absolutely will talk to you because they're going to make stuff happen. And that's what we want to have that sucker punch. We want people who are going to see that something that game would be better if this if something happened, like petting a fox, and they'll just go do it. Because that's how our games get great.

Tim Bourguignon 56:39
Hell yeah. I can say hell, yeah. Chris, it's been a fantastic discussion, My cheeks are hurting, which is always a good sign. So thank you so much for that. Where would be the best place to continue this discussion with you and still have hurting and hurting cheeks afterwards?

Chris Zimmerman 56:58
High the. LinkedIn is the way people generally get in touch with me. If you can do it, if you send me a LinkedIn request and actually write a personal note, I will probably accept your request. I get a ton of LinkedIn requests from people trying and failing to convince me to enter into an outsourcing agreement with them. So if someone does a LinkedIn request and says, Chris, I heard you on the developer's journey, I will absolutely accept it. And then we can talk as much as they want. So as I said, I'm at the point in my life where I'm giving unsolicited advice to people. So as long as you're willing to listen to unsolicited advice.

Tim Bourguignon 57:39
You're and yes, you want to plug in before we call it today.

Chris Zimmerman 57:44
Ah, you should play goes to Tsushima if you haven't, because it's awesome. The other games are harder to harder to actually know that the infamous games will play so they're great. You can join the millions and millions of satisfied Sucker Punch game players. So

Tim Bourguignon 57:58
you heard it again, Chris, thank you so much again. It's been a blast. It's been fun, Tim, thanks

Chris Zimmerman 58:03
for having me on.

Tim Bourguignon 58:05
And this has been another episode of developer's journey. We see each other next week. Bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you liked the show, please share, rate and review. It helps more listeners discover news stories. You can find the links to all the platforms to show appears on on our website, Dev journey dot info, slash subscribe. Creating the show every week takes a lot of time, energy, and of course money. Will you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation, you will find our patreon link at Dev journey dot info slash donate. And finally, don't hesitate to reach out and tell me how this week's story is shaping your future. You can find me on Twitter at @timothep ti m o th e p corporate email info at Dev journey dot info talk to you soon