Real World DevOps

Real World DevOpsEpisode 16
Database Performance With a Side of Empathy with Baron Schwartz
1x
Database Performance With a Side of Empathy with Baron Schwartz
By Mike Julian • View the Website

Baron Schwartz joins me for a delightful conversation about his technique for writing books, his thoughts on culture change, and wrapping up with a very real conversation about bias, privilege, and empathy that you won’t want to miss.

Broadcast by

Baron Schwartz joins me for a delightful conversation about his technique for writing books, his thoughts on culture change, and wrapping up with a very real conversation about bias, privilege, and empathy that you won’t want to miss.

About the Guest

Baron is the CTO and founder of VividCortex, the best way to see what your production database servers are doing. Baron has written a lot of open source software, and several books including High Performance MySQL. He’s focused his career on learning and teaching about scalability, performance, and observability of systems generally (including the view that teams are systems and culture influences their performance), and databases specifically.

Links Referenced

Transcript

Mike Julian: This is the Real World DevOps podcast and I'm your host Mike Julian. I'm setting out to meet the most interesting people doing awesome work in the world of DevOps, from the creators of your favorite tools to the organizers of amazing conferences, from the authors of great books to fantastic public speakers. I want to introduce you to the most interesting people I can find.


Mike Julian: Ahh, crash reporting. An oft-forgotten piece of a solid monitoring strategy. If you struggled to replicate bugs or elusive performance issues you're hearing about it from your users, you should check out Raygun, whether you're responsible for web or mobile applications, Raygun makes it pretty easy to find and diagnose problems in minutes instead of what you usually do, which if you're anything like me, is ask the nearest person, "Hey, it's the app slow for you?" and getting a blank stare back because, hey, this is Starbucks and who's the weird guy asking questions about mobile app performance. Anyways, Raygun, my personal thanks to them for helping to make this podcast possible. You can check out their free trial today by going to raygun.com.


Mike Julian: Hi folks. I'm Mike Julian, your host of the Real World DevOps podcast. My guest this week is Baron Schwartz, the founder and CTO of Vivid Cortex and author of a book that I'm sure many of you have laying around, High Performance MySQL. Welcome to the show Baron.


Baron Schwartz: Thanks Mike. Great to be here.


Mike Julian: Baron some years ago, well, I also started writing a book in like 2015, I guess it was, 2016. And you've written a lot about your writing and I mean you are a very prolific writer on your blog, having also written the tome of High Performance MySQL.


Baron Schwartz: Maybe too much of a tome. Yeah.


Mike Julian: Right. It is a pretty sizable book. And I found this article that you had written about how you wrote, which I found absolutely fascinating. One of the pieces of advice I saw that I've used and have been regurgitating to everyone. How do you write the book while you outline? You start with an outline and then you keep outlining. And you keep and keep and keep on outlining until you're at the point where you should feel like you've stopped outlining long ago and then outline some more. Yeah, just a little bit more after that.


I thought that was incredibly insightful advice because most people, they do stop jotting down thoughts a bit too early.


Baron Schwartz: Yeah. I should use that advice myself. Every time I do it, I'm really happy with the results. The truth is I don't always, and then I'm like, "Why is this so hard?" It's just because I'm just slogging through not having outlined and now I've got ... So for folks who are not going to read this blog post, which I assume will be a lot of our listeners, the general idea that led me to try this approach was actually writing the second edition. So the blog post that you're talking about was written after the third edition of High Performance MySQL. And the second edition was an absolutely horrendous amount of work. I know because I used a timekeeping app and I basically spent like a half a year on it. So it was more than a thousand hours of really hard work.


And then afterwards I looked at what was most of that time spent doing and most of it was actually spent editing things that turned into pros too soon because pros has to have correct grammar. And if you don't feel right about the order of the ideas in a paragraph and you start fussing with it, then the grammar gets mucked up when you're sort of dragging things around or whatever. And so you try and fix that, but you're polishing something that is structurally bad and to fix it, you end up having to go back and restructure it and then re-edit it. But if you're re-editing for grammar and flow and everything the whole time, it's just an insane amount of work.


So the third edition, I did using mostly the outlining style that you're talking about, mostly after several years of having just collected notes, which is a part of the writing process that's largely invisible, just like filling files full of one bullet point URLs or quick little one liners or whatever. And I took that stuff, I sort of decomposed the second edition into its component parts, restructured it, put in the stuff that I wanted to update or new material, and then outlined and wrote. And the third edition was about 300 hours of work. Although it was a complete rewrite of the book and made it much larger. So it was a lot more material and a lot more accomplishment with a heck of a lot less work.


Mike Julian: Yeah. When I first started writing mine, I did actually start tracking time and then I stopped doing it after a while on the advice of one of the editors of the first edition of a friend of mine, Derek Balling, he gave me a piece of advice that do not ever under any circumstances, attempt to calculate your hourly rate of writing a book.


Baron Schwartz: Excellent advice. Yeah. If you do the math, what you end up earning from a book is almost always depressing in purely economic terms. However, I will say it's been a huge ... well, there's a couple of things. High Performance MySQL has been unusually best selling for a technical book and very few books ever strike gold that way, which is purely a function of just circumstances and luck and things like that. So I think if I calculated my hourly rate, it wouldn't be depressing, but that's-


Mike Julian: It would also just not be awesome.


Baron Schwartz: Yeah. It still wouldn't be awesome. But it's been good to get the royalty checks every now and then, which most authors never get. They never pay back their advances. And that's part of the publishing role. But yeah, even if you do, it's still ... But there's also a lot that you can't just reduce to an hourly rate about the benefits of writing a book, not only for example, the book lives on, and carries to many audiences, and reach as many people, and touches many lives that you never would have in other ways and that comes back and is very rewarding. People write me on a fairly regular basis and say something. I met with somebody a couple of months ago and he said, "I have to thank you for making me a millionaire." I said, "Well, can I get a finder's fee? Just 1%."


Mike Julian: Oh, wouldn't that be nice. It's always wild to me when I get the notifications that, "Hey, your book's been translated into another language." I'm like, "What? People care that much?"


Baron Schwartz: Yeah. I mean, it's so gratifying in so many ways. I recommend the experience, but also just like life skills, and connections, and there's probably 15 or 20 different kinds of things that have come out of this book that I would not have thought of going in.


Mike Julian: So you recently, I saw you recently, released an eBook on DevOps and databases.


Baron Schwartz: Yeah. The newest tome. This one is only 65 pages, not 850 or whatever.


Mike Julian: That's not so bad. I mean, that's like a weekend project, right?


Baron Schwartz: It basically was a weekend project after five years.


Mike Julian: Right. Overnight success 10 years in the making.


Baron Schwartz: Exactly. Yeah. The way I wrote that book was actually a little bit different. I outlined and outlined and outlined and I had accumulated a lot of material. I also crowd sourced a lot of it. And so I tried to do a lot of giving credit in the book because a lot of it was not original material, but it was more, "Let's pull all of this stuff together that people have done this here. And it kind of connects to that over there." So a lot of personal experience over ... well really 15 years of career experience plus five years of trying to put pieces together. And then one day, last November I think it was, or ... yeah, I think it was in November I presented in QCon, but Jessica Carrie had helped me to tie together the stuff that I had been sort of ranting about with databases under the rubric of DevOps, which had not really occurred to me before. So I have to give her credit a lot for kind of tying all of these things together and recruiting me to give that talk.


And then since then I gave the talk a couple of times, and did a lot of research, and digging around, and watching other people's talks, and things like that. So all of that came together. I outlined it, tried to organize the content thematically, and then I used a technique that I haven't used a whole lot for writing, which is, I just voice dictated the whole thing.


Mike Julian: Oh, interesting.


Baron Schwartz: Basically a weekend project.


Mike Julian: I mean, speaking at yourself the entire weekend.


Baron Schwartz: Yeah. Because you know what? I was sort of in a mental place where I just needed to kind of somehow get the energy and momentum to just plow through the whole thing or it wasn't going to get done. And the best way for me to do that sometimes is to hook myself up to a microphone, double press the function key, and start dictating. And especially to dictate in a ranty kind of a way, which will help me to tie together things that I feel strongly about in a very fluid way. Very, very much stream of consciousness. So that book, when it actually got into characters in a Google doc, was not outlined like that. It was dictated and ranted. And then I basically crowdsourced that very crude first draft to a bunch of people just asking on Twitter, "Hey, who wants ..." And then I shared the Google doc with them. And pretty much people said, "This really sounds very ranty."


Mike Julian: I wonder why?


Baron Schwartz: Yeah. I wonder why? And here are some things that you can do to make it better. And then I went back through and edited, but I had been working from a fairly strong outline, so I ended up not having to do a lot of wordsmithing at the kind of structural level. So basically what I needed to do was sort of get the unsavory tone of voice and all of the things that come with the rant, get those things out of there as much as I can. So it probably isn't completely there. There's probably still some places where you feel like I'm lecturing a little bit too much or whatever as you read it. But I think if you look at a perfect book, let's say there was a mythical perfect book, that would fall in the center of the bullseye and books all start somewhere around the rim and they gravitate towards the center, but they never get there.


Mike Julian: Yeah, exactly.


Baron Schwartz: I just came from a different point on the rim.


Mike Julian: Right. So what I want you to tell us what the ... I know the book is about DevOps and databases, but what's actually in there?


Baron Schwartz: Yeah, there's a bunch of stuff. A bunch of it is things that other people have been thinking about for a long time. A lot of it was inspiration from our customers. So for those who don't know me, Vivid Cortex is a database performance monitoring company and our customers use us to observe large fleets of databases running at scale, typically performance critical, where it's really a big data problem to understand what these databases are doing. And we were noticing that some customers were very successful with this and they would report to us that they were moving really fast and engineering productivity was going way up. And we would do onsite visits. I would do onsite visits with them and see the evidence. I was like, "These teams are awesome, not just in database, not just in monitoring, but just across the board." They are doing really awesome work.


I kept trying to figure out what was different about those companies and what was different about the companies that would have a champion who would bring us in and who we would get some traction, and then after a year they wouldn't renew. And just kind of putting the pieces together a little bit over time and also with some things that I feel really strongly about. Like where is your critical productivity bottleneck in your engineering team? And it's typically not where people think it is and if you read books like The DevOps handbook, or The Phoenix Project, or The Goal, they focus on the sneaky nature of bottlenecks coming from dependencies, and variations, and people with specialization. And that these things are so much more costly than anybody ever expects them to be.


And I had been sort of ranting about this as, "Your DBA is a great resource for your company, but if you make them the critical bottleneck, then everybody suffers by having to wait for the DBA." And I just really couldn't connect that into DevOps for a long time until Jessica helped me to see that. And so that's one of the big things that I wrote about in the book that I think is actually, I don't know if it's, revolutionary, but I don't know if people have really written a lot about it before. Certainly, Silvia Botros was I think one of your first guests on this podcast and she was talking about some --


Mike Julian: The very first guest.


Baron Schwartz: Yeah, the very first. She was certainly talking about that. She's written blog posts like a DBA is a priesthood no more. I'm not the only person. But I didn't feel like it was kind of an industry wide thing that everybody recognized and was talking about, that making your DBA a specialized role is a bottleneck for the entire engineering team. So that's one of the big themes of this book. I think DevOps is often considered to be, especially in the database, DevOps is often kind of defined as automation. We've automated the DBA grunt work, but the really high performing companies that I've worked with and the ones that have been the most successful with VividCortex are often the ones who take it beyond, "Let's make the DBA efficient." Into, "Let's help the developers to own more of the application lifecycle." So it's more like the Netflix philosophy of full lifecycle product ownership rather than, "Let's collaborate really well together across these silos."


Mike Julian: Yeah, that's an interesting point. I want to dig into that a bit more. How does that actually look in practice? How can an engineering team own more of the database work?


Baron Schwartz: Yeah, there's a few things. One is, there's a lot of those things like company culture, and team structure, and who's responsible for what as far as what are your goals and incentives, what is rewarded, what is promoted, what is seen as high status or low status work, things like that. And so those are kind of subtle things that are difficult to be very prescriptive about. I mean they're not actually very subtle, but I think the difference between achieving good results with them or not can be sort of subtle differences can make a big difference in the outcome.


So I'm thinking of ... I think I can speak pretty openly about some of our customers, like draft kings and certainly about SendGrid, where Sylvia works. There are teams there who desire to own more and have folks who are curious and interested in the database and don't feel like they have to be or want to be kind of either protectively kept away from something or that something is too hard for them to embrace and dig in and get really good at. Right. So part of it starts with having really high quality people who you then empower by breaking down some of the things that become functional barriers. Nobody's going to feel really great about being a developer who becomes awesome with databases or SQL if they also can't get visibility into the databases. For example, if they're forbidden the ability to monitor them.


So that's particularly near and dear to my heart because that's what we do, is provide production visibility into databases. But there are other things as well. It's not just about monitoring. There are things like automation, automating the deploy pipeline, decomposing or decoupling things in such a way that you can release the application without changing the database and you can change the database without having to rerelease the application. And there's a lot of good material in there. They're very detailed case studies that I cited and linked to from companies like Zalando, and Flow, and the Gilt Groupe, and so forth about how to do all of those things. So this is not a theoretical book of sort of preachy principles or something like that. The principles are there just to sort of organize and structure things, but then it gets down into the nuts and bolts, but it's also a short book. It's only 65 pages, so you can't actually get into a code listings. So instead of doing that, I just link out a lot to people's presentations, and other eBooks, and blog posts, and things like that.


Mike Julian: That's wonderful. So, yeah, that's awesome. I'll include a link to that eBook in the show notes too. What I think is really interesting about some stuff you mentioned there is the cultural aspects and curiosity, high performing teams, they're not just like we do X, Y, and Z as tactical things, but how they think, how they work together, how they approach a problem holistically. It seems to have a really high performing team is actually focus a lot more on the human side of things.


Baron Schwartz: It very much is. Yeah. Yeah. And there's a lot of stuff that I included, cited some things. So there's this weird thing about culture. So we talk a lot about DevOps as being very culture focused and that DevOps is a culture or there are various ways to say it, but culture is kind of a squishy topic because you don't just-


Mike Julian: Oh, yeah, right.


Baron Schwartz: You don't 'change culture'. That's a recipe for disaster. Somebody tweeted a little while ago ... I can't remember who it was, but somebody tweeted that if you take a poor culture and you bring great people into it, you don't fix the culture, you break the great people.


Mike Julian: Right. Right. Yeah. I've seen that.


Baron Schwartz: Yes. Yeah. I have to. Yeah, absolutely. And another related tweet that comes up while I'm brainstorming about tweets is Kelsey Hightower tweeted pretty recently, "Get the right people on the bus, but only after you fired the wrong people." And I've also seen that that's super important because you can only keep either your high performing people or your low performing people, but not both.


There's a very loaded topic because what does high performing or low performing mean, and have they been supported, and did you set them up to fail? Lots and lots of nuances there. But if you just want sort of a hot take, I think all of the things that I said are true when you kind of understand the depth of thinking that can be behind them. But anyway, back to culture, basically you don't change culture directly. Instead you do things like changing an incentive, or giving people a different tool to make the right thing easier, or changing what people do. For example, there are lots and lots of sort of culture change things that are just like change in which order people do a task and then suddenly something else follows from that. There is a book that I'm trying to dredge out of my memory that touches on this topic and I can't. Maybe I'll think of that later and put it in the notes or maybe you know it.


Mike Julian: Yeah, absolutely. I worked with a company a while back, some years ago, that they worked with Pivotal. And now a lot of people know Pivotal from pivotal tracker or pivotal web services, but what a lot of people don't quite see is they also have a consulting wing where you can go in as a company and send part of your team and you can work with Pivotal at their offices for a few days, weeks, months, whatever you want to pay them for. And I had the experience of being with a company that paid Pivotal to help us with launching a new project. So I was at their office for like three, four months. And one of the coolest things about it is ... the best way to describe Pivotal's approach to Agile is zealotry. And that sounds negative. And in some ways at the time, I was really frustrated by this, but now I look back and I see, "Oh, actually that was very much intentional. It's probably not how it is all the time."


But what they were doing is things like work starts at 9:00 AM, work ends at 5:00 PM. If you're here before then working, we're going to ask you to stop. If you're here after then working, we're also going to ask you to stop. Lunch happens at noon, the bell rings and you have to stop working. That sounds terrible. And then you look at actually what happened as a result of that is that people have a much more healthier approach to work and things like you were always pairing when you're writing code nearly 100% of the time. That was frustrating for me. That was frustrating for basically everyone on my team. Well the interesting thing that actually happened as a result of this was when we stopped working with Pivotal, we all went back, well there's a big contention of the company that hadn't had that experience, but there's about 20 of us that had had the experience and we come back with all the stuff that we had been doing for the past three, four months.


These are very tactical process. This is just how we do things. And then you get to see the culture conflict. Two completely separate teams that used to be one are now working very differently.


Baron Schwartz: Oh, wow.


Mike Julian: Yeah. It was wild to see 'cause you see all the zealotry paid off. It wasn't really about them being zealots about what they were doing. It was about, "We're teaching you a new way to work."


Baron Schwartz: Yeah. That sounds like a really interesting experience. Yeah.


Mike Julian: Oh, it was absolutely a fascinating experience that kind of ... what made me think of that is, if you change how you do a task and then you just repeat that whole thing of like, "I have task one through 10 and I'm going to change how I'm doing all 10 of these tasks." Over time you change culture. Culture doesn't change first.


Baron Schwartz: That's right. Yeah. I think it's much more successful the way that you're describing. Yeah.


Mike Julian: So Nicole Forsgren accelerates her state of Java's report. In the book it talks a lot about that as well.


Baron Schwartz: Yeah. They've got an entire sections on culture change, and the western generative culture or organizational structure, and the consequences, and what creates, or sustains, or fights against those kinds of things. And everything in there resonates with my personal experience. And what's really cool is that now there's science. It's no longer anecdotes from people who've sort of been there, done that. Let me tell you. And it's no longer a simply, "Well, it's a bestselling business book, so it must be right." Right? Now we actually have legit well-constructed research with scientifically valid results. I mean, it's incredible. It cannot be overstated what a value accelerate, and Nicole, and the team have created for the whole community. I think it's incredible.


Mike Julian: Completely agreed. One of the things that's been coming up a lot lately and I know you've been discussing on Twitter and through your blog posts, is the value of diversity as a performance factor of like diverse teams are better teams. Also, just like diversity is good from a moral and ethical standpoint. We should be diverse because the world is diverse.


Baron Schwartz: Exactly. Yeah. It seems hard to argue against it, but you find yourself having to make business justification arguments for things sometimes, which feels absurd. It feels like an argument that shouldn't ... maybe shouldn't even have to be engaged. Thank goodness, again, accelerate is there with the data and the DAR report brings the numbers that you can use to whack people that want to be whacked with a number stick. And for those of us who are more focused on the human side of things, it's a little bit tricky because both kinds of justification are good and work for different people and at the same time it's a little bit of a shame, maybe even a lot of a shame that we actually have to resort to financial benefit return on investment arguments to advocate for people being equally valuable.


Mike Julian: Yeah. I saw a tweet a while back that, it said, "I don't know how to explain to you how to care about other people or why you should care about other people." And that stuck with me because it's so directly and eloquently said like, "Well, yeah, you're right. Other people are valuable because they are other people."


Baron Schwartz: Right. There's one that I've put in a lot of my slide decks as well that says something along the lines ... I'm going to have to find this for your notes as well later. It says something along the lines of good teams are composed of people actively caring about each other.


Mike Julian: Oh, that's a good one.


Baron Schwartz: Yeah, I'll find it. We'll put it in the notes 'cause I know I've got that bookmarked all over the place.


Mike Julian: Man. That's a good one.


Baron Schwartz: There's all of this stuff that came from Google's research, which actually came from somebody at MIT, I think, about the psychological safety, and what that really means, and what creates psychological safety and teams and things like that. And it kinda gets long ended it. And then this one little tweet kind of sums it up. I've been trying to do this in my personal life too. Just personally, I'm a self improver. I'm a seeker. And a while ago I realized that there were things about my attitudes and beliefs and biases that I didn't like. For example, I don't know if you've done this, but project implicit, which is out of Harvard. I think it's probably like implicit.harvard.edu or something like that.


Mike Julian: Yeah. I took that and it was depressing.


Baron Schwartz: Yes. Yeah. Basically I'm a racist.


Mike Julian: Yeah. That's what I got too and it was depressing not because I disagreed with it, because it is valid research. It's backed scientifically, but it exposes that part of yourself that you don't want to think about and exposes that, "Hey, there's a whole lot that you have been brought up around that you don't even think about."


Baron Schwartz: Just completely unconscious.


Mike Julian: Yeah. That's the entire point of the implicit bias of you have biases that you don't think about, but they are there.


Baron Schwartz: Yeah. Yeah. And we're two White guys for people who are listening and can't see us, but for two White guys, this comes as like a complete revelation. I don't know about you, but I think I first took that implicit bias test when I was well into my 30s and probably approaching 40. And it just made me realize that there were entire things that I had never thought about and would never have occurred to me to think about, entire realms of curiosity about my experience in the world that were just ... it was a complete revelation to me. And I started to lean into that. I started to think, "Well, what else is there?"


So a couple of things that have been super helpful to me and that I recommend to everybody, well, one of them I recommend to everybody who is male and another I recommend to everybody who is White. There's a podcast series from scene on radio called Men, which is all about what his maleness, and where did it come from, and what does it mean? And it tries to expose or to help men experience their maleness because it's so unconscious. It's the default mode of living. It's the fish swimming in the water as a metaphor they use. The fish is not aware of the water. And it was so helpful to me to start to realize this water that I swim in. And then the series prior to that, it was called Seeing White. And it's exactly centered around the same thing.


As a white guy, what is Whiteness? Where did it come from? What does it mean? How does it work? How am I a White person operating in Whiteness? And so it kind of comes back to this implicit bias stuff. And it showed me or gave me access to a different mode of inquiry that has led me deeper since then. And the one thing that I want to emphasize from here, I think I've said several times before about these things, is how helpful they've been. But I don't know if I've really kind of said how much joy I've gotten out of starting to realize the variety of human experience that was kind of denied to me, really. I was very much off from a huge spectrum of modes of being by virtue of unconsciously being trained to perform maleness and to operate in Whiteness and all of these kinds of things.


And so one of the things I've done is I've intentionally diversified my feet. I don't follow very many White male voices, which I'm not meaning this in any sort of accusing or holier than thou kind of away or whatever. But I think my feed is something like ... the people that I follow on Twitter, is something like 85% women and a lot of Black women because they live at the intersection of two different types of oppression. And you hear a truth from them because of their direct experience day by day, minute by minute, that it's accessible if you listen to those voices. But if you don't really make a conscious effort to do it, you can live your entire life in the bubble of these things never occurring to you.


Probably again, what's probably coming through in what I'm talking about here is probably mostly about, "Oh wow, what a revelation." But the part of it that might not come through or might not be obvious until folks experienced it for themselves is, "Wow, what a joy. It's just so enriching to understand and then to have access to different ways of being." Yeah. I can only recommend it to everybody. Listen to Black people, listen to women, listen to minorities, listen to disabled people, listen to people who are not in tech. Think about it. If the links that are coming through in your Twitter or Facebook or whatever are mostly about, I dunno, so and so invented a new algorithm for sorting or whatever. It's like, "Okay, big deal." You're going to find out everything that you need to know and much more. You're saturated with all of this kind of stuff. I know I was when I was just sort of following who is the majority population in tech, but following poets, following journalists, such richness and such joy.


Mike Julian: Oh yeah, absolutely. And I can kind of echo some of the stuff you've experienced. Years ago when I first started really waking up, I had had this internal narrative that I was successful because I had made myself successful.


Baron Schwartz: Yeah. Me too.


Mike Julian: Right. And my parents and family and all of this, were all looking at me saying, "Well, clearly you've made yourself successful." After a while I started to realize, "Well, no, actually there were a lot of experiences that I had that would not have been available to other people simply because of I'm White." There were the old boys network is definitely a thing.


Baron Schwartz: Totally.


Mike Julian: My breakout job that really kicked off my career happened about halfway through my career. But I got because of the people that I knew and to me it's like, "Oh well anyone can build a network." And that's what I did. I consciously built a network. Well, the fact that I consciously did it is valuable, but that I was able to have that opportunity to begin with was something that I'd never even considered.


Baron Schwartz: Yeah. When I started thinking about these things ... like I listened to the Seeing White series first and I started thinking about all of the ways that affirmative action has bullied me and been the wind in my sails my entire life. I mean, I'll just give you one example. I started to think back to how I got into college. I was homeschooled. I got into UVA, one of the top colleges in America, without ever having taken the SAT test, so I can probably just leave it right there. There's probably a lot of heads nodding and going, "Mm-hmm (affirmative)." Right. But I got into community college first and I had to take remedial courses because there were areas that homeschooling had left me dramatically under prepared. And I was also at the same time, my parents had told me if I wanted to go to college, I was going to have to pay for it myself.


And the financial aid system just ushered me in and I actually did some stuff that I shouldn't have done. I realized about it later. I started feeling like, "Wow, those are kind of not really cool things that I did." I went back to the financial aid people and they said, "You can't fix this now. It's water under the bridge. Forget about it." Now these are not federal felonies or whatever, but I was sort of feeling like I was between a rock and a hard place with kind of being out on my own in the world and having some trouble with money and things like that. There are definitely people who would not have been just sort of so kindly forgiven by the system. There is no question that being White has been several steps ahead on the starting gun many, many times and being male many, many times.

Look, it's not as though I should seek to tear away these privileges and throw them on the ground and trample them because it's power. Instead, I should use this power for good. I should use it to raise up and help people who don't have that power, should use it to advocate for them when there are folks who don't recognize that not everybody comes with those same levels of power, and privilege, and advantage. So those are some of the kinds of things that I do. And I have honestly come from a very difficult upbringing and experienced a lot of traumatic things and although I also have these privileges at the same time, and so what this combination has done for me, because I've been bullied, and beaten, and abused, and all of these other kinds of things, there's a very strong trigger in me when I see that happening.


And by listening to the voices of people who have come from different places in the social advantage system, when I see that happening now the triggers kick in and I'm much more likely to jump in and try and help out. Even if that is just seeing that somebody is having a tough time and then just jumping into their DM and saying, "I see you're having a tough time or whatever it is."


Mike Julian: You mentioned that learning about all this has brought you joy. And for me it's kind of the same thing happened. Learning about all this is I enjoy helping other people. That's what I love doing. I love making connections with other people. I know tons of people in a lot of different places through just a lifetime of making new friends.


Once I was able to understand I have this privilege and a lot of other people don't. A lot of other people will never have these connections that I do. They will never have the access that I might. Now that I know this, I'm actually able to ... I get joy from making introductions. And those introductions lead to changing of lives, which just makes me even more happier and also betters the world.


Baron Schwartz: Yeah. Being able to help people in a very real and genuine way, it is a source of enormous gratitude and gratitude is the source of happiness. You want to be happy, don't try to be happy, try to be grateful and becoming conscious of what's going on around you. I'm a big follower of Thich Nhat Hanh. And I was listening to one of his recordings the other day.


One of the things that he does through mindfulness, just coaching people to be present, to have access, and to be established in the here and now, is to recognize the small things that are a miracle. You and I are talking to each other on computers thousands of miles away. It's a miracle.


Mike Julian: It really is. It blows my mind.


Baron Schwartz: It's a thousand miracles. But in this little recording of his, he was talking about, "You turn on the tap water, and you put your hands under it, and you recognize that the water running into your house is a miracle. You didn't have to walk miles with a bucket to get that water. It's a miracle." So there are so many of these things that are miraculous and recognizing the differences in experiences and being able to make a little bit of a difference for someone else is enormously gratifying.


Mike Julian: Well, I think that's a fantastic place to wrap up our conversation. Baron, thank you so much for joining me. Where can people find out more about you and your work?


Baron Schwartz: I'm on Twitter. That's my main social network @xaprb and my personal blog is xaprb.com and I may be coming soon to a conference near you such as velocity or something like that. Those are the typical types of conferences that I'm at. Tweet me, email me. You can email me baron@vividcortex.com or baron@xaprb.com for personal stuff. And I always love hearing from people.


Mike Julian: And don't forget to grab a copy of his latest eBook too.


Baron Schwartz: Yes. And please tell me what you think of it and how to improve it.


Mike Julian: Well to our listeners, thank you for listening to the Real World DevOps podcast. If you want to stay up to date on the latest episodes, you can find us @realworlddevops.com and on iTunes, Google play, or wherever it is you get your podcast. I'll see you in the next episode.


What is Real World DevOps?

I'm setting out to meet interesting people doing awesome work in the world of DevOps. From the creators of your favorite tools to the organizers of amazing conferences, from the authors of great books to fantastic public speakers. I want to introduce you to the most interesting people I can find.