×

DevOps Institute

[EP50] What Game Development Taught Me About Culture with Brian Dawson

Continuous Testing, Humans of DevOps, Podcasts

September 13, 2021

On this episode of the Humans of DevOps, Jason Baum is joined by Brian Dawson, Vice President of Developer Relations and Ecosystem Development at The Linux Foundation.

Brian focuses on identifying, sharing, and promoting development best practices in the open-source software community. Prior to his role at The Linux Foundation, he led an agile transformation consulting practice helping organizations small and large implement CI, CD and DevOps.

Brian has spent over 30 years as a software professional in multiple domains including engineering, QA, and management, all with a focus on optimizing software development and delivery.

He’s contributed and been credited on over 100 video game titles.

They discuss cultural and “human” challenges in DevOps and software, console game development and testing at SEGA, leadership and more! 

The lightly edited transcript can be found below.

Narrator 00:02
You’re listening to the humans of DevOps podcast, a podcast focused on advancing the humans of DevOps through skills, knowledge, ideas, and learning, or the SKIL framework.

Brian Dawson 00:16
We should romanticize developers to an extent, not more, though, than we should value or even romanticize all the roles that everybody plays in ensuring that quality software actually gets out to users and solves problems.

Jason Baum 00:33
Hey, everyone, it’s Jason Baum, Director of membership at DevOps Institute. And this is the Humans of DevOps podcast. Welcome back. I hope you were well-rested. We’re back from vacation from Labor Day. This is actually our 50th episode. So hooray to us. And thank you, our listeners for joining us on this journey. Also a big congrats to our original host, Jane Grohl. Thank you, Jane, for taking us through that first half. And it’s been an absolute pleasure to be with you here for the second half of those 50 episodes. And today, the excitement continues. I am very excited to be joined by Brian Dawson, of the Linux Foundation. Brian, thank you so much for joining us.

Brian Dawson 01:22
Thank you for having me. And hello. And I, I doubt as an as exciting as a 50th anniversary or knowing Jane as exciting as Jane, but I’ll do what I can. And it’s an honor actually be your 50th guest. I appreciate it.

Jason Baum 01:38
So just for backstory, Brian is the vice president of Developer Relations and ecosystem development for the Linux Foundation. He is he’s focusing on identifying, sharing and promoting development best practices in the open source software community. He spent over 30 years as a software professional in multiple domains, including engineering, QA and management, all with a focus on optimizing software development and delivery. And prior to Linux Foundation, he led an Agile transformation consulting practice helping organizations small and large implement CI, CD and DevOps. So Brian, thank you again. And are you ready to get human?

Brian Dawson 02:19
I am ready to get human. But I wanna and I’ll probably challenge you by throwing you off foreseen what I want to say. And throughout this No, that’s my new tagline is, I’m loving being on, you know, already to get human. Because as I say, I focus on optimizing software to development and delivery with a particular emphasis on the human side of it. Because I do really believe we can optimize tools, we can have all of the most amazing technologies in the world. But unless we’re thinking about the humans that are at the two endpoints of software development and delivery, we’re never going to reach the true potential of software. So I love this topic, I’m ready to dig in on it, Jason.

Jason Baum 03:07
Awesome. And I love to hear you say that because we are about the humans of DevOps at the DevOps Institute. And on the podcast, especially the humans of DevOps, we want to know about you, we want to get personal, not too personal, but, but we want to get personal, we want to understand, you know, the inner workings of why, you know, you do what you do, you know, anybody can attend lecture, we can all hear the tech talk, we want to hear about you and why. So, you know, our last guest, if you recall, if you listen to this show, two weeks ago, prior to Labor Day, you know, we had a really cool guest all about their background, Joel, Joel train, is what we call him because he plays the saxophone. But, you know, he had such a, an amazing story about, you know, being a musician and getting into tech. And so I would love you know, you have justice, interesting of a background, spending a lot of time in the gaming world. Just a quick hint to our listeners, you know, just dropping some just some stuff. So take us, Brian, on your, your journey, and where it began and how you went from. I’ll let you tell it go ahead. Okay. Well, it’s

Brian Dawson 04:20
funny that you said music and games because music and games I think represent two major plot points in my career in tech. The other there was a bit that preceded it, I’ll hit but, you know, with games. What I was saying my first professional development or engineering job was in the gaming industry now. I decided I wanted to be a programmer, developer engineer, depending there are different ways to slice that. Because I wanted to create games and I’ll flag me in case I forget to tell you about really where that triggered, but where I started to get really, really comfortable with computing and engage with it was, was making music right at about I want to say about 12, or 13 is where I got my first Malcolm McLaren album. And Sugar Hill gang chicken tastes like wood came out. And me and my brother decided we were going to, you know, practice the disciplines of hip hop. But that led into getting a Mac with the first year that digit design or opcode, developed committee. And that’s when we really started wiring things together. And what I was thinking about earlier today is, is what we find we know a lot of technical professionals, actually, not only practice creative arts, but specifically are musicians. And I think one of the things that attracted me to development and gaming as the same thing that attracted me to music is you had a set of rules or building blocks. But outside of those rules and building blocks, you had complete freedom to create, right, just like you have control flow and language constructs and, and CPU instruction sets. You have a set of constraints and a set of building blocks in programming and development. But how you construct those together to manifest something and bring it to bear to solve a problem or to create something new and novel is up to you, which is very much like what I found it to be in creating music and especially in creating and recording your own music, using software. Now, that said, I will add in as I think I may have shared with you in the past, Jason, I my first true experience programming, I lived in a house with a mechanical engineer, who ultimately my father ended up you know, leveraging Computer-Aided Engineering, working at SGI and Cray. So I always lived because of that with technology around me, but it was never forced on me. I ended up in a programming class at about eight years old, loved it, making little lines chase each other around the screen, my first gear version of game development, and I probably would have continued from there. But the sad story is after class one of those days, at eight years old, I got jumped by a couple of kids from my school. And I didn’t go back. I didn’t go back to programming for about another eight or nine years. Instead Intel. Um, I was testing at Sega actually testing video games and I think Jason You Sega fan?

Jason Baum 07:51
Yeah, so I Yeah, okay, so I was a fanboy when you were first telling me this story, you know, when we talk, you know, and you’re dropping games. And of course, these are the games that I grew up on. So yeah, go ahead. Okay,

Brian Dawson 08:05
now, which is the things that I always love, we talk about part of the human side of software development. I love hearing that you worked on the games that we you know, that you loved or enjoy the games we worked on. But we used to have, Sega was a cartridge for you, the younger folks in the audience used to have these things called cartridges that you blow on.

Jason Baum 08:23
Yeah, that’s how you that’s how they work. You blow on them, and then that somehow they magically work?

Brian Dawson 08:29
It was it was the what 80s equivalent of rubbing your credit card stripe on your shirt to get it to run. Right. So true. Yeah. Um, and, and, you know, I got a job test, right, I think I had already maybe started I was writing a domino game. But somehow I was trying to figure out my path to a career and I landed a job testing. And, and people would sit there all day. And we test for something called an address where we used to get these cartridges that had LCD screens on them with with with eight digits, and you’d play and then Sonic would get stuck in a wall and wouldn’t get outright the type of thing that as a player, you would always try to find these loopholes. And, and, and eight numbers would pop up on this thing called an address checker. And I remember going around the office like 30 people, mind you, let’s be real, most of the 30 people were stone. So that’s probably why they couldn’t answer and I go around and ask what does this mean? And no one actually knew what an address checker was. What and so I decided I had to figure it out. And it turned out that it’s when you get a memory overrun, err, and the game code accesses an unauthorized location, it will throw an address here, right? So it’s like a straight pointer. We were programming in assembly and Seaton, but that was really the start of my journey. I know it was a long way to get there. I decided at that point that I had to understand What are what are these addresses? How did these sprites move around the screen? How do we make Sonic the Hedgehog spin up a ramp and flip back? And so I started on this journey of teaching myself how to code.

Jason Baum 10:12
You know, I think that so many who get into this field, it’s just out of sheer curiosity, that seems to be the driver of so many. And a love for understanding your Well, I guess the same thing but yeah, like the understanding piece of it. So So I mean, that’s so there was the middIe. Which, by the way, like, now, there are albums, but it’s like a, you know, that will come out with doing like, right, like regular songs that were recorded. And we’ll do it just in MIDI. And I think, yeah, to listen to, but you know, the background in programming MIDI songs and writing that way. And then the program that you were in when you were eight years old, and I guess you found it back. When was Sega when you were 17? Around? Is that

Brian Dawson 10:54
a Sega? Well, let’s see. Yeah, I started at Sega about 17 or 18. I’m old enough now that I can I can I don’t have to remember specific? Yeah, somewhere between eight and 30. Somewhere in that range? About 17 or 18. Yes.

Jason Baum 11:10
And then what was next? So what So you found this the curiosity? Where did that take you?

Brian Dawson 11:16
Well, so yeah, it wasn’t it was interesting. So you know, the path for people? Well, where it took me actually is it took me to getting I don’t know my first or second PC. I know, I saved up money, a couple of checks. And I used to live in fries at about this time, I was telling you about the Bay area first, Jason, the other Bay Area. First is the first Fry’s Electronics was in Palo Alto. And I was one of the first employees there, which I’m very proud of. I ended up being one of those people that had to like when they said they had to come over and approve transactions. But I started collecting PC Parts and building a PC. And there was a period there, where I literally had my monitor and my desktop. And these things were enormous, then, right next to my bed in my parents’ house, and I go to sleep and I’d wake up coding. So I started making I was a big fan of Domino’s, it seems very simple, not really sexy. But I started creating a Domino’s game around that time. And that’s when I decided that programming is what I’m going to do. And I’m going to make games. So I set on this path. So shortly after this, we heard Sony was going into video games, and they’re like Sony the Walkman people are doing like video cars. Yeah. But then I got a chance to play tacking. And, and I knew that Sony was a place I had had to work. So I kind of identified my career starting, when I landed a job at Sony, as a junior software engineer and our research and development department prior to launch to the Sony PlayStation. One of my proud career moments as sad was I believe, like, literally the 100th employee, or at least the story sounds good. It was given or take some to be hired at Sony Computer Entertainment America. And we went on then to, to, to launch the PlayStation, PlayStation two PlayStation three. And, and in that role, I established kind of my predilection or my affinity for tools and technology. So I wasn’t actually creating the games themselves. I started in third-party developer support where we would take the libraries coming out of Japan, we’d validate them, we may augment them, we may wrap them in some higher-order functions. And then we deliver them to developers, we train developers on how to use these libraries. And then there is always a bit of a research slant to it. ie we were always trying to figure out with the latest hardware and latest libraries that we had. How far can we push the envelope doing novel things? I mean, ray casting, I mean, really even ray tracing, which is a lot less intensive was revolutionary then. So you know, we’d work with some of our senior engineers as a junior engineer to teach people how to how to do ray tracing. So I’ll stop and maybe let you as an interviewer asked me some questions otherwise I’ll take the next

Jason Baum 14:32
No, it’s all fascinating. So and you used to do you are you still do this right? You still you podcast. So you so that’s why I feel like you’re kind of like yes, driving the interview. Please, by all means, I go you

Brian Dawson 14:47
know what? What happens, Jason? I told you when I’m the interviewer, I have to prevent myself from talking too much. And now that I’m your guest, I’m just gonna

Jason Baum 14:58
just go for it. Hey, why not? I love it. No. So I mean, we’re gonna bring it back to human right? Because it’s all about the human at the end of the day. So what would you say, you know, the game development taught you about culture? Because I’m you, you took some pieces away from this, I would assume that you would that would take you into the next path of your career.

Brian Dawson 15:19
Yeah. And well, well, actually, it’s interesting. We’ll flip that around. I, I did not realize what console game development taught me. It taught me about people and culture, probably until about the last six years of my career. But what is this, I have this acronym that I’ve been using called paper, when we describe kind of what an ideal team member, what an ideal worker, what an ideal developer, not even developer, just anybody involved in that software supply chain should possess and its passion, authenticity, performance, empathy, and respect. So paper, and one of the things in thinking back now after enjoying my experience at CloudBees, what has kind of led me to the Linux Foundation is all really calcium, when I saw that was phenomenal, and drove phenomenal innovation in the console game industry. And that’s, it’s this industry that people were passionate about. It was small, it wasn’t easy to get into. But you only did it if you loved it, right? That caused people to show up every day, wanting to do their best wanting to do, there’s all this talk about the insane work hours and development schedules in games. That was also a lesson that I learned in terms of proper process planning more of an iterative, continuous approach can stop people from burning out but the reality is, is people stay and participate in it and, and do 100 plus hour weeks when it comes time to ship because they’re passionate about it. The other thing is authenticity. When we were young, early on, in console, develop the game development, I’d say working on what turned out to be a milestone in console game development. We weren’t showing up in suits, we weren’t showing up worrying about top-down politics, and posturing, we were able to show up and just be ourselves, right. You know, neurodiversity ticks, given, you know, focuses on the way you were, you know, clothes, you wear toys all over your cube, but we’re able to just show up and be ourselves. And what I’ve learned in my career since then, if that if you at least you can pair passion and authenticity together, and your team in your environment enables that, then most likely, the other P the performance part is going to come. And so I think while the game industry gets picked on a lot for its work practices, there is something magical about the innovation that is driven out of the culture that the console game industry enables or empowers. And we could do a lot better at mirroring that, across all of our software development takes, you know, taking some of the politics out, accepting people for who they are, and providing a level of engagement. Oftentimes, we talk about contents, like I’m not just hiring you to bang out some characters. And then and then hit Compile. If you’re using, you know, a compiled language, I actually want you to come into the team and understand what piece you play in the larger problem we’re solving. I want you to think about the humans that are indirectly or indirectly using our software because then it’s my hope that you get engaged and passionate about what you’re doing.

Ad 19:02
Are you looking to get DevOps certified? Demonstrate your DevOps knowledge in advance your career with a certification from DevOps Institute, get certified in DevOps leader, SRE or dev SEC ops, just to name a few. Learn anywhere, anytime. The choice is yours. Choose to get certified through our vast partner network self-study programs, or our new skill of elearning videos. The exams are developed in collaboration with industry thought leaders, and subject matter experts in the DevOps space. Learn more at DevOps institute.com/certifications

Jason Baum 19:34
Yeah, I love everything that you just said. There’s so much psychology that goes into this but I love the fact that basically at the end of the day, we’re just saying treat people like adults treat people the way you want to be treated. Let’s cut out the BS and then basically just show up do your job know your role and understand everybody else’s and where you fit in the big picture and everything’s gonna be okay kind of takes care of itself when we treat each other with respect, it’s an amazing thing.

Brian Dawson 20:03
And can I underscore something on the treat each other with respect, I still May when I grow up, I’m almost 50. Now, but when I grow up, I may find I’m wrong about this. But I’ve always had a slant. And this is particularly important, I’d say in development teams, and understanding that it doesn’t matter where you sit in the hierarchy, and it plays into politics, the so-called hierarchy. Value, everybody’s talent, everybody’s scaling, what they bring to the table, doesn’t matter if you’re an individual contributor, or an engineering reengineering lead or the CIO. Some may get paid more, some may have more purview or breath. But I do think it’s important that, that you understand that everybody from your middle tier engineer to your front end engineer, to the QA team, or your QA engineer, all play a critical role and respect them accordingly.

Jason Baum 20:53
So we talked about kind of what went well, so So let’s talk about some of the things that didn’t, what are some of the cultural human challenges that you encountered? Well,

Brian Dawson 21:04
in the game industry, I’d say it was more about always talk about them, not not, well, this concept called the DevOps Trinity. And we’ve all heard the words. So and I categorize it as people slash culture, process slash practices, tools, and technology, those are the three planes or the three dimensions that you really have to mature equally and continually revisit to get right. And I’d say, in-game development because this was this technical creative endeavor, and, and really, whether it was called out or not, the engineers were treated like artists that should have free rein to do whatever you want, and also have to look where games were born from not as a big industry, but really small team, like we like to envision garage endeavors. Well, something that came of that, that that I learned is, well, that came of it as a lack of, of repeatable focus on repeatable process and practice. Right, and, and I learned a respect for what we’d see a lot of right is you have a game with double-digit million contracts with toys r us tied up to it. And the engineering team, we’d have a ship date of May first, right. And the engineering team wouldn’t share the code with anybody Intel, April 1, and then April 1, it’s throwing it over the wall, picture that waterfall view throwing code over a brick wall, and okay, figure out how to ship it. So in terms of a process that’s supported and practices that supported collaboration with a focus on quality, they weren’t there. Um, the, the other aspect that I had sort of learned, and this goes back to, and there’s many, so I’m just trying to pick out a few is in that there was a lack of respect for the role that QA played in the delivery process, right, which, which, which was, well, we did our work. Now you guys just go figure out how to make our work acceptable. And by the way, you have 30 months to do it at any QA manager, any QA engineer that’s listening to this in any industry will probably share with you that they’ve experienced that. So that goes back to learning that you have to respect everybody on the team. And also to sound really corny, and borrow from Hillary Clinton not to bring politics and but it takes a village, right. We should romanticize developers to an extent. Not more, though, than we should value or even romanticize all the roles that everybody plays in ensuring that quality software actually gets out to users and solves problems for them.

Jason Baum 23:58
So I want to continue with like your, with your journey. And I know that after, after the gaming industry, you kind of transitioned a little bit to sales, I believe briefly. And then and then you are a speaker and an evangelist. So that’s a big transition. And I would love to hear a little bit about that. And, you know, what, what did the transition from tech to marketing sales back to tech, you know, what were the what did you take from it? What were the troubles that you had? What was good?

Brian Dawson 24:37
I think it opened up my eyes and first let’s just call out that I was a good kind of architect, macro solves problem solver. I can kind of come up with novel solutions to problems. I was not a good coder. And there are many reasons so I was probably right We’re moving into some other areas in the development space. And you know, I still code occasionally and I’m decent, but I’m not that prolific programmer. That’s one to sort of set the stage to to set the stage is, you know, I grew up at a time in Silicon Valley, kind of before the startup culture, where, you know, people in my dad’s generation as my dad would validate were, would confirm that there was a constant tension between engineering and sales and marketing. I actually had a chip on my shoulder when I thought I was a hotshot developer of all this talk about value, everybody. I’m like, Man, I’m the guy that knows how to create it, right? I’m smart. You guys can’t do this, you can’t sell our market anything unless we’re creating code. But you know, I was at an arguably big company, or at least under a big umbrella at Sony at this point. And I just thought, you know, marketing and sales and marketing were the people that had parties and got free stuff. And I love to hang out with them, because I don’t like to party and get free stuff. Um, but what happened is I had to transition I had grown up in the game industry, I’d spent about 11 years in the game industry, had brought in our sourcing and reuse practices into what is now the PlayStation company. And I wanted to challenge myself to try something new. And I had an opportunity to join a company called VA software, they created a site called Sourceforge dotnet, which today is just a distribution site back then it used to host projects that were developing for the Linux kernel. And I thought I was I’m like, I think I told you a bit of this, Jason. I’m, like, hey, so we discovered these great new practices in game development. Game developers are not aware of kind of this inner source, you know how to facilitate it. So I’m going to go evangelize it. Lo and behold, I was so naive for this, you know, cocky engineer, that I had just gone and taken a job in technical pre sales, right. And I had no idea what sales was just to cut to the chase on that what I did learn is significant respect, not following the art of sales. But actually what sales reps have to do what it takes, and I and I and I got an appreciation for the fact that the end of the day in a way sales makes the world go around, you can have the greatest idea, you can create the greatest game, you can create the greatest piece of software. But unless someone can cut through the noise, to bring it to people’s attention, so they use it, you haven’t met your objective. And then quickly, because I’m worried I’m just completely winning over you on the show here, Jason is, as I then later made a switch to an evangelist, because throughout my career, as you can tell him a little talkative, I’m rarely accused of being brief, right? So in a world of, of kind of your archetypical introverted engineers, I was someone that could take a complex subject, make it simple and communicate it. So at a point, I was tapped for some of our smartest engineers at Sony, I was tapped to give their talks at our developers conference. And that’s where I kind of started the evangelism. I most recently spent six years at CloudBees, where I joined as a DevOps evangelist, but then stayed to build a product marketing team. So again, what was my lesson, it’s very similar to sales, they are extremely important. It takes a village to develop the best thing in the world. But again, unless you can people to get people to understand why it’s important, why it benefits them, and what problems it solves. You don’t ever truly meet the potential of the software you develop. And just my last point on that, so yeah, I take a lot of pride, it was an unplanned path, but from a developer to a development manager to building and driving a tools and middleware program to driving reuse and practices to, to communicating with customers pre sales to running a post-sales team to now in marketing. I take a lot of pride in that. I have a 180 sort of panoramic perspective on the end-to-end software delivery supply chain.

Jason Baum 29:28
Yeah, you’ve been through the whole process so you know how to communicate it. And you know what, I mean? We always talk like lens talk about lens a lot how you see the world and how someone else might see the world and I feel like you have pretty good lens because you’ve experienced so many things. You’ve seen it from different perspectives. I think sometimes that makes it easier to communicate and also easier on the other end to create.

Brian Dawson 29:53
Yeah, and I I go back to that paper thing. Something that just triggered for me is I think and having different perspectives The at least one benefit it’s giving me is understanding and empathy. And that sort of paper acronym I used earlier. You know, I’ve sat in the QA seat, I know what they go through, I’ve sat in pre-sales, to have to try to sell something that we develop, that’s not ready. I’ve said impulse sales to have to implement it. Right. So I think the one gift and to an extent curse, is giving me a sort of empathy and understanding of the different roles in the process.

Jason Baum 30:32
So you, you, you bounced from different areas, and AI, you’ve experienced so much. Was there anyone helping you along the way? Was there any guidance that you had? And, and from what you’ve learned? What advice do you have to give?

Brian Dawson 30:49
Wow, okay, you really want me to

Jason Baum 30:52
this is an essay and I want it on my desk in?

Brian Dawson 30:57
Well, it started when now I am. I am, you know, unfortunately, and I’m probably missing. So I’m a person of the general philosophy, that I kind of chuckle when people go, you know, I pulled myself up by my bootstraps. I did this on my own, nobody helped me. Well, now, that’s not really true. You might not have seen it, but people have helped, you know, um, I don’t have one particular kind of in the vein of the people, I question that say that I don’t have one particular mentor in my career, like somebody that said, Hey, I’m going to lead you through this year, the person I, I should call by, but I will say that throughout my career, especially being a young engineer, I was constantly observing other people and modeling. off of them subconsciously, you know, if not consciously, in whatever domain I was in. So I think the one thing I would say is whether you know, you’re mentoring or not, you are mentoring. And there are people new to the discipline, you’re in younger are of age and new. And they’re killing off of how you interact. What, what what you do. Outside of that, it sounds corny, you know, I’d say my dad, I didn’t grow up in a circle of technical friends early on. Now, me and all my brothers are in technology. But my dad did. mentoring me my late father, I remember once I got into a professional career, you know, spending hours on the phone talking to him about things like the relationship between engineering and marketing. Now, he did tell me one thing to go through a few of the things I learned and that was, if you work in a technical field management or otherwise, always keep your hands in a technical project. So if you have to spend 10% time just, you know, in an IED off on your own working on something, do it. The technical aspects of software development are not just for developers, all of us should practice and understand them and hone our skills and develop some of empathy. Another interesting thing he taught me that I learned because I’m more of a generalist is, Brian if you do five things for five people than any one person only knows 20%, of what you do, which still hasn’t prevented me from doing 50 million things at once. But at least I know that there’s a compromise to it. But then the key one, I’ll, I’ll kind of, you know, just keep it at the power of threes, go with that I learned early on in an industry with just really, really, really smart people is, don’t be afraid to say I don’t know, right? Don’t BS, your way through a problem. The way you can engage with other people develop mutual respect, and get them to work with you to solve a problem is by not knowing everything. If someone asks you a question. And you don’t know say, I don’t know because one, you know, in a space where, to an extent authenticity, but absolutely, knowledge is valued. Claiming you know, something that you don’t can instantly lose respect. I’d much rather say You know what, I don’t know. Let me go look into that and figure it out for you. Or you know what, I don’t know. Why don’t we talk through this and work it out together?

Jason Baum 34:25
Yeah, your credibility is really important because once you lose it, you lose respect and that that’s everything. The other thing that you said about your dad early on your whole journey kind of process that starts with your dad buying you the turntables, right, it was the right, yeah, got a Radio Shack mixer. But yeah, your turntables and a microphone. Yeah. I mean,

Brian Dawson 34:47
Hold on. Wait, hold on. We get two turntables and a microphone.

Jason Baum 34:51
Yeah. So I mean, that’s kind of great. That’s kind of the beginning of it all. So I love all that. So we’re gonna We’re coming up on time. I feel like we could talk all day. But I always asked this question. And, you know, I didn’t warn you about this ahead of time. Maybe I should have. But I like to ask this. This is usually my last question. What’s one unique thing about you that maybe you haven’t shared in a work environment? I usually say what nobody knows. But that’s tough.

Brian Dawson 35:26
I gotta think about it, man. There’s, I’m such an open but I you know, I just had to talk so much that at some point, I tell everybody, everything. I try to keep secrets. I mean, we just talked about it here. You actually got it, it would be this. I don’t know what other guests do. So forgive me if this is it doesn’t sort of meet the bar.

Jason Baum 35:46
We’ve had a little bit of everything, Brian. On this one.

Brian Dawson 35:50
It’s kind of it’s kind of silly. And I’m going through a few but I’ll just say this when we talked about music what I’m what most people I have I have worked with don’t know is that you know, I had been I err, quoted and musician for, you know, what, the past 35 years. And I think most people don’t know that I have actually recorded a couple of CDs that are out there. I never let people know my pseudonym. And, and I’m proud to have worked with a very talented drummer. Brain who actually was the drummer from Primus and sublime. Wow, actually produced the CD with me. So nothing, you know, cool. Ah, but just a little fun fact.

Jason Baum 36:41
Awesome. That’s, that’s awesome. Is that’s the California connection? I’m guessing the

Brian Dawson 36:46
yes, yeah, is the California I didn’t know I would have at being from Long, Long Island, or having spent time out there. I don’t recall Jackie might appreciate that. One of my first marriages. The other fun fact is that I was this close to creating a Wu-Tang game. I actually had brought it to the Wu-Tang Clan and put together a whole game design. And I had wanted to create a hip-hop slash game development studio.

Jason Baum 37:15
Oh, I was so bought that one, too. You. You took so much of my money, Brian, back in the day. Yeah, I think you were sharing like at one point or looking, I was looking at your credits. And I saw X Men on there. And I pretty much that was my entire childhood was losing money to the X Men arcade game until I finally beat it. And it’s so it games are so great until you beat them. And they’re like

Brian Dawson 37:39
that now it’s like, that’s like a technical challenge. They’re fantastic. They solve them. But thank you, because you were part of that I said, the human part of the software supply chain. Your course, helped the world go round as well.

Jason Baum 37:53
So can see we all bring it all the way back to the human aspect. Brian, this has been awesome. We could talk all day. We are we’re gonna talk after this. And it’s been an absolute pleasure having you on the show.

Brian Dawson 38:05
Well, thank you, Jason. It’s been a joy. Thanks for giving me a platform to let it loose. And yeah, I look forward to having you on my podcast. Soon

Jason Baum 38:13
here. Awesome. Can’t wait, why don’t you plug the podcast?

Brian Dawson 38:17
I will. I’m spinning up a new one. The blog guest that I just left was DevOps radio, which I did for three years at CloudBees. in coming weeks here, I’ll be spinning up a new podcast called dev effects under Linux Foundation, interestingly enough, talking about the human side of open source software development, and I look forward to having you

Jason Baum 38:38
there. I can’t wait. Awesome. Thanks again, Brian. All right. Thank you. And thank you for listening to this episode of the humans of DevOps Podcast. I’m going to end this one the same as I always do, encouraging you to become a premium member of DevOps Institute to get access to even more great resources just like this one. Until next time, stay safe, stay healthy, and most of all, stay human, live long and prosper.

Narrator 39:04
Thanks for listening to this episode of the humans of DevOps podcast. Don’t forget to join our global community to get access to even more great resources like this. Until next time, remember, you are part of something bigger than yourself. You belong

Promo graphic of a giftbox with SKILup IT Learning logo

Community at DevOps Institute

related posts

Predictions 2023: DevOps Will Become The Norm

Predictions 2023: DevOps Will Become The Norm

By Eveline Oehrlich and Guest Contributors For the Majority of Organizations, DevOps Must Still Expand DevOps promises better quality software and happier working environments. The measures of deployment frequency, lead time for changes, MTTR, and change failure rate...