 So right here, we'll be the turn-on switch. So we've got another five minutes or so, isn't it? Hello. Hello, everyone, and welcome to open source lessons from a four-year-old. I'm Colleen. I'm here to introduce Jonah Bacon and his little special guest, Jack Bacon. All right. How's everyone doing? Come on, you know how this works. We've done this before. How's everyone doing? You all right, Jack? Yeah? OK. All right, so I don't know everyone in this room. So for those of you who I don't know, I've been doing community for a while. I used to work at Canonical GitHub, Xprise. And now I'm a consultant, and I help companies to build communities. And typically, with these kinds of talks, I'd kind of blather on about some of the client work that I've been doing. And it's been really fun doing this. I've only been doing it for full time for a little less than a year. And the diversity of the work is interesting. And it bubbles up all kinds of interesting insights and perspectives on how people work in different ways. So the commonalities between them as well. But today, I'm really going to be talking about more of a personal story. And it's going to be very personal. In 2008, this was a big year in my life because I used to live here. This is Wolverhampton. Is anyone familiar with Wolverhampton? This is not surprising. Wolverhampton, not a particularly nice place to live, it has to be said. That really does capture the spirit and the culture of Wolverhampton right there. And at the time, I was also working at Canonical and running the Ubuntu team forward slash boy band, the Ubuntu community team. And in 2008, I moved to this place, Oakland, which I thought was an epicenter of crime. But it turns out to be an epicenter of cool restaurants and cocktail bars. And moved over there. And then on the 8th of November, 2008, I married this beautiful woman who sat in the audience right there. And thus began the dude, really? She's way too hot for you. So anyway, so we got married. And as often happens, we were enjoying our married years. And the time is right to start thinking about having a family. And on the 14th of November, 2012, this little person popped out with a ridiculous amount of arm hair for some particular reason. I don't know why. You can already see it from there. That's actually him laid on my chest. That's my chest right there. And you can see my hand a little bit behind there. He was tiny. How many of you have got kids, by the way? All right, so a lot of this is going to be very familiar, I suspect. So he was born. And one of the things that really struck me as soon as he popped out was we now had this little chemistry set in our house, this little science lab of all these things that are going to be happening. My career really primarily, since I started, has been about understanding people. Community is really about understanding the connective tissue between people and how people do things. And I find it fascinating. And it's a huge jigsaw puzzle to tease apart. And I thought, this little boy is going to be in this house and he's going to be growing up. And there's all kinds of questions about nature versus nurture and this, that, and the other. So this is going to be a very powerful environment in which I can learn more about this. It ended up looking a bit more like this in the last kind of three or four years. Because what happened is we went from this little person ultimately to this person. See, if any of you are uncertain about whether he's my son, that should be your evidence right there, OK? So I'm going to throw at this talk really kind of walk through some of the things that I've learned in the last four years about community and open source and how Jack has helped me to kind of zone in on these different things. So let's first of all talk about playing and hacking. Over the last four years, Jack has played with lots of different things, OK? This is his first experience playing Sonic the Hedgehog in an emulator. I love that. That was basically my experience when I first played Sonic the Hedgehog. Jack, do you like the Hedgehog game? Yeah? Can you say yeah? OK, good. This was Jack playing with, we had this, Eric and I have signed up to a personal trainer recently. So you can imagine how that's working out for me. And this is an exercise box. And it arrived. And Jack wanted to kind of screw the things in and help to make it. And he was playing with that. And he did a really good job with that as well. And then what's been interesting is he starts playing with different things. And then we have this thing arrive. Has anyone seen this before? It's called a coder pillar. And basically what it is, is it comes in lots of individual little segments. And each segment has got like a symbol on it, like a left arrow or a forward arrow or a right arrow. And you put the segments in place. And then it moves the caterpillar based on the order of those different arrows. It essentially teaches rudimentary elements of coding. And Jack's really loved playing with this. Because at the beginning, he played with it and it moved forward. But then he started kind of fiddling with it and trying to make it do different things, primarily smacking it into the wall. And this is when I really started noticing that really we do first, we first play and then we hack, right? And this is how all of us got involved in this, right? I'm pretty sure that everyone in this room, when you first discovered open source, it was through using a Linux distribution or a particular project and you used it. And then you realize, wow, I can actually change that. I can improve it. I can refine it. I remember when I started, my first distribution was called Slackware 96. And what, yeah, represent. Any Slackware users back then in the room? Yeah, it's the original gangsters. And the thing that was even more interesting to me about it than the distra was the fact that people could contribute to it, that you could change it. And that's really empowering, I think, particularly for people who are young or elderly people as well. A good example of this in my mind is Doom. Anyone play this when this came out? Yeah, this is a great game. We played it and we were impressed. This was like the first proper 3D shooter, really. And then it was ported to a digital camera. People started hacking on it. And it was ported to an iPod as well. Not a very good port to an iPod by the looks of things. And it was ported to some terrible watch that some company released. And it was ported to a printer. And to this ridiculous touch bar thing. And to a scientific calculator. It gets worse. I have more ATM. How do you test that? A oscilloscope. Oh yeah, look at that. And then some guy even ported it to a car. And you actually have to steer the car to kind of play the game. Which seems suboptimal. And the pièce de résistance of this is some guy who decided, do you know what's missing from playing Doom? Controlling it with toasters. So he hooked his toasters up to his computer and he's like, you gotta see the YouTube video for this, it's absolutely brilliant. So, but this again, it gets to that kind of central theme of we play with something and then we hack on it. And what's really critical that I've learned here is this is the reason why hackable content is so important. Like, I used to work at an organization called XPRIZE. And XPRIZE is a great organization that has these huge competitions to solve big problems in the world. And my job there was to build out a community. And one of the things that was a little difficult was that's an organization that builds competitions. They're more of a policy group. In an open source organization or a software company, you can build a community because you have a central piece of hackable material. It's code or it's documentation or it's translations. And that's what helps people to come together because unless you have that, you can't build an asynchronous distributed community. That's why things such as GitHub and GitLab are so important because you get that material, you play with it, and then you provide it with an environment where you can experiment and you can contribute those experimental pieces with other people as well. And in the last few years, I've been trying to, I'm a very simple human being. So what I like to do is to be able to understand something and then to boil it down into a simple model that helps me to understand it and opens up further questions. And I've kind of come up with this, which is imagine you've got on the far left hand side a typical user, someone who has used something and now they want to contribute in some way. They need to first of all go on this on ramp. And some of you who've seen me speak before will have seen this, where this is, what do you need to do to help someone make the first contribution? So with code that is something such as you need to be able to discover that you can participate. Then you need to be able to learn the skills that you need to actually contribute. The software development environment, the code itself. You need to be set up your tool chain. That can sometimes take a day for some projects. Then you need to be able to find something to work on. Then to get help and then to be validated that you did something that you contributed something. It's amazing how many open source projects get this wrong. This is way too complicated. And this to me is the first area of focus. And then you get into this kind of phase where you start out as new. So you've got no context, no relationships. And then you become a regular, where it's more like the cyclical kind of workflow. And then up here you kind of become a leader and a core kind of contributor. And the way in which we engage with those three different areas is radically different from my experience. I'll get onto that a little bit more later on, but I do want to talk about incentives. Because, you know, in the community leadership world, I think, incentives, people look at it with different perspectives. There is a feeling that if someone's going to contribute to an open source project, they should do it for the righteous right reasons. And I agree. However, we are, as animals, massively incentivized. And one of the things that's been interesting playing and learning with Jack is how incentives can help you to incentivize the right kind of behavior that you want to see. Now, in our house, this is roughly translated as, Daddy, can I have a rescue bot? Okay. Jack, do you like rescue bots? Yeah. Who's your favorite rescue bot? Who? Heatwave. I love heatwave as well. So, you know, if Jack wants to do something, that if we can incentivize it in the right kind of way, then it invariably triggers that kind of reaction, which for me, coming from the north of England, I sometimes find infuriating, because I feel like I was born in a black and white movie and raised in a mine, right? Where there was no incentives whatsoever. So I'm going to give you, there's basically two types of rewards that are typically the output of when you incentivize someone. The first one is called an extrinsic reward. And I'm going to explain this with a little piece of video. Now, I was hanging out with Stuart Langridge, who many of you will have seen at the show last night, who thought that that was a dog turd on that spoon. Okay. So I just want to clarify, it's not. It's chocolate, weirdo. Okay. But this, I forget what happened, but Jack had done something really good. And an extrinsic reward is a material thing. It's a toy, it's a gift. It's something that he can consume. And in this case, quite literally. That's cool. We're coming for her slow landing. We're, we're, we're coming for her slow landing. We're, we're, we're. Yum, yum, yum, yum, yum, yum. So that's an example of an extrinsic reward. And then you have an intrinsic reward. This is when I took him to the zoo. Erica runs a company called Bitnami and she was in Spain for a week and I took him to the zoo and he was a bit nervous about getting on the train and he loves trains. But one of the things, I wanted to kind of, the behavior that I wanted to encourage here was kind of becoming more fearless and trusting that this is a safe thing, this is okay. So he did it. And really the intrinsic reward here was a huge amount of validation like, you know, you're a big boy, you know, you did a good job, I'm really proud of you and those kinds of things. And that is in many ways more important than the extrinsic rewards than anything else. So essentially what I've learned through this is, and this applies massively to communities and open source projects is, you know, for example, if we take Jack and I want him to learn how to ride a bike, okay, that's my bike, by the way. What I will do is I will help him to learn that skill and then I will, there'll be these two incentives, there'll be an incentive, intrinsic reward or an extrinsic reward. And there has to be both, okay. The difficulty here is essentially over reward, right? So I wrote a blog post a little while back and I put this in here. There's been some interesting research done, it's called the Yerkes-Dodson Scale, that shows that if you provide too many rewards to a person or to a community, then they can become so focused on the rewards that their performance actually reduces down. So to illustrate this, imagine I'm teaching Jack how to do something and he gets Batman, okay, and then he keeps doing really good things and he's learning more and he's a chief of more things and there's a mixture of intrinsic pieces here as well, but then he gets Ray from Star Wars, okay. And the problem is when people typically do this, you see this with parents all the time, is that as they do more and more stuff then this massive pile of toys appears in the corner of the living room because they keep doing these things and the expectation is the desire for the reward will keep continuing and the performance will keep continuing. Whereas in reality actually tends to fall off because what happens is they become so focused on the reward that their actual performance slows down, but invariably you keep rewarding them with more and more things. So you give them some stupid gaming machine with like two screens that pull out the side and now you're spending a load of money but you're actually not achieving any noticeable results. All right, so now I'm going to perform a nice segue and I want to talk a little bit about behavioral economics. Some of you may have heard of this before. Has anyone familiar with behavioral economics in this room? Oh good, so just a few. So when Jack was born, one of the things that really struck me was there's this big debate between nature and nurture, all right. And I thought this is going to be fascinating watching this pan out in our house and one of the things that I've become increasingly interested in against Stuart language, he introduced me to this. There's a great speaker called Rory Sutherland who he introduced me to. The basic idea is this is that we've all got one of these in our brains. Some are considerably smaller than others. And according to a book called Thinking Fast and Slow, it's basically broken into two broad areas. You've got system one thinking and system one thinking is essentially that kind of the part of the brain that's been there for hundreds of thousands of years is still looking for the tiger in the bush. And it's still reacting to things without really thinking, having any kind of conscious thought. And then you've got system two thinking. This is the conscious decision making logical piece of the brain. And as Rory Sutherland describes it, the system two is almost like the press office that's constantly explaining away the terrible decisions that system one is kind of executing, okay. Behavioral economics is the basic notion that we are as people very irrational. So we think of ourselves that we walk through the world and we're presented with information and we assess that information and we make good decisions based upon that information. But that doesn't really happen. We actually make terrible decisions. If we were rational, we'd all have savings. We'd all exercise regularly. We wouldn't drink alcohol. We'd plan for retirement. We'd all buy the art of community. But in reality, as I've discovered from the book sales, we're irrational and we go out drinking at the weekends and we don't exercise and we eat unhealthy food and we don't plan for retirement. But we're consistent in the way that tends to happen. So that kind of consistency of irrational behavior is the study of behavioral economics. So good example, tax return. Some interesting research found that a lot of people, when they cheat, they cheat just a little bit, right? They don't cheat a lot because people have a good sense of self-character and self-worth. So what happens is they have a tax return and they go through and some people fiddle the numbers a little bit, right? So they may be at too many expenses here or whatever it might be. I'm not suggesting obviously that I do this. Erica does the taxes. So if anyone does it, it's her. She's looking a bit guilty right now. So what happens is people go through and they may fiddle the taxes a little bit. And if you sign at the end, then people have fiddled the taxes and they sign their name. If you change the form so they sign at the beginning because they identify themselves first, the level of cheating goes down. And that to me is interesting. That brings out all kinds of parallel considerations around like how do we use that for example to influence behavior on forums and message boards. There's a great platform called Discourse which is a forum and there's all kinds of behavioral economics pieces built into that because Jeff Atwood, the co-founder of it, is a big fan of this kind of stuff. Another example is this sign. This is actually from Rory Sutherland. Scotland put these signs up. We're all familiar with these signs, right? So Scotland put these signs up with the expectation that the accident rate, the death rate would go down. But the Scots saw this more of a competition than a deterrent. And the psychologist basically recommended that you change this to an unhappy frowny face. And it causes something called a feedback loop and what happened is the accident rate went down. Bizarre. Another example in my mind that I think maps very well to open source is something called the IKEA effect. So you go out to IKEA, if I go and buy one of these tables and let's say Lisa goes and buys one of these tables and they're identical, we each make these tables independently, well each think ours is a little bit better because we overvalue personal creation. And this has got huge implications of things like code review. Is that code review should be as objective as possible so you remove that internal kind of bias that people tend to have with their creations. This is why I think we see a huge amount of conflict in open source because fundamentally it's a, I hate to use these words, but it's a contribution economy, right? All right, another example, final example that again relates to cheating. Dan Ariely, who's a professor, did some interesting research that found that he had a class of students at MIT, gave them a very clear opportunity to cheat. So ask them a bunch of questions and then in this condition, they just asked the students like did you get this right, did you get this right without checking and then they shredded it. And people again just cheated a little bit. They didn't cheat a huge amount. Then in the next test, they basically got a set of students through the 10 commandments first and cheating went down significantly. Because again it's like a reminder of a moral code. Again, this could have implications for how communication works in open source communities. I don't think there's a religious significance there. It's more about a reminder of what good conduct should be. That's actually something that discourse has implemented pretty well. The problem with behavioral economics is the maths is really difficult, right? And it's very anecdotal, but there's this guy who appears to be part man, part tiger in this picture. And he's called Dr. David Rock and he came out with something called the scarf model which I think is something we can map very easily to businesses, to relationships, all kinds of different things. And it basically looks like this. Is each of these things, he's a neuroscientist done a bunch of research with animals and he found that these five elements people really care about. So for example, we all care about status. There's this interesting thing in industry where people say they don't care about job titles. But we all care about job titles. It's just not really socially acceptable to express that. But status is a huge deal in everybody's lives. Even with Jack, for example, you know, with Jack, is that your passport? Cool, can you show everyone your passport? Hold it up. I know, I'm embarrassed of my picture as well. With, so even with Jack, for example, he's a big boy and we tell him he's a big boy and that means a big deal to him because he knows his progress. And like, Jack talks a lot about the difference between him being a baby and being a big boy and it's the difference, for example, with between a contributor and a committer or a manager and someone who isn't a manager. These status elements influence our behavior and the relationships we have with people. So when we understand status and we can plan for it and we can clearly show the on-ramp from one status to another, we can actually build a real sense of accomplishment in different communities. The next one is certainty. Unsurprisingly from his research, people don't like stress and anxiety. And when you have uncertainty, it causes stress, it causes anxiety and what happens is people make really bad decisions when they are stressed and they're anxious as I'm sure everybody in this room has done at one point in their lives. So again with Jack, a lot of this is, when he's nervous about something so she's going to school in the mornings, this is about providing reassurance, not just for that individual instance, but also just more broadly. Instead of just saying, hey, it's gonna be okay today, is at night when he's back from school is reinforcing that certainty over and over again. This is something where I think that bounce between open source companies and open source projects gets really sticky because the company always has more information in the community. So, and the company often doesn't do a good job enough in dealing with the potential perception of nervousness and things like that that are going on to reassure people. The third element here is autonomy and this is basically choice. Is that rather unsurprisingly, choice is really important to all of us. And a big chunk of the work that I do is, choice architecture is, okay, we want this person in the community to get to this point. What are the options that we can give them where we still all get to the same point? This is why, for example, customization is so important to a lot of people. This is why when you go and buy a car, you don't just get a car, you can choose all the different configuration and the models and the wheels and things like that. But you're still given that company your money, but that choice makes it feel more rewarding. It puts people in a sense of control. This is something we use all the time with Jack, for example. Would you like to eat kale or broccoli, for example? And when she says none of the above, chocolate, please. Then we have relatedness and relatedness is essentially different groups of people. So for example, in the company, you may have engineering, marketing, you may have other groups. Different groups of people will form their own little mini cultures. So the culture in an engineering team is often quite different to the culture in a sales team, for example. And there are different groups of people at Jack's school. There are different groups of people in our family. There's different groups of people in our company. So understanding and helping those cultures to thrive is really important. For example, when I was at Canonical, at one point, my team grew to six, but at one point we were four people. And there's a guy called George Castro, who some of you may know. George is a huge Metallica fan and insisted that we called ourselves the Four Horsemen, which is a Metallica song. And we had t-shirts made and all kinds of stuff. And that kind of cultural identity was very important. And then the final one is fairness. And this is one of the things I really learned a lot from Jack as well. Unsurprisingly, Dr. David Rock's research found that people want to be treated fairly. That's not particularly surprising. But it also found that people don't like to see other people treated unfairly. And a number of times, Jack has come home from school where he said, you know, he felt like his friend didn't get treated fairly or there's been times when Eric and I have been debating something and he'll just chip in and basically say, Daddy, don't say that to Mummy, kind of thing. Because he's got a real sense of fairness, not just for him, but for other people as well. And that I think is intrinsic in how people tend to think. So this is important for communities because justice is important in treating people well, but not just the justice, but the perception of the justice and the execution of the justice is really important as well, particularly in areas of diversity. Now what's interesting, I went to this event years ago called Foo Cam that O'Reilly, I think they still put it on, can't remember. And I met this guy who has written a few different books. And one of the things that he said to me was that always stuck with me, that the way in which you build a great thing is you have to build the worst thing first. So if you wanna build a great cell phone, then what's the worst cell phone that you can build? Like it's one, like for me, like it's one that has got only a few buttons on there. There's no screen. There's a parallel port in the side of it. You don't receive phone calls from my mother-in-law, et cetera, et cetera. No offense to me. But then what you can do is you can optimize, you're designing for failure. You can say, okay, well we don't want the lack of information so we put a screen on it. And you essentially, in this context, you optimize for the things on the left and the things on the right are the things that are the opposite of it. So the opposite of status is clicks, certainty is stress, autonomy is limits, relatedness is chaos, fairness is bias. And I think this gives us a good sense for the patterns we wanna focus on and the anti-patterns we wanna design around. And if you do this well, then Jack gets a rescue bot. Jack, which rescue bot is that? Do you know which rescue bot that is? Is it Optimus? Optimus. Optimus Prime? Yeah. Yep, so Jack gets his rescue bot and Daddy gets loads of gin. Specifically St. George gin from California, if you wanna get me any gin. Let's talk a little bit about working together. So, Jack watches a lot of television. Well, not too much television. So, when you're out of the house, maybe. Jack watches some TV. So for example, the Mickey Mouse Clubhouse. Jack, who's your favorite Mickey Mouse Clubhouse friend? All of them? Good choice, non-committal. Mickey Mouse Clubhouse, he also watches Paw Patrol. Who's your favorite pup? He's gonna be a politician when he's older. And this show is called Super Why. Has anyone with kids seen this? This is the most annoying program on television. I hate this pig. Alpha Pig. That is Alpha Pig. Oh, it's horrendous. Also, there is a joke that this may be a reality TV show about the elementary team, which seems unfair. But what's interesting is with all of these shows, it's about teamwork and it's about collaboration. And one of the things I've noticed with Jacking with the way he loves shows that are about working together and solving problems. We've had him watch other shows that aren't about that. He's just not interested in them. So I talked earlier on about this, which is the on-ramp. But I think when we dig into this, it gets pretty interesting. The way I tend to think of collaboration is that it's fairly consistently looks kind of like this, where you have, the first thing we need to do in how we collaborate and how we build collaborative structures is we need to, first of all, understand what success is. This, when I consult with companies, I found this pretty transformative in getting this clear, is that you might have five or six different people who are all working the same thing and they really are not thinking about the same kind of problem, okay? So getting that clear is the first element. Then understanding the context in which you're gonna collaborate in which you're gonna do something and having that shared set of skills and that shared set of tools is important and then being able to communicate consistently as well. And then at the end of it, you need acknowledgement of this. This is not student language, this is not ACK, okay? That's not how he spells it. And he shouldn't ever be the validation of any of this kind of work as well. Ginger is a service. So I think what we do is, again, in breaking things down, if we can understand what each of these different pieces are and we can optimize them as well as possible, then we build really, really great collaborative structures. So for example, within the context of Jack, let's assume Jack and Erica and I are all hanging out and we're gonna build a speedboat out of Lego, right? So the first thing we need to understand to find a set is what is a speedboat and what does it look like? So we'll look a picture of it up on the internet or we'll define where that's gonna be. Then the context, well, we're here and this is what we've got to play with, wanna do it in this set of time and there's the three of us are available to do this. And then the skills are gonna be knowing how to use Lego, which we've all got as a skill, the tools of the Lego, and then the communication is talking with each other, communicating and body language. And then, but the key thing is when you go through that round and round is you validate each step of it. So, oh, we've built the bottom part of the speedboat and now we've added the other, I don't know much about speedboats as you can probably tell, but you add all these different bits to the speedboat and you acknowledge and you validate that and that's effectively how we grow. So if we break those different pieces down into how companies collaborate and how communities collaborate, then we can optimize that collaborative piece. And earlier on, like when I, you know, I was talking about these different roles that people can play in communities and with each, there's these three different phases that I mentioned. Now, when you're new, you have no context, you have no relationships. The example that I've been providing recently, which might seem weird and I promise you, this is not an insight into our life, but I imagine what it's like for a lot of people who are new to open source is it must be like going to a new discolony for the first time. Because effectively this is brand new, it's weird, you don't know anyone, everything's out on display, right? And it must be just an awkward set of communications. Think about how it applies to open source. You get a project and you want to contribute to it. You create something on your machine and how do you share that? Oh, you have to do it all out in the open. You have to submit a pull request. You've got to have that reviewed and peer reviewed publicly. That freaks a lot of people out. So being new is really difficult. That's why that on-ramp piece is so important in my mind is clarifying that because you make that process as simple and as secure both in terms of confidence as well as technology as possible. But what I just talked about that kind of cycle of how we collaborate is what happens really as you're a regular because what happens is we do the same thing over and over again with different contexts. Like if you think about how you write code, it's invariably, you know, clone or fork, write code, submit a pull request, do code review and merge, right? And there's all CICD, all that kind of stuff that can be attached into that. But it's the same basic thing with different contexts. We need to make sure that that's efficient and that people are happy with it and people feel connected to it. And the only way in which we can learn that is to ask the people who are doing it, right? The people who should not be making this decision are engineering managers, okay? It should be engineers, for example. But then when we get into the core, the core elements, like the leadership, this is where I think we engage very differently because invariably the people who naturally bubble up to the surface as leaders in a particular project, we want to build an environment where the core people will mentor and support the regulars and the regulars will mentor and support the new people and then you build scale because mentoring programs never work out typically because you always have way fewer mentors than you have mentees. So we would need, the thing that's key with the leaders is we want those people to be set up so they can be constantly identify and improve in different elements in how we work together. And then what happens is you build a community that evolves and you build a generational community of open source. So the last bit I want to get onto here is really around challenges. We face challenges in the world all the time, right? I'll give you a few examples. I don't have a picture of what happened in this particular case, but when Jack, I love that picture, by the way. When Jack was very young, we had a friend over at our house and I was kind of holding Jack up like this, you know. Oh, go, go, go, go, go, go, go, go, go, go, go. Because he's a baby, right? We do that to babies. And my friend was stood next to me and she said, I wouldn't do that if I were you. I was like, why? I was like, I just wouldn't do that. I'm like, oh, go, go, go, go. And then he proceeded to throw up in my mouth. Now I don't mean around my mouth. He filled my mouth with vomit, okay? I want you all to taste what I tasted so you can understand how terrible this was. So I just immediately handed him off to our friend and I just ran to the bathroom and was trying to get it out. And of course, I got the taste out, but oh, it was not good. I went downstairs and she was downstairs and Erica was downstairs with Jack and I could hear them cackling like witches. And I went down and Erica said to me, you know what the worst thing about that is? It's like, what? Worse than having a child throw up in my mouth? Like what? She said, it's breast milk. Oh, so that didn't go as expected. So we have challenges like that. Sometimes we get hurt. I got hurt the other day and this is all that all we had in the car. Poor patrol. I have a hairy leg by the way. So sometimes we get hurt and we get hurt emotionally. We get hurt physically and this is important. Like a lot of people, particularly today, like more and more people have been open about difficulties that have in their lives. We want to help people to get over those difficulties and to be successful. And then just sometimes, like you get embarrassed, right? I love that. This is one of my favorite pictures of Jack. Look at that builder's crack right down there. And what I love about it is his face is, what? Jack, do you like that picture? Yeah? No. And then another challenge I think, and what I think is even more important in many ways is confidence, right? This is when we went to a kid's birthday party and this was not the first time. This is like the 50th time I showed you, okay? But you know, is giving people the confidence to kind of succeed and get over those challenges that they've got? We've all got roadblocks in front of us. And one of the things that I've become a huge fan of in recent years is something called stoicism. Anyone familiar with this? So this is something, if there's one thing I want you to take away from this talk is this. Because I think it will help everyone in this room in whatever context and whatever world you live in is go and learn about stoicism. This is Marcus Aurelius, who is one of the kind of early forefathers. He was a pretty powerful dude in the Roman era. And stoicism is the basic principle of it is that in the world, in the world every day, you can think of our bodies as being hardware and our brains, you know, our thoughts and our perspective as being software. And typically when we're in challenging situations, stoicism is about dealing with difficult situations, dealing with challenges. And we often react emotionally. You know like, we've all been there, you've been in a meeting with your boss and it's not going well. Or you're having a difficult discussion with your spouse or somebody else and you get that knot in your stomach. And it's so overwhelming that you just react. And then afterwards when you're at home that night drinking a gin and tonic and reflecting, like, why did I say that? Like, why did I do this? The principle of stoicism is that you train almost a separate voice that you can look inside. You can look at yourself from the outside in. So when you're in that meeting with the boss and it's not going very well, is you can say, you know, now, how do I react to this? What do I want to accomplish in this situation? Like, I'm feeling that knot in my stomach but I don't want that to control me. What does my boss want to hear? Well, I'm going to be reactive to the feedback. And you say, you know, I appreciate it, I'm going to be calm, I'm going to be respectful, I'm going to focus on a solution, I'm going to focus on moving forward. And this stoicism has been applied throughout the ages, right? There was a guy called Viktor Frankl who was in Auschwitz. And he used this extensively to deal with that. And he just said to himself, this is terrible, this environment's terrible, but what I'm going to do is I'm going to focus on what I'm going to do when I get out there. I enjoy teaching children. And he built a rapport with the guards in Auschwitz and he eventually got out and he ended up becoming a real scholar in this area as well. And this is something you have to train. But the thing that's powerful about it is that when you train yourself in this, everything is, you can get over any problem. Because everything you can look at and you can put into context, you can objectively determine what you want to do and you can move the needle and move them forward. So it's a really, really powerful kind of method of growing. The three books I'd recommend, the first one on the left is called The Obstacle is the Way. Whenever I meet anybody, and some of you all in this room have been told this, whenever I've met anybody who's been going through a bit of a tough time, like they're looking for a new job or they're having difficulty at home or whatever it might be, I tell them to read this book. Because this book basically says that in every difficult thing in the world, there is an opportunity buried in it that we can learn from. I'll give you a quick example. Years ago, I gave a talk, I gave a keynote to Oskon. Is Steve Wally in here? No? Bastard. Sorry, Jack. I keep forgetting Jack's in here. I gave this keynote and it was terrible. It was 10 minutes long. And at the time, I had no idea how to deal with like a 10 minute presentation. All my presentations were like this, like where you build up a story and you kind of get to it. And I gave this keynote, it was awful. It was really bad. And you know, people were nice. I thought, oh, that was great. No, it wasn't. It was terrible. And I came off that and I just, I was gutted. I just thought, I completely screwed that up. That was a big career opportunity for me and I completely wasted it. I didn't do what I should have done. And Steve came to me afterwards. He's been a friend of mine for many years and said, look, some people are good at writing novels and some people are good at writing short stories. You'll better write in novels. And you just need to fix that. He said, think of this as an opportunity, right? You'd now have that information in your head. You know, don't think about the negativity. Focus on, you now have the information. So I went away and I read books on how to do short talks and I watched loads of presentations and I gave another keynote about six months later it was 10 minutes long and it went really well. And that to me is a tiny example of like there is something buried in every obstacle. So when the worst thing is happening in the world just focus on that. The one in the middle, this is the first book that I read where I discovered about Stoicism. I thought was gonna be one of those horrible Tony Robbins self-help books. And this is really good. When Bill Clinton was president, he invited the guy who wrote this, Steven Covey, to go to Camp David to teach him how to implement this in his presidency. And this basically gives you seven practical implementation methods for Stoicism to help you to be successful. And then the third one is called The Daily Stoic that I actually got just a little while ago and this is essentially, it's a Stoic principle that you can read every day. And it just, the whole point of Stoicism is you've got to practice it, you've got to do it, you've got to be constantly engaging in it. And there'll be times when you screw it up as well. So Stoicism I think is a really important thing for us to focus on. But one of the most difficult things I think we have to deal with is conflict. Jack has developed something called a bottom attack. Is that right? Do you know what a botty attack is? No, liar. Okay. Yes. You do, don't you? Now with conflict and difficulty when we're dealing with, like typically conflict from what I've seen is related to two key areas. It's either related to feedback, getting feedback from someone about something and making decisions. So you see conflict all the time in the open source world, people rowing about, you know, why are you making this decision stupid? Unity sucks, blah, blah, blah, blah, blah. And then you've got feedback which is, you know, I think you're terrible, I think this was terrible. Your video sucked, blah, blah, blah, blah, blah, blah. And what's in my mind, what's important to me is that we have to remember that, again, this is a bit of a stoic approach, is that at the center of pretty much all of this are words, right? And words are important, but I grew up with this thing. Sticks and stones may break my bones, but what? Sticks and stones may break my heart, but words will never, I couldn't paste that from the internet, the internet was wrong. But sticks and stones may break my bones, but words will never hurt me. Appears to be a philosophy, a method that some people don't approach anymore, people don't use anymore. And I think when we look at that kind of critical feedback, and we look at those, you know, people being difficult in decision-making situations, it's important to realize that we can take those words, we can process them, we can take the stoic approach, and then we can react to them in the way that we want to achieve the outcome that we want. As an example, when I was a canonical, we got a huge map criticism about unity, as you can probably imagine, right? And some of it was pretty brutal. I mean, some people said some pretty horrible things about Mark Shuttleworth in particular, but it was words. And I think when we look at that, it's easy to look at those words and to just immediately absorb them, and then they affect your emotional character. And then again, it doesn't help you to make the right kind of decisions. And what's interesting is that when we look at how we perceive words, there's lots of different things that can play a role in why people write and comment in different ways. So for example, age, you know, there are some people in this room who are younger than others, some people in this room who are older than others. And I'm 37, as I've got older, one of the things I've learned is, the way in which we use words, the way in which we act to words, the way in which we converse, it changes considerably. There is something about wisdom, right? Is that we do grow and improve. So, you know, when you get some critical feedback from someone who hasn't been through that journey yet, then it's easy in my mind to say, you know, I'm not gonna judge that too badly because that person's, you know, 17, and they're still learning, right? It's easy to look at that comment and say, how dare you say that thing? But I'd rather look at it from the perspective of, you know what, you're 17, you're still in the process of learning, evolving, of growing, and I should count that in mine and still let it bother me. There are other elements such as gender, right? Obviously, a huge source of discussion in diversity, right? And I think it's something that we should, in my mind, this is more about understanding the target of those discussions is, I see a lot of men who will say something and they won't realize that that will be interpreted differently for a woman than it will be interpreted for a man because of various, you know, elements like discrimination and, you know, life experiences and things like that. So it's just, again, something we need to bear in mind in the way that we communicate with people. Culture plays a huge role. There are some people in some countries who will communicate very differently to people in other countries. Even in the US, people on the East Coast, way more direct than people on the West Coast. On the West Coast, everything is awesome, okay? On the East Coast, some things are awesome, okay? And I like that. I like the fact that we have that but that's, again, a consideration that we should take into account. Another one is social skills. Amazingly, a lot of people who work in technology, not good social skills. I don't know why this picture is there. Seems weird to me. Some people just don't have good social skills and it's, again, it's easy to kind of see something and say, that was terrible, I'm gonna react negatively. I'm gonna challenge that. And then when you think about if that person's particularly, you know, if they've got a set of social skills that they can count on, then it will be weird but if they don't, then you can't really hassle someone for something that they didn't have to kind of help them to handle that more delicately. And then experience. This is what you do if you type in experience into Google images search, by the way. You get this kitten, I'm not entirely sure why. And experience plays a huge role in the way in which we react and the way in which we react to conflict towards the way in which we manage that. Some people at the beginning of their career will react in a very different way to people at the end of their career. I'll give you an example. I'm working with a financial services organization to build an internal community. The woman who I'm working with is my counterpart there is absolutely brilliant. She's fantastic. She's doing amazing work. But she's never done this before. And each of these points that we do in this work, so for example, we're talking about infrastructure at one point, and she's getting a lot of pushback, a lot of difficulty from the infrastructure team. And she doesn't know that that's perfectly normal because she's never done it before. But I know from some of my prior experience that is just part of the way this is going to work out. And then when she does it the second time, she'll know that's perfectly normal. And that, again, plays a big impact in all the different elements of behavioral economics that we talked about earlier on as well. So the way I tend to approach kind of conflict resolution here, and this is the way I approach it with Jack, is the first thing is to really associate with the feedback. Like, if Jack comes home and he's angry about something, the first thing we'll say is, first of all, kneel down, so at his level, so he doesn't feel like I'm powering above him, and I'll say, are you frustrated? Yeah, I'm frustrated, Daddy. Why are you? And he'll say something, I'll say, well, yeah, I can understand why that's frustrating. I couldn't understand what's annoying. And just listen and let him talk. And then acknowledge, I appreciate the fact that you feel that way. I get that, that must be annoying. And then what I'll do is try to offer solutions, say, OK, well, do you think this would help? Or do you think this would help? Do you think this would help? And then he'll say, yeah. And then we'll start making a plan. And then I'll help to support him in that plan. And that's the way in which we apply conflict resolution to adults as well. So in conclusion, I love this little boy. And I mean, he's phenomenal. And he's taught me so much in just four years. And my theory here is this, and this maps to open source, is you take a person and you help them to be the best that they can be. And one of the elements here is helping to guide people in brave directions, helping them to kind of challenge themselves, helping them to challenge their fears, and supporting them with the stoicism that we need to kind of guide them through those new challenges. We help them to learn new skills. And part of the pleasure of skills, it's not just about learning the guitar, about learning to code, but part of the pleasure is doing that with other people, is being collaborative. And when you get that right, you get more rescue bots. Is that we provide people with incentives and rewards and validation, which is not just material gifts. It's not just challenge coins and t-shirts and badges and all this kind of stuff. It's validation. It's appreciation. Not really related to open source, but you've got to have a good taste in music as well, but in my mind, throughout all of this, throughout all of this theory and practice and evolution and learning and growing and things like that, you've always got to be able to look at yourself and pull funny faces in the mirror and not take yourself too seriously as well. I think when you get this right, ultimately you cultivate communities or you cultivate people that just bring huge amounts of pleasure to lots of different people. Thank you everyone. All right, we have a few minutes for questions I think. And if anyone wants to ask Jack a question, you're welcome to. He's not. Jack, I'm so proud of you. You've been sat here quiet for the whole time. This question is for Jono. Which is your favorite character on Paw Patrol? Chase. I love Chase. Do you like Chase? Jack, do you want to come here? Can you come and see everybody? Come on, give them a bit of motivation everyone. Come on, Jack. Do you want to come and see everyone? Who's your favorite character on Paw Patrol? Okay. Any more questions? Is there another way of equating stoicism with what mindfulness practice to? Yeah, I think so. I mean... I mean, it's same ideas like being able to, you know, not react, not be reactive, but also just to kind of step back and say, okay, what's happening there? Yeah, I think so. I mean, I think I've only done a bit of mindfulness and I think it's incredibly powerful because one of the things that in my mind is good... My mind is good about it. One of the things in my mind is good about it is it gives you a chance to step back and to focus on what's important. And are you not in my microphone? You're not in my microphone. He's laughing by the way, he's not crying. So I think one of the... You okay? All right, I'm gonna put you down for a second. Okay. So one of the things that I think is cool about mindfulness is that... Is it... Do you wanna go down? Do you wanna go back to mommy? Okay. Is... There you go. Is it gives you... I think it gives you an opportunity to, yeah, to focus in on those different pieces. And one of the things that is key in, for example, seven habits of highly effective people is about... He talks about some things require a lot of urgency and some things require a lot of... Some things are important. And the things that we invariably don't focus on are the things that aren't urgent, but they are important. And that, I think, is a big chunk of the mindfulness piece, is that we... Is it gives us a chance to step back. And there is the physiological element of that, of course. But part of it, I think, is helping us to step back from all the urgency and the noise and the clutter to focus on what those important things should be. And I think that's one of the reasons why this is so powerful is that I think the people who are most successful in whatever they wanna do and how they define success, the people who understand what's important, they can focus on those things, even at the expense of the urgent things as well. Where does getting things done and all that come into play with this, I mean, as far as prioritizing and evaluating tasks and the things that come in, has that ever come into play with some of the work you're doing with organizations? Yeah, I mean, getting, that's actually a really good question. The question is around, how do we prioritize and get stuff done? This is one of the things... One of the things that I... I was actually talking to Lisa about this earlier today. One of the things that when I started out consulting, what I primarily did was I'd worked with a company and understand what they were doing. And then I basically build like this 50 page, really in-depth report. It's basically the art of community written for a company. And I did that because I felt like they needed that level of comprehensive detail. I want them to have all of the information they needed to build something out. But then they faced the challenge like, how do we put this into action? I'd provide priorities and things like that. So increasingly what I've been doing is focusing on, okay, part of the reason why I like to define a set of key themes when we do a new piece of work is so we can define a series of different objectives that we want to work on. And then we can tie them to a much shorter cycle. So we can say, okay, what do we want to accomplish in the next month, for example? Because I think that the big challenge with communities and community leadership is there are such a myriad number of things that we can do if we look at infrastructure and social media and content and events and all this kind of stuff. There's a million variables. And that's why I think it's always important to get to the heart, to get that same cognitive model of what do we want to solve? What do we want to accomplish? And then tie that to a shorter release cycle. So now some companies will still want this, but now I don't tend to write as many 50 page reports. It's more like, let's build a year-long strategy at a high level, but then let's boil that down into something very specific for the next month. And then that gives people an easier thing to wrap their heads around. I think I've got time for one more. We actually have enough time for two. Oh, two, okay. Hey, when you talked about rewards, you talked about balance and over-rewarding. Does order matter? Like do you have to do intrinsic first versus extrinsic, or does it really matter? The way I tend to think of the balance between extrinsic and intrinsic is, what I like to do is, so the first time you go through that on-ramp when you make your first contribution, an intrinsic reward is critical, like that validation. It's amazing how powerful it can be when someone contributes to your community. Let's say they submit a pull request and it gets merged in, and the CEO or someone senior in that community or senior in that community just drops that person an email, not a form-generated email. Just say, hey, I just want to say thanks for that. It's really cool. We're really happy that you're a part of our community. That requires no work or very little work. But then what I like to do is to look at that journey from new to regular to core and drop in lots of individual little incentives. So as an example, the way I tend to think of it is, when you've done something five or 10 times, you're becoming like a long-standing community member, depending what the thing is. So at that point, I think it's good to drop in your first extrinsic reward. So as an example, one of the things with a client that I work with Hacker One is people submit security reports for vulnerabilities, is when they've submitted about five to 10 reports, then we'll drop them an email and say, hey, we love what you're doing. You're making the internet safer. We want to send you a T-shirt. And I think if you drop those out at different intervals, it then creates this... In my mind, people should never expect them because then you build entitlement. They should just be surprised with the extrinsic rewards and then a constant stream of intrinsic kind of validation. So in the art of community, you talk about one of the keys to building community as establishing a shared mission. I'm wondering if in your recent consulting work with various companies, you've noticed a trend of shared missions that go beyond the immediate sort of technical task. That's a really great question. I wouldn't say the shared missions, but there's shared goals and objectives. I mean, at a broad level, people just want engagement. The thing that I'm really excited about, like when I started doing this, one of my main goals in my career is I want... My main goal in my career is I want the world to understand the value of community leadership and collaborative kind of participation because I think it's how we make the world a better place. And it's amazing to watch how important that is to more and more companies and more and more organizations. But I think the way in which they define the goals there are typically around numbers. Want more users, want more this, want more that. So I think we're starting to see a bit of a trend to we want more long-lasting, fulfilling kind of participation as opposed to just numbers. But that's not really mission, I guess. It's just like a lot of the companies want the same kind of thing, like when I'm working with them. They just want it in different areas, essentially. All right. Thank you, everyone. And Jack, thank you. Okay, is it? Okay, testing, testing. The devil went down to Georgia. He was looking for a sole to steal. Are we good? Yeah. Okay, because I wasn't done with my... Okay, thank you for coming. So this will be an experiment for me because I'm using a new little travel Chromebook for the first time. So hopefully this will all work out well. But thank you all for coming. And I made sure the room was brisk to keep everyone alert since it's late in the afternoon. So if you get chilly, just move forward and cuddle up, like move in, and we'll get through this. Okay, and then also this article, you don't have to frantically take notes if you find like some tidbit of wisdom in here, whatever, I publish this on our website, opensource.com. And so there's a link to that. So a brief background for me. My background has all been in tech writing of some sort, journalism, tech publishing. I've been an editor and a writer for quite a few years. I've worked with people from all different kinds of communities in Linux and open source communities with different roles. I've worked with professional writers and journalists. And I've worked with people who needed to write for their jobs, but didn't want to. And then I've worked with first time writers. And so that's kind of the background on what inspired this talk to begin with is I wanted to provide some tips I've picked up over the years on how to streamline what you're doing so that you can repurpose something you write and use it for multiple projects, perhaps, you know, or multiple audiences without having to rewrite different pieces over and over. So I wanted to show you how to kind of streamline what you're doing and do the least amount of work and get the most effective piece as a result. So before you start writing, there are a few tips I have for things that you should consider before you dive in. You need to think exactly what you're writing about because you're gonna need to have a nice focus on it so that you don't end up writing a book when you meant to write an article or you don't end up writing a book when you meant to write one documentation for one part of your project. Make sure you know why you're writing about it. Be very clear on what your goal is. What is the purpose of the thing you're writing? Is it because you want people to contribute to the project that you're working on because there's gonna be some vital information to make sure you include if that's your goal or is it because you want other people to write about the project? You're writing something that you want other journalists to pick up on or you're writing just to raise awareness because you want people to test your project or your code or to grow your community or whatever. So be very clear on what your end goal is when you get started. Think about who your reader is, what kind of knowledge they need to have coming into reading your piece, what level of expertise or what bits of information are they gonna need to know? And then is that gonna be information you need to provide or do you wanna make sure that you just provide links to those sources and references so they can get that bit of information? For example, before you get started you need to have this, this and this installed. Well you would also want to provide links so they know where to go do that before they come back and read your article or documentation or whatever it would be. And then think about will you be reusing this content? Is this something like do you need to, let's say you have an update on a project you're working on, do you need to let managers know the status, you also need to let journalists know about it, you also want your community to know and you also want developers to know. If you need to write for all those different people, know that in the beginning, think about that in the beginning so that you can have that in mind when you're doing your research and your outlining, you can be multitasking as part of that process. And then you're gonna need to be thinking about what kind of research is gonna be involved. For example, if there are bits of information, somebody would need installation instructions or whatever. Are you gonna need to go find that information so you can provide those links for them? Or if there are areas that you're not strong on or there's documentation your project has elsewhere, is that the kind of research you're gonna have to do in advance to have that information ready in the piece you're writing. And then creating an outline. If you haven't created an outline in a long time, perhaps you did it in school. That's when I learned to do it in elementary school or junior high or whatever. And I remember I hated it and thought it was stupid and tedious and too much extra work that you didn't need. It actually saves you a ton of time in real life. And before, unopensource.com, where I'm working now, before I have writers write for me, I often will ask them when they send in their ideas, you know, what does the outline look like? What's a sample of what you would be covering? You know, how do you see this article looking? It doesn't take a lot of time to not get an outline, but it can save you a lot of time in the writing process and keep you focused so that you don't accidentally go off on different tangents. So I'll go into that a bit more too. And then, so you've done all this, then you start writing. And then after writing, you'll revise. So this is a bit of a preview of what I'll cover here too. And I plan to leave some time at the end for questions. If there's a question that really can't wait, raise your hand or whatever, but otherwise I'll take questions at the end. So here are a few examples of some what's and why's. You wanna let your community know about a bug fix or security update, or you wanna provide a project status update to a manager. You wanna tell developers about a new process for submitting patches, or you wanna inform the press about a latest release. And so these are going to be different audiences also. You're gonna have three general audiences. You'll have your lay audience, you'll have your managerial audience, and you'll have your experts. The lay audience may not have any special knowledge. They may not be super familiar with their project. They may not be open source experts. Maybe they're just getting started and want to know more about what your project is. What does it do? Is this something that would interest them or is it just for more experience to sadmonds? So that's a completely different type of topic than what they're actually hunting for. The managerial audience, they may or may not have a technical background. And so, and then what they wanna know about the project will probably be different than if you're writing to a developer audience. They're gonna wanna know, is the company getting what they wanted out of this, or are we on budget or are we hitting deadlines and that sort of thing. And then the experts will be the most demanding audience and they're the ones that are really going to be looking for factual errors maybe, or additional information. So, your tone and the kind of content you would include would be a little bit different for that audience. Okay, so the press. There's another audience. That's a completely different audience and I won't go into detail on what to do if you're writing for the press because I recommend the care and the feeding of the press and provided a link here and the link I provided earlier with the article on our website has this link in it. This was compiled by Esther Schindler and some other contributors to the Internet Press Guild and the Internet Press Guild is an online networking community of tech journalists. Before you ever write a press release, I highly, highly recommend or if you haven't read this lately I recommend that you read the care and the feeding of the press because it's a bunch of journalists telling you exactly what they want and the information you send them. So, if you want the press to cover your project or your company or your product or whatever, go read this and they provide an outline and etiquette for writing for the press. So, I won't go into details really for how to write for the press because they're a wonderful entity that has already provided a document for you. So, on opensource.com, we have quite a few different kinds of audiences. Our site covers open source in general and so we cover topics for new users, people who are just learning about open source. This may be their first encounter with open sources coming to our site but then we also have a lot of sysadmins and advanced developers who read our site, a lot of managers, people who are working in multiple communities. And so, documentation is another topic that I won't go into a whole lot in this talk but we ran this article on our site a couple years ago. It's how to write a manual worth reading and it's not going to tell you everything you need to know about writing a manual but it provides many other links. Rich Bowen wrote it, he's here. I saw him give a talk at ApacheCon a couple years ago and after the talk I was like, that's a really great article and it would be a great resource to have online so people can go and get those links. So, if you need to write documentation, I recommend that you start here or there are other guides online too on how to write documentation. Write the Docs is a wonderful resource. They do write the Docs and read the Docs and those websites are wonderful for writing documentation. So, I won't go into a lot of detail on that either because they literally have entire books and conferences about writing documentation because that's a very big project. But, so I won't go deep dive into documentation. So, you've defined your audience. You know whether you're talking to people who already have expert knowledge or you want to write for the press or you want to write for a more general audience. So, let me dive into the theme here, the Stephen King theme. I have been thinking about writing a completely different type of content for a different audience. I've been thinking about writing fiction for the last couple years. I haven't written fiction for quite a few years. That's what I used to be passionate about but I've been writing technical stuff for so long. I don't know that I have an imagination anymore. And so, I read this book on writing, A Memoir of the Craft by Stephen King and I still haven't read any fiction but I thought this was such a wonderful book. Highly recommend it. It's not a really long read but he has excellent solid advice for writing in general and just practical tips. Like writing is, it takes practice. It's something you do all the time. The less you do it, the harder it is. But he had some other gems in this book that I'll use through this talk of writing advice that I thought really applied to any kind of writing including technical writers. So, it didn't help me with fiction yet but it's helped me at my regular job. So, to be a good technical writer, you know, write about any kind of technical topic, you need to read a lot of content. So he says, good writing requires reading. And you can write if you're not much of a reader but your writing's not gonna be that great. It really helps for you to go, you always wanna be reading people who are better writers that that's gonna really help you and read what your competitors are writing. If you're on a project and you have a competitor, go read what kind of documentation or press releases they're putting out because if they're doing it better than you, you wanna take some pointers and, or if you read it and you think that's not very good, think about what is it that's not very good about that because that's something you wanna avoid in your own writing. So, let's say you're writing, somebody's giving you assignment at work to write. Be clear on expectations. I just had this really interesting conversation with a colleague last week. She doesn't work in my group but she works in a different group at the company and she's fairly new to the company but she's very competent, very experienced, technical, excellent writer. And she was telling me that her first assignment, she just turned in and it was some documentation and they wrote, the manager gave it back and was like, this isn't right, this isn't what I wanted. And she mentioned that she doesn't, one thing that she's noticed is she doesn't have tribal knowledge coming into the company. And I thought this was really interesting and so I told her about this talk and I said, whoever gave you the assignment wasn't clear on expectations but you could have been clear on expectations. You should go back to them and say, okay, tell me what you want. What does an outline look like to you or show me a sample of a previous similar piece so that I know what you actually think it should look like or give me a list of things you wanna make sure that I've covered in here, give me a little checklist. So you have to be very clear on what the expectations are because if someone says document the install process for whatever, that sounds like one thing to me but it might sound like a totally different thing to them and so I would say, okay, give me a little checklist of the bits that you wanna make sure that I've included in here. Yeah, and then read examples. And then if there aren't any examples for your specific project, ask for other examples from maybe other projects out there that what kind of writing is it that they like? Do they want a more casual tone or do they want more old school, very formal, white papery type of tone? So after you've done your reading and you have an idea of an expected outcome, take a moment to consider how your work might be repurposed. For example, this talk, I actually proposed this talk a year or two ago for an event and it got accepted and so then I had to write the talk because that's how people do it. You know, you're like, I have this idea and now I have to go write it. And so for years, I've always thought after I give this talk, I'm gonna write an article about it and I'd never done that before. I never would go follow up because afterwards I'm like, woo, that talk's done. I'm done, you know? And I'm over it, moving on. And so this time, this was the first time I ever did this, I was like, I'm gonna write the article first. And I did, I went to Dublin and my talk was on Monday and so I went on a Friday so I could get the weekend there to check it out but I hadn't written the talk yet so I spent the whole weekend in my hotel room and I wrote the article, but the article was done and what worked out really well for me, I recommend that you write the hardest things, whatever it is that if you're gonna repurpose it, write the hardest thing first because then you've already done all the research and in this case, you know, I wrote the whole article, I had the screenshots ready, you know, for my article, I had already fleshed out the whole idea in my head, I had outlined the whole thing, you know, knocked it all out so writing the talk was super easy after that. I had done all the research, I already knew how it was gonna flow, I could pull bits and pieces out, I could pull images out and my slides were already made that way and so the talk was easy. It was, you know, the article that took a while. So that's what I recommend, is do the hardest part first. Lesson learned for me, it just took me a while but that's how I do it now. So I'm gonna show an example here of writing for different audiences and so opensource.com, the project I work on, it's a community site, like I said, well, we're supported by Red Hat, so I'm a Red Hat employee and so when I wanted to get an example, I thought, well, I don't wanna use a Red Hat project, I wanna hunt for a different company or community but then we bought this Ansible and so, but I already thought this is a good example so I left it in but I really was trying to get a different organization, a different community so Ansible was not into a Red Hat community when I use this as an example but I thought this was a really good one. Greg from Ansible was writing about a new process, he wanted to let developers know about a new process so his audience was developers, Ansible developers, experts on Ansible and so he was writing on a mailing list to tell them about the process and so the message was called new process for acceptance of new modules and extras so he didn't need to define what extras was because the developers already knew about this stuff because they're on the mailing list. So then his colleague, Robin, who was writing for a different audience about the same thing, she was writing on their blog and so their blog was going to be a much broader audience, there's gonna be developers, there's gonna be some general people in the community that are just learning about Ansible or maybe some managers who are using Ansible, the organizations and so her piece for the wider audience was called Ansible Extras Modules Plus You, How You Can Help and so it's not nearly as narrowed down, she doesn't know for sure who's in her audience unlike Greg, who knows exactly who's in his audience as developers on a mailing list and so what she does is she defines the audience in the very first sentence, she says if you're a caring user of Ansible and you meet any of the following criteria this post is for you because you can help to improve the quantity and quality of modules and so then she defines who the audience is because as a reader, if I go start reading an article and then halfway through I find out, oh, this isn't even for me because I don't have the Enterprise Edition and this whole article is about an Enterprise Edition then I've just wasted two paragraphs of my life that I'll never get back, but so at the very beginning she says the audience is your user or a contributor to Ansible Extras Modules or you've been looking for a way to contribute or whatever and she offers a little list of who the audience is going to be and so this brings us to the second lesson from Stephen King. Invite the reader in and that's what she's doing. This is for you, come in, read my article, read my post. So and then a strong introduction helps you, the writer, stay on focused and stay focused and stay on task for the rest of whatever it is you're writing. We see this a lot in opensource.com. People will send in a draft or proposal but if they don't have a strong thesis statement at the very beginning and say in this article I'm going to tell you about this, this and this and you'll learn how to do this. If they don't have some kind of a strong thesis at the beginning, often they go off into all different topics or I won't know until three or four paragraphs in what's your point, what are you even telling me? I don't even know yet if we want this article because I had to read four paragraphs in to find out what you're gonna tell me about because you had a bunch of really great anecdotes and whatever but the very beginning if you say in this article I'm going to tell you how to get started with this new thing that we're doing then as you go through your writing process if you find that you're kind of wandering you go back and remember what did I say I was gonna do in this piece because I'm gonna have to go and do that and all this other stuff either needs to be in a different piece or I can just take it out. So tell a story. Anything that's not part of the story you can take out so if your mission was to tell people how to install a thing or how to get started using GIMP. If I start talking about my favorite music player then I just got off topic and that's gonna get pulled out you know that's gonna be a really great second article we would love to see it on opensource.com submit a proposal but if it's not essential that's the stuff you're gonna pull out you're gonna tell a story. Even if you're writing technical documentation or press release you should be telling someone a story. The press releases I get now from professionals it's rare I see one that is interesting in that first paragraph it should be interesting you're telling a story we have this really cool new thing that I want you to know about make it interesting. So leave out all the boring parts. People will ask me how long an article should be. If you're writing for a print publication that is very important information to have because there's only a certain number of pages they're going to give you because they're gonna have to pay for extra paper you know for extra pages or whatever. So that's when it's appropriate and necessary to make sure you're counting words and whatever. On our site we tell people as long as necessary I will tell them random numbers just because some people have anxiety if they don't know a general word count and we've posted that on our site because we have found that some people just really need to have that information but I'm also a big fan of if you can tell a concise story that's interesting in 700 words you don't need to go ahead and make it 1200 because you felt like it was too short you know and generally if it starts getting too long that's when you think about breaking into a series. Particularly these days people don't really like generally reading super long stuff and those people that do don't mind reading part one, two and three you know and they have that option so. Some of the best advice I ever gotten in my career was deliver content the way people wanna consume it and so if you really feel like you need to give more information go ahead and do a series part two or three you can publish them on the same day if they're you know important for each other but if they're super long you know have them in more consumable chunks I'm gonna read part one and then go get some coffee and then I'll be back and I'll read part two. So for example Greg's post to the mailing list he admits details about developing modules instead he provides links to the module guidelines and because he's not writing for an audience of module developers so he can leave out the boring parts you know he actually needs to just be writing about this new thing that's what he left in and Robin's case she's writing for a broader audience and so you know she defined the audience and then after stating the problem she states the solution and so she says you know folks who keep an eye on the various Ansible repositories have probably noticed that your friendly neighborhood Ansible community team that's myself and Greg and she provides a little bit more information and the boring parts for her she links to Greg's part for some of the more technical details so for the community audience she links to his post to provide Ansible documentation module guidelines and how to contribute there's just a little screenshot and then she summarizes solution and before she dives into the details she's provided you know a lot of us read blogs and news online and you really and ideally only have to read the first two or three paragraphs to really know what the whole thing's about and then if you really want to dive in you keep reading and that's what she does she provides the beefy information at the very beginning gives you the overview and then people who want more information can read further down into the piece so now let me give you a little bit of information on a sample outline I'll provide several sample outlines for different types of pieces so like I said you want a strong introduction you want to invite the reader in you want to provide a beef brief background state the problem so you know in the past again couldn't do this this and this and so people didn't you know weren't comfortable moving away from Photoshop because you know again but didn't have a friendly enough user interface or whatever maybe that's the problem and now we have this this and this so for somebody who might be kind of new you can briefly say a bit of the background and then what the new thing is and then so that's your inner introductory paragraph brief bit of background and then you share the news and then you can dive in and then I recommend breaking that up maybe with some subheads if you're going very far in subheads can provide a bit of a roadmap when people are reading through something that's longer so if you're writing a feature length blog post for example tutorial or how to those can get a little bit longer and that's where you might want to break it up with subheads you know installation instructions you know configuring then then dive into the other sections and then and then conclude in the conclusion you want to wrap the whole thing up provide important dates or action items you know for example if you'd like to learn more you can meet us at the following meetups you know and provide those links or you know we'll be speaking at scale and here's the link to watch the live stream or whatever provide that in the conclusion and then any action items for example this is the the proposal and you know final feedback needs to be submitted by whatever date that kind of stuff is what you're going to provide in the conclusion so depending on what you're writing about you might also want to include additional resources after the conclusion such as documentation links press contacts it's incredibly frustrating to not be able to find any contact information at the very end like where where do I find these people on IRC or Twitter how do I learn more who do I contact if people just send you to general landing page on a website that's not going to help them find you know real people to contact who are the people on the project or community resources if I have additional questions and you don't want me answering them in your main IRC channel make sure you've included and and we have this IRC channel for new contributors to community or whatever make sure that information is very clear at the very bottom of your piece or mailing lists you know to find out more subscribe to our newsletter or sign up for this you know our mailing list the care and feeding of the press which I mentioned earlier they provide a fact sheet of information to include if you're writing a press release I really think this fact sheet is wonderful thing to think about when you're writing anything they have a list of different facts included like what the product is configuration requirements how much it costs you know is there a community version and an enterprise version contact people for the press and and that sort of thing so there's more information on that care and feeding and feeding the press you know but these are the top level bits of information checklist to have to include so after you finish your draft which is probably the night before it's due I'm assuming like everyone else I recommend that you take a break from it and revisit it with fresh eyes and if I'm turning stuff in I generally finish it the night before and then we'll read it again in the morning with fresh eyes because you're kind of over it by the time you finish your draft and you know what you meant and so you need to step away from it and if you have time which I recommend doing this send it to some colleagues or some of the people on the project and have them read it if you're writing to maybe a new user audience it might be good to send it out to some people who are actually new users in your community and have them read it and ask for feedback you know like what did I leave out what questions did you have open source.com we have a list of writers and community moderators on the site and so we can collaborate with them and the writers can work with each other and and share documents and ask for feedback that way you know Google is one way people are doing it some people like to do it and get hub where you can actually get input and so unless you're just writing a short blog post and you don't really care but if you're writing something that's going to be documentation or an article you want to submit to a publication that gets a lot of traffic it's good to go ahead and get feedback and this is also really a great way to engage people who might be new in your community that where they can actually be helping you without diving in and doing you know something they're not comfortable with they can be providing you feedback on you know articles or documentation you've written and they're generally very happy and excited to do that because this is an easy thing for them to do is go read it and send you feedback critique I I like sin if you're gonna have somebody at it and send you feedback don't send it to people who are afraid of you it's in it to people who who maybe you're a little annoyed with you because you're always too brutal with their stuff you know and so I like to make sure I send it to people on my team or people who know me well enough that they know that I can take it if they give me a harsh feedback because you want people who will be honest and say this was a horrible introduction or I have a colleague who has to who cut out about half of one of my articles one time literally about 50% because he was like this is a whole different article and he was right and it was really good feedback but I've also had people in the past where I've sent them stuff and they're like oh that's nice you know and that's not actually really helpful because I thought it was brilliant obviously but I need you to tell me everything is wrong so I can go in and make it actually brilliant you know so people who are terrified of you or afraid of your feelings aren't the best ones to actually give you great feedback and then also keep that in mind I guess when you're giving other people feedback you're not doing them any good by just saying that's nice if they ask for your feedback give them honest feedback you know that I didn't understand this part this wasn't clear to me I think it would be more clear if you did this I thought or I thought it was too cutesy and you're writing for professionals you know I'll get it I'll get it and then don't take don't take criticism personally and that's that's it's easy to say and that's hard to do until you get used to it but you won't become a better writer if you're not paying attention to people's feedback and hearing them but also your name's on it and so you don't have to take everybody's feedback and accept it if you don't agree with them in your names on it as editors for example on open source calm we send the links the articles back to people after we've edited them so that they can review them and sign off on it because their names on it if they don't like it they need to push back and say no that I wanted you to put this in you know or I wanted you to dangle my modifier why did you undangle my modifier okay fine you want to dangling modifier I'll let you have it you know I find split your infinitives it's your article so and I've had these discussions right Vicky I feel very passionately about these things so Oxford comma you're gonna have to take it somewhere else if you don't want to use an Oxford comma I really feel strongly about that but thank you all right so you've decided to write what you're going to write about and you're writing for you've done your research you've sketched an outline you know how to edit whatever you you write so what do you want to do next the scariest moment you can write now you're writing if you know all these things you're going to go ahead and write and so that's the hardest part for me still and I've been doing this you know my whole career is actually starting to write a couple weeks ago and I had actually I've been writing very much on our site the last couple years I've been doing much more editing stuff but I've been kind of missing writing and I had told my team that I'm interested in learning more about machine learning and AI and neural networks and all that because it all sounds cool and I didn't really know much about it and so they're really fine right an article and I was like what so I went and did a bunch of research and so I did the research up front and doing the research was great because then I could find things that looked interesting but I couldn't use for this one article and I just put them all over on a different document you know for the articles I'll write someday and then I had the research and I knew what I wanted to write and still getting started writing is the hardest part every time so but it's the last thing you do and then information about writing for open source.com if you're a first time writer or you're a kind of novice writer if you want to become a better writer we have a small team of editors like I said in the writers and community moderators that will work with you and help you become a better writer and so here's your opportunity to get free editorial services you know and work with a team that wants to work with you and help you become a better writer and then we publish content under a Creative Commons license so you still own your content you can still go put it on your website or share it elsewhere but we would certainly love to work with you and we have many opportunities for writing on the site that don't even have to be technical articles if you want to write about your favorite open source tool or how you got started using Linux your first experience using Linux all of those are can be fun things to write about and our readers really like to hear those stories and we would like to hear them too so thank you. Do I have any questions? Questions about specific things you're working on or writing? Yes? Pardon? Oh okay yeah then yes okay so he's asking if someone if someone if you give somebody something to review and they are being nice to you and you feel like that they actually have more feedback how do you politely ask them to give you more direct feedback right that's a great question and I think it's fine to go back and say okay what things do you think I should have covered that I didn't include were there bits that I should cut out do you think my tone was correct I mean ask them a few questions like that if if you're writing for a new audience like you could say are there bits in here that might confuse some people you know are there links I should have included and I always tell people also you're not going to hurt my feelings you know and so don't worry about hurting my feelings I really want you to tell me exactly because that's not being critical they're not being you know critical they're giving you feedback and that's what you're asking for so yeah I think you were next right right yeah and that's and as somebody as a writer that's where you can help that people who are reviewing for you you can send them you can help be clear on expectations from the beginning say can you double check for these things and make sure that maybe send them a little list of goals you had for that article you know was this clear for someone who's new will my manager be happy with this report you know will people get a good feel for what this event was like because I went to this event you know so that little checklist can help them too and yes okay yeah the question was when you're doing outlining if I thought about using line mapping programs or tools or practices or whatever no I because I haven't used them and it does and that's not part of my process and so doing a traditional old-school outline like I learned in junior high actually works well for me but if that works well for you then I recommend doing that and I have various tools I am yes what tools I use for organizing notes and I am we have started as a team using Trello boards and so I kind of will throw out my ideas on the Trello board for articles I want to write and then I tend to work a lot and just plain text documents G edit is what I tend to work in really bare bones and then I manually put in HTML and that's just part of my process but I've used Google Docs for you know other people other editors who want to meet or eight Google Docs before and then a lot of our writers like to write in Google Docs and that way people can add notes in there I really like to keep it pretty plain and simple and I have a bunch of different text documents where I have notes or now that I'm looking at doing more machine learning topics I have one that's just got a bunch of different links and I'll put in just like little dotted lines in between sections of like this is this the links for the article I'm thinking about here and and then another list of links so I have a bunch of different things so okay okay yeah I'll get another one and we come back to you yes go ahead okay so the question is these different tools like I'm using these specific different tools I think that's different teams and different projects documentation team versus you know developer team maybe they're all going to have their own tool set our team we don't have a tool set everyone kind of uses whatever works best for them and we try to be really flexible with our writers too because we're community publication and we actually we don't have an author budget to pay for content if we were paying a bunch of money then I would be pickier about how you send it to me but as it is now I'm like wadded up and throw it over and we'll take it you know because we want that it to be easy for people to write for us I personally have had been burned so many times for you know it's stuff not saving as a draft if I'm working directly in content management system that's one reason I like to just work with plain text files and I manually click save a bunch you know and just because I like to keep it very simple like that and plus just with fonts getting all screwy and whatever I'd really try to stick with plain text because I've worked with different you know programs over the years where my content would be used on in design or online or whatever so yeah I think it depends on what what group you're in when I was talking to a call a new colleague about the group she's on I made a comment because she's working in documentation I was like you know who sucks at documenting what they do people who work in documentation because they have like no documentation at all about any of the stuff they do right and I totally get that because my dad used to work installing business telecommunication systems and I remember him calling me from a cell phone one time because his home phone system wouldn't work and he's like yeah I've got people over fixing my phone because if it's what you do all the time then you don't want to do it if you don't have to write so yeah anyway so I was like you could be the you could be the person who documents everything for documentation you could be that person and they're going to appreciate you and I think that she might do it now so another question yes good okay yes I do for that because I'm very annoyed by those lists also but other people really like them so the question was like for release notes you know the really least notes will be a bulleted list of all the new stuff for all the fixes and but some people will complain because that's too technical or too much of a list right and plus if you just say bunch of bug fixes that's not helpful I have to say stop doing that if you're says that list with the bug fixes where but so as I said earlier to live deliver content the way people want to consume it I think you should do both and that's again it's repurposing content have that list of you know bug fixes or release notes have have that whole list but then have a brief blog post that's that might be a higher level look at these are the things that you're going to be most excited about in the community behind the scenes we fixed a bunch of bugs including the one that you know screwed up your display every time you close the screen or whatever and so you could do a few highlights and then for the full list here's the link with the full list of all the things you know but just provide a blog post or an article of these are the things this is why you care about this latest release and you know your system is going to be way more secure those are the bugs that you really care about or that sort of thing yes okay so what is this is this for a what is page like what is our project is that we're talking about okay then then you it's an introductory here you might have a series that you would write you would have the introduction you know like what are we you know we are whatever your product is you know and we are the software is intended for you know CIS admins who want to automate whatever you know explain that in the very beginning and and then you know for history of our project read our history section and then maybe have you know a page that's the history or and then a link that's the community page you know of who are the people in your community who are the contributors how to get involved page you know for how to get involved read over here for how to start contributing then you have a start contributing article you know and this is where you can find help that sort of thing does that make sense so you might have to write a series of pieces and connect to them a break it into bite-sized chunks you welcome any other questions okay thank you I've all been a great audience thank you check check check yes all right how's that can you hear me wonderful yeah Jason yeah I think we're good test test settle down settle down I did get sign off by AV that water is okay yeah that's what they approve we're gonna get started this is a Corey Quinn as you all know and don't you know who he is take it away that should be better awesome all right thank you all for coming I'd like to start by pointing out that the title of this talk is the single best way to get into any event ever without paying you show up and you say can I see your badge sir and you say don't you know who I am and they look at you like the asshole that you are and they say no I don't you say great run past them what are they going to do they don't know who you are so my name is Corey Quinn now as for who I am it's gauche if I get up here and tell you it sort of cuts out the entire theme of my talk so I have a few testimonials first who is Corey Quinn so who is Corey Quinn I actually struggled with this trying to tell you all why you should know Corey Quinn it was really difficult and then I realized it's because everybody should know Corey Quinn for example if you like whiskey you should know Corey Quinn because in knowing him you will need to drink whiskey also if you are a fan of Docker you need to know Corey Quinn because he speaks so much about Docker that it is evident that he is fully in love with Docker so there are many reasons to know Corey Quinn and if you came here to see a fun enthusiastic engaging talk well you're in the wrong room because it's Corey Quinn but if you do not know Corey Quinn find him give him a hug because he loves them and you want to know him because Corey is somebody who is willing to mentor and teach and be a thought leader in the industry this is this is me can I shut it no okay that's your space I think this is hard for all of us so I'll just start I think we should remember at Quinnipig as he lived ragging on dogs $9 developers and paradigm shifting message I just saw a guy in a dark suit and I okay Corey is a thought leader that leads beyond the leading edge of thought leadership probably one of the first of us to realize that what comes after get his goats Corey was the driving force behind getting me to talk into this microphone I think it's safe to say that without Corey none of us would be here well maybe physically but definitely not emotionally and after all isn't that why we're here in this industry the emotional connection we gain as a community by running the cutting-edge software the mature teams develop for their highly specialized bespoke cloud environments and running it on the raspberry pi a spark station in our do we know Jen we know and that one dude with an espresso machine so please warmly welcome Corey and influence our par excellence before I met Corey I was in the Palo Alto homeless shelter they only had one charger for mobile devices can you believe it I was down I was out and then I met this man with his incredible thought leader skills and he led me to found my successful start up new to me floss combining the sharing economy and dental products so thank you so much Corey I'm gonna get up here because no one in the back will see me if I don't and I really don't know who this guy is I was hanging out outside and he said if I came up here and said something nice about me by me a Starbucks what the give me that get off the stage thank you one more all right thank you thank you for those who don't know who I am I work for you know anonymous very large tech company now because I work for very large anonymous tech company that means I know what the hell I'm talking about I didn't always know what the hell I was talking about until I met Corey Corey is not only a very seasoned reliability engineer he is a self-actualization engineer and he helped me fully actualize myself as an engineer in various large tech companies if it was not for Corey I would not know who the hell I am let alone who the hell he is by the way this man wrestles bears and it is amazing should look it up on YouTube sometime it's best when I win thank you so yeah that's who the hell I am thank you for that I'm going to put these logos up on the slide because these are impressive companies with impressive logos and just by standing near them it builds credibility for me I don't work at any of these companies but somehow that doesn't matter because just by standing next to them suddenly people take me far more seriously I want you to think about what my application my code and my environment all look like it is god damn paradise it's beautiful contrast that to your environments the shattered hellscape that you call code how are you even in business about this time many of you are thinking it's time to quit your job and go raise goats which is fun because some people I know at one of these companies raise goats part-time I don't know how that works let's get those logos back up there to shore up my credibility some more obviously I am far better at solving these problems in your team is because I theoretically might work at these places that's messed up and I've been thinking about this for a while until I saw a talk last year that finally clarified this and convinced me to build this talk at devops days Boise there was a talk given that was absolutely fantastic this is the description of that talk no I'm not going to read it to you I'm assuming people here mostly literate he's a fantastic speaker and the talk match this it was subtle it was nuanced it made some very good points that sailed over the heads of a good portion of the audience and he had some great points that he brought up during the course of this talk he mentioned for example that all developers at Netflix have access to production you may gasp at this I gasped at this please gasp thank you and the reason that they're able to do this made a fair deal of sense because what's baked into their culture is that they trust people to do the right thing that's a good premise to work from you you trust people good and this all works because Netflix from their culture deck is big on the concept of freedom and responsibility and this sounds awesome that by midway through the talk yeah this sounds great the guy next to me says that yeah he wants to start giving his developers access to production and good for him I sneak a look at his name tag and fucking hell he works at a bank excuse me I have to make some changes to my banking choices there we go so either that guy missed something or I did but what we'll get back there this seems like an opportune time for us to talk about the indigenous cultures in the Pacific Islands more specifically in the 1930s and 40s war has broken out in a global scale and these islands suddenly become staging areas for some of the largest armies that the world had ever seen this incidentally is true and the indigenous cultures hadn't seen anything like this ever before they wind up with massive amounts of war supplies being shipped in and airstrips are springing up in a matter of days giant supply quantities are coming in and they saw this happen again and again and again so they take a look at this and they do what any of us would have done they went to hacker news to reconstruct everything they see from first principles like any good tech startup does they see airfields get built goods show up a bounty from the skies and they build models from wood of airplanes and buildings and entire airport complexes and wait to see some of the bounty show up for them it didn't work so well this is a concept known as a cargo cult yes it's real and this happened because they confused cause and effect airports didn't need the supplies the supplies need an airport to get where they were going if you cherry pick from what you see you just sort of hope for similar outcomes it doesn't always work to bring that metaphor back around devoid of context we're all inclined to do this these islanders were in no way stupid and neither was the guy from the bank sitting next to me in that talk what happened was that they missed the larger context of world war two and it's accompanying logistics or the larger context of the constraints that netflix has to work on so let's go back to netflix is point for a second here and fill in some context that we missed specifically through a few slogans that I made up for netflix that they're welcome to use that help explain some of this based upon a number of conversations I've had with people there it's a lot easier to trust your developers with roots in production after they've got a decade of experience who here was junior and screwed the production pooch by accident once wow what an entire sea of hands suddenly I don't feel nearly alone wonderful I did I was in my first Linux job and I was playing around on staging and because we didn't really have stack overflow back then I copied and pasted from other places so there was an arson command with a delete flag whoops a doozy turns out that it paved the entire staging machine that someone left the production that mounted on this is taking a lot oh my god and so I panic I call for help people look at this we got most of the data back but not all of it a couple of days go by and then I'm called into the VP's office like oh boy time to get fired and he only asked two questions do you know what you did yeah is it ever going to happen again no well not like that and he said that's all I wanted to say we appreciate your work or you're doing good get back to it so Shane from everbridge thank you I learned a lot from that including my management strategy years later but I'm not nearly as careless or as junior now as I was 10 years ago imagine that back then there's no way in the world that Netflix would hire me and right up until now at this point until I gave this talk and started putting the boots to them they might have Netflix also pays absolutely top of market salaries even by Bay Area standards we're talking ridiculous amounts of money and by doing that this enables them to buy us for things that not every company can do they can screen not just for technical ability but also good judgment this is great and it's awesome but did you ever notice that whenever people go through the official published Netflix culture deck they pick and choose all kinds of different points but never this one huh that's funny and lastly let's talk failure modes you not being able to stream the latest episode of House of Cards is at a different place on the spectrum then everyone's bank balance is now inaccurate on the ATM when you're looking at that on the scale of should we take to the streets and riot I didn't say which was in which position and I've taken engineers from all four of those companies out for drinks at various times and the entire time we were out they complained the entire time about their environment everything sucks and nobody talks about the bad parts I tried to in a talk that I submitted for this but their talk but the acceptance committee turned it down and apparently apparently it wasn't uplifting enough they said it was too sad they said it was depressing they said it was a terrible submission for the scale youth track and frankly they're more than a little concerned that I had the temerity show up to the conference at all after that stunt I digress our environments are all terrible because we have constraints that shape our choices time money number of people you can throw out a problem business goals your business model we're all trying to do more with less the best that we can unless you're Travis Kalanick the CEO of uber nobody shows up to work planning to do a shitty job today I really hope at this point it's intentional because at this point it's borderline performance art we all want to do a good job but we have constraints the point is that constraints shape our choices and the speaker here on the stage talking to you about their environment isn't generally going to talk about their own constraints let alone what your constraints are the person here giving the talk is human we're telling stories from our environments with the hope that it serves as inspiration we're not expecting it to serve as a blueprint for follow these steps and then you'll wind up with an environment just like mine ultimately sometimes we fail to communicate that as speakers we are fallible but so are you it's not always the speakers celebrity that's a problem sometimes the danger comes from the audience that's right that don't you know who I am asshole might be one of you I'll give you an example five years ago I saw it great talk at a conference it was genuinely great it talked about provisioning strategies and how to approach it philosophically and it was a well-delivered talk that was terrific for a lot of reasons not least of which because docker didn't exist yet so you don't have a see a smug assholes telling you you're doing it wrong and the speaker was from the Department of Energy and he admitted this is my first conference talk it was a little obvious he based on the nervous he was but he killed it and he talked about how they were solving this problem at the DOE it went really what well right up until the Q&A portion at the end of the talk does anyone have a question and someone does yes you sir that condescending looking fellow in the back what's your question and the question was that's not how we do it at Google so let's unpack this short sentence like the remarkable bullshit onion that it is in fact let's interlude here for a second I as a speaker have certain responsibilities to fulfill in my role as a speaker I have to have content that at least vaguely resembles what the prospectus says I need to show up on time there's a remarkably strict must wear pants policy the list continues and as an audience you have responsibilities as well including asking questions at the end make a note there will be a Q&A section let me help you out for a second with a list of things that aren't questions such as I don't know calling bullshit on the entire premise of my talk while remarkably on point for most of the talks that I give is still not a question neither is telling a pointless story unless it's necessary to set up the premise for your question if you do for God's sake keep it brief and your resume is never a question no matter how dramatically you choose to read it that's not how we do it at Google is rare because it manages to hit all three of these points in one short sense I know a condescending engineer who works at Google try to suspend your disbelief again this was the speaker's first talk it wasn't helped by the fact this guy was visibly nervous and didn't really know what the hell to say to something like that why don't people ever pull that crap with me I'm hard to rattle that's right my talks don't actually solve anyone's problem but I want to address the merit in the substance of the question rather than the shitty delivery do these two things look alike to you for those who are unaware of what the Department of Energy does such as the guy they just have to run it God help us all they do a lot they handle a huge array of tasks such as managing the country's nuclear arsenal they run a good portion of the world's supercomputers and they do a surprising amount of work with genomics this is important stuff whereas Google's responsibility is organizing the world's information they sell ads against that and of course killing services that people are actively using good luck to those of you using Google cloud I'm sure that story is a happy ending the point is is that different problems are being solved in different ways by different places but we're going to give the jack wagon in the audience the undo amount of credit simply because of who he is and where he works and okay now what let's even take that a face value what do you expect do you expect the speaker to hang on let me edit my slides on the fly and change the theme of my talk hang on while I edit this to reflect my new conclusion besides that's my talk I'll get your own and what about the rest of the audience because that's really what it comes down to it's not a one-to-one discussion here just from that condescending statement people now start throwing away the very salient points that were brought up during that talk about how the Department of Energy solves these problems the journey that they took to get to where they are and instead focused on how a big tech company solves these problems devoid of any of the context or the appreciation that their own business models aren't running a giant search engine or turning off things people are using most of you don't work at these companies and for those of you who do be careful about what you say and how you say it and whether or not you're punching down I'm making fun of you because you can take it you've won and it's important that you recognize that the weight that your word carries because of this bullshit imbuing me with the authority of your company approach I didn't even work there and I have to worry about that now the rest of us we don't have the problems that these companies have we don't have their constraints and we certainly don't have the resources so let's stop trying to cargo cult all of their solutions they do an awful lot of good work and that work is very often stuff the rest of us can leverage to solve our problems but without context it's not going to magically solve our pain so let's stop pretending as a great case and point the simian army slash chaos monkey is a service that netflix wrote sorry an open source project that netflix sponsored a while back and what it does is it randomly kills individual instances or sometimes entire regions to validate that they can fail over safely between different environments they have no single point of failure and they've been talking about it for years in condescending talks just like this one they're rightly very proud of this and we've heard about it for ages and we've all seen this talked about and as a result we've taken its lessons to heart to completely eliminate single points of failure in our own environments all of our sites don't go down anymore when a single amazon region has an issue that's good tell another one of course that's not true one service in one region went down this week and everything from instagram to american airlines to amazon's own status page shit the bed yes netflix stayed up good for them in 2015 according to their annual report they spent six hundred and fifty million dollars on technology and development half a billion dollars a year let them avoid a two-hour s3 outage good work the rest of us weren't so lucky this is ok most of the internet was impacted and rearchitecting your entire stack to avoid a black swan once every seven years style of event during which most of the internet is down could potentially double your costs at least and if you're running something that puts people's lives at risk if it's not available do it if you're running my side project twitter for pets maybe that two hours of downtime is ok maybe that's better for it parts of my environment we're down that's ok this talk is subtitled the dangers of celebrity and tech and that's intentional because those dangers are real I'm not talking about dangers to your environment and I'm not talking about dangers to your application because I genuinely don't care what I came here to talk about is the dangers to you as people it's difficult to build something that you're proud of and then a tech celebrity on a stage craps all over it you wind up feeling like complete crap and you really shouldn't because you built a thing that works for you and I'd be shocked if the guy who gave the talk the Department of Energy wound up giving that talk again I want to believe that he did but as a speaker myself it's hard it is difficult to get up here and talk about a thing it's scary and if someone craps all over it your first time out it's almost unthinkable to get back up and try it again so when you see a good talk on kubernetes or agnostic provisioning or whatever it is that excites you think about context behind that what are they showing you what are they leaving out and remember they're not you counterpoint you see a terrible talk that misses the point and can't ever work are you sure is it actually wrong or is it just wrong for you in your use case in your problem space comes down to a concept of empathy where you get to be the person that you'd want them to be if the roles were reversed if the shoe was on the other foot you see a new speaker appears sweating bullets terrified to be speaking at all good from a softball question be kind because here's a secret tech isn't about the tech it really never has been out of his heart it's about the people and from either side of the stage you should never walk out of the room at the end of it feeling shitty this has been don't you know who I am my name is Corey Quinn and now you know a little bit more about who I am thank you a couple points of your rather tonight in about an hour and a half there's upscale which is a series of ignite talks a bunch of us are giving one I'm talking about my amazing architecture and how I run the infrastructure that powers Twitter for pets you should come are there any questions about the rest of the talk questions comments thoughts yes in in slow pitch softball how do I throw good good how do I throw it poorly thank you I hire people for that yes can you tell us more about Docker can I tell you more about Docker it is a fantastic solution for some use cases whether it's good for yours that's something for you to decide so this is actually a real question so thank you what an amazing change does it start with your resume so in that say that we were in the audience of a talk that that department of energy talk mm-hmm and the persons stood up from Google and did that is what how should the audience should one should the audience do anything in response to that and if so what should it be that's a great question and I think that's going to come down to the people in the audience I'm I'm I'm torn on that one because if you see someone standing up and doing something like that as an audience member on the one hand you don't want to devolve into a riot you sort of expect the speaker to wind them down on the other you also don't want to watch a bloodletting and watch someone floundering my approach has generally been in those types of situations to sort of interrupt with sorry I have another question and then throw something completely unrelated and ideally stop the flow of nasty of course other questions comments thoughts your resume disguises a question okay I sat through this thing like you asked me to what are you going to take me to Starbucks again oh good good good there we go yes the awesomest thing I've seen all that thank you appreciate that I work for you thank you what would you give for advice for people that work at the company where you screwed the pooch as a junior sorry what context because here's a sport you saw the hands we've all been that person what advice for oh oh yeah sorry that you have to do resume took me a second yeah there we go yeah don't leave netapps mounted on staging production netapps mounted on staging environments you'd think this would be obvious and it is in hindsight I have Corey Quinn you should know who I am thank you all for coming