Faking Coherence for Engineers
Lam, Yvonne
Many of us have kicked ourselves after giving a bad explanation of a familiar topic or sounding less than competent when discussing a less-familiar one. This talk will cover how we improve at sharing what we know and at being clear about what we don't know, both as individuals and as teams.
 Hi. Thank you. So, I forgot to do my forced breath breathing. Oh, well. There's this breathing exercise that we learned to calm us down before we speak. And it just went in one ear and went out the other. Sorry, Anna. So, that's me. Hi. I'm Yvonne Lam. My Twitter handle is up there. Release Engineer is not a specific title at Chef. We ranked along the SDE track. Basically, I just tell people I'm a release engineer because it's shorter than saying what I do, which is that I work in the team at Chef that does internal tools, CI, CD. And we basically manage all the infrastructure for building, releasing, and publishing software packages that Chef uses. So that's what I do. Everybody always says when I say a lot of things, but really that, wow, that was really meta. So, that's the kind of talk this is. It's kind of who I am. I've decided to own it. So here we are. So, what is coherence? I realize this is kind of a weird title. I mean, it's kind of a weird talk topic. So, I'm going to take a couple of minutes and lead us into it. So what is coherence? Well, I think of it really, this is my geeky definition. I think of it as getting the right amount of information into the amount of bandwidth that you actually have available to convey it. So I think of it as kind of a packing problem, right? Like that it's like, okay, so you're interacting with another person or a group of people. This is how much room you have to tell them stuff. How are you going to tell them stuff efficiently? Like what choices are you going to make around that? Coherence isn't exactly easier to define, but I think it's really recognizable, right? You all know when you get that feeling that it's like, oh, God, I've just told them a whole bunch of stuff and I'm not sure if they took any of it in, right? Like anybody here ever not feel that? And I know that when somebody sort of loses track of their train of thought with me, that my response is like, okay, I know they're trying to be helpful, but now I'm going to have this bunch of stuff that I need to fish through to figure out what in that is actually going to be useful to me. And I'm not necessarily sure that anything is. So I mean, it's a little bit of a loaded description, right? I mean, because sometimes you really don't understand something and you really do have to sit down and take the time to think about it and process, but I don't think it's an inaccurate one. Like it's not an inaccurate description of the feeling. Okay, so why talk about coherence at all? So my answer is actually, there's a little bit of backstory to it. So I have a friend who is an early career academic and she's in a field that is very competitive and as you probably know about academic jobs, like it's a very competitive market. There are a lot of people for very few jobs or can be and so the interview process is pretty grueling. And as an early career person, she had the opportunity to be involved in a bunch of hiring loops at her institution. So like people get really excited about this and they always ask her like, so what advice can you give me? Like it's my first time on the job market. What you know, like tell me what I should do. And her response, which I thought was really interesting was don't ramble and be as coherent as you can manage, right? And her point was not that you have to be perfect. Her point was that in a video interview, which is how all of these things start, it's really easy to weed somebody out because they're just not getting to the point. And I thought this was really interesting because I have never heard anybody give that advice to an engineer, right? Even though I think a lot of us, there was a point in, you know, like there was a point in our careers where we really needed that advice and really needed to take it in. And you know, on a lot of days, it's like, yes, it would be good if somebody would just remind us that it's like, it's good not to ramble, right? Like it's good to be clear and to be as clear as you can be. So, like, why do I care? Like, why do I care about coherence? And okay. So the answer, so the short answer, right? I mean, an answer that fits on a slide and that is good for somebody skimming through the PDF of this thing afterwards, right? It's, well, you're like, when people are coherent, right? Like it's easier to work with them. It's easier to get the work done. You have less friction, less delay. Lack of coherence creates friction. So this is a good enough answer that fits on a slide, like I said. And my real answer is more complicated because I'm meta and that's what I did. So I think of coherence as invisible infrastructure. So there's this great book by two scholars, Susan Lee Starr and Jeffrey Bunker, where they talk about infrastructure. And what they really talk about is how infrastructure is effective because it's invisible. Like that's how you get the gain from infrastructure. Like, it's invisible. People don't need to know about it. People don't need to think about it. They can just sort of like go on and do the thing and not have to focus about like, I don't know, like, are the lights going to turn on when I hit the light switch? The other thing that they talk about though is that invisibility can also make infrastructure less humane and less maintainable, right? Because it's like, how do you talk about something that's supposed to be invisible? Right? Like, there's a lot of mental load against doing that. So I listened to a lot of DevOps conference talks, which I expect a lot of you here do too as well. And a good chunk of them have a story, right, about a project that ended up better because the participants worked through intense disagreement about something, right? And they had a lot of positive friction and that ultimately made the project better, right? Like, we have all heard this story and it's a great story. I would love to be able to tell that story. But as sort of a, I don't know, deep introvert, mildly the slimy type, like, when I hear these stories, like, I always end up wondering about negative friction, right? Like, I always end up wondering about like, how does the team repair negative friction, right? Like, you know that nobody is perfect and that people are sometimes short with each other, you know, they misunderstand the question and they give a long answer to a question that wasn't really asked. But, you know, so there is negative friction, like, there's always going to be, and the question is like, well, so how does the team repair it, right? Like, and is it the team that's repairing it or are there individual people doing it because they think it's important and nobody else really knows, notices that there even is friction or that repair is happening all the time, right? So I kind of think of that, like, that sort of ties into my thing about invisible infrastructure. And I see managing coherence, learning how to be more coherent, creating space for people to be less than perfect in their expressions, like, I see that as one aspect of that invisible repair. Okay. So, how does lack of coherence create friction? So, I think in a lot of ways, right, like, that it's like, we know that it takes time, right, and attention and emotional labor to understand each other when we are less than, you know, when we're just less than clear, right, for whatever reason. And there are a lot of things that just go wrong when we're trying to deal with that friction, right? Like, there's a, like, it's just load. And, you know, like, if we think about it, we can think of a ton of examples. And, okay, so, like, what? Well, did that bullet actually appear? Come on. So, well, one of them is, like, what are the things that could go wrong? And one of them is, like, just inefficient message passing between humans, right? So, that's my really sort of geeky, short hand for, we don't talk to the people we should when we should, right? So, anybody here ever give up, you know, just like you didn't give up, but you put off doing code review or triaging a bug because, like, you read the description and you just did not understand what the person was trying to do, right? Like, this happened to anybody? Okay, see? Right, like, how many of you have put off talking to somebody because, like, you just had it had enough coffee that you felt like you could make yourself understood? Yeah? Okay. And how many of you put off talking to somebody indefinitely because you always have trouble taking in what they're saying? Yeah, see? Okay, like, was that good? Like, was that, like, exactly. Like, so, like, this is the thing that happens all the time. Like, we do this all the time, right? Like, if it adds load and we can find an excuse to just, like, no, don't want to go there, don't want that load today, then, you know, then we just kind of avoid it. So another reason why I think coherence matters, right, is when we perceive somebody as being coherent, right, like, or incoherent, we end up with a picture of, you know, their knowledge, their authority or their capability. And, you know, that might be us too. Like, it's hard to feel like a competent person when you're just like, oh, I totally messed up that explanation and all I did was confuse that person worse, right? And this matters for a lot of reasons, right? Like, so, one of them is that, you know, it just kind of feels bad not to be able to make yourself understood or not to understand other people, right? Like, my very neutral example of this is that if you're traveling in a country where you don't speak the language and you're there for a really long time, you just kind of get tired after a while, right? I mean, you know, you just, you know, like, there are people who, like, I know people who never go to McDonald's, but when they're traveling someplace where they don't speak the language, they're just like, okay, I'm going to McDonald's because some things will be in English, right? And it will just be a break. And, you know, it's hard to have a good opinion of somebody that you don't understand. It's hard to have a good opinion of yourself when you're not making yourself understood. So, that's the thing that I think matters. Like, it's a reason to me why coherence matters. The third thing is that in order for what you do to be valued, other people have to understand, like, why it matters. Like, they have to, I mean, they have to know that you're doing it. They have to know why it matters. They have to know that it is, you know, that it's a thing in the world. It's not just the thing, it's not just like the light switch, right, where they can just like the light switch and the lights come on and it's just kind of magic. You know, and it's really hard to be valued if you feel like you can't get your point, you know, you can't explain why you matter, why what you do matters, okay? So why is faking coherence? Like why not just fixing it, right? Like, we're engineers, we're tech people, we want to fix things. My really depressing answer is that I just don't think you can. I don't think it's possible. I wish it were because then I could stop having those days where it's like, no, I don't want to talk to anybody for like the next three hours because I don't think I can possibly be understandable. So why not? Well, nobody's perfect and that's a pun. So we have bodies. I can absolutely guarantee you that people will want to talk to you when you haven't slept or when you've had too much caffeine or you're coming down with the cold or even when you're just like thinking deeply about something else and just like don't, it's like, sorry, all the swap is gone. I don't have any room to page right now. You know, like it's going to happen, right? Like, it's not going to stop. Another thing is that perception of coherence I think depends a lot on the conditions of your labor, on the conditions of your work. And so like I can probably best explain this with an example. So I've been like the one ops person embedded with a team of devs. How many of you have been in that situation, right? Like security, QA, you know, like you're the one person on the team doing what you do and the rest of the team, you know, it's not that they all do the same thing, but they have very similar functions. They understand what they do. So I've been that one engineer and it was really hard to make my concerns hurt, right? Like everybody else is their focus is on shipping new features. And I'm trying to get somebody to sign off on a data retention policy so that we can tell our customers how long we're keeping their stuff. Yeah, sometimes I sounded completely incoherent because I was trying to talk to people who had all of their contacts paged in and none of mine. And sometimes I was completely incoherent because I got totally frustrated trying to explain like, no, really, we need to be able to tell people how long we're keeping their stuff. And you know, there's sort of a point here, which is that even though there was probably something that I could have done to get better at making my case, there was ultimately so much I could, there was really only so much I could do to fix the fact that, you know, everybody else just is doing something else, their focus is different. I am the only person with my very specific context and I'm going to have to like get all of that into their brains or, you know, a good chunk of it into their brains so that we can actually talk about this thing and they can understand why it matters. The next one is sort of, well, you know, other people are incoherent too, right? Like other people are not perfect. They're going to be coming down with colds. They're going to be running late. They ask questions that don't make sense, right? Like they're stressed out because they're trying to explain something to you and you're totally not getting it because they're the expert and you're not. And the thing is that incoherence is really a state problem, right? Like once somebody goes down the rabbit hole, it's hard to pull them out again and when you have a group of people, it's even worse. Like we've all been in that meeting, right? Where like one person understands one thing, misunderstands one thing and they're just, and they sort of like start running and then the rest of the room is like, wait, stop. And then they try to explain it to them and, you know, this person gets like five different explanations that aren't the same. So yeah, you know, it's like, it's very easy for incoherence to spread. So this is kind of why I think incoherence is a problem we're thinking about, right? Like it's not just that it feels bad, but it does. And that dealing with other people's incoherence is emotional labor that we might or might not be able to equip to deal with like at any given moment. It's, you know, it's just that it's like, yeah, the badness spreads. And a really abstract one, right, like is we are a craft field, right? And by that I mean, so this is a paraphrase from a professor named Jerry Rockwell, and he describes a craft field as one that developed to share knowledge that cannot be adequately captured in discourse, right? Like so basically you can't just explain what it is that we do to somebody and expect them to understand it, right? Like, like we learn by doing. That is how knowledge in our field spreads, right? Computer science is a craft field, right? Software engineering is more so and ops engineering is even more so. And you know, one big feature of craft fields is that we learn by doing and that constrains as practitioners how fast we can grow our individual scope, right? Like, and we're not only in craft fields. We are in craft fields that are expanding. So what that means is there's a lot to know. No one can do everything and doing is how we learn stuff. So no one can know everything in any kind of level of usable detail. And so we're all walking around not really understanding a lot of what it is that we do or not being able to explain it well, right? And so this is a reason for all of us to try to do better, right? Like there's going to be a lot of incoherence and confusion around just by the nature of what we do. So there's something to be said for not adding to it when we don't have to. I mean, in part, this creates slack for people who really don't have any choice about being incoherent like because they're learning, because they're new, because they're working in something that is their native language, because this is a completely new context for them. Like, you know, it's good. I think it's as a value. I think it's good to make space for people like that. And you know, those of us who can reining in our incoherence a little bit when we can, like I think that's sort of a good thing to do. So, okay, so what can we do about incoherence, right? Like I convinced you it's a thing. You know that, like I didn't have to do that, right? Like you knew that. And I really see this as having two components, sort of tactics and techniques piece and a strategy piece. And because we are all engineers and we love us some life hacks and we love us some techniques, I'm going to do the techniques first because it's the part that everybody thinks it's fun. Okay. So, I think of this, yep, you're on the right side. I think of this really as how to put a decent API in front of your brain, right? Like you have all of this infrastructure, right? Like where you're thinking about things and you're processing and you're taking any things and you're trying to sort of juggle it all around. And you know, and the people that you're dealing with, they don't really want to know all of that. Like they just kind of want to know, like, okay, like, like what parameters do I have to send in to get the thing that I want back? Like, so this is really how I think about it. My disclaimer is because I think people in this field get a lot of pressure to be perfect, is you don't have to do this all the time, right? So coherence is very relational and it's very context dependent. And I think of it as being like playing catch or tennis or ping pong or any of those other games where like you're trying to move a ball back and forth between a bunch of players. The theoretical ideal of this game, right? Like this is the thing that we all sort of learn when we learn how to play ping pong or whatever is that you want to maintain a volley so that the game has momentum, right? Like it's not interesting if you're spending all of your time chasing the ball. But that's theoretical, right? If you're playing catch with a little kid, you probably don't really care all that much. Like, you know, like it would be a very mean person who would just like yell at a little kid because they couldn't throw the ball back or catch it every time, right? Like if you're playing fetch with your dog, well, okay, I don't have dogs, I have cats. Playing fetch with a cat is like you're not doing this to maintain smooth movements of the ball. Let me tell you this, it's just not a thing. And you know, like if you're tossing a frisbee around while you have a drink or a cookie or whatever on one hand, like, you know, you are not playing the perfect theoretical game of catch. Like you're just not doing that, right? There are conversations where everyone involved is totally happy not being entirely coherent, like, you know, and that's fine, right? You know, like they're fine just like they're brainstorming so fast that it doesn't really matter if they miss one idea out of three, you know, or that they don't really quite understand how this other person got from point A to point B. Like, but they're happy, it's fine, it's good, don't mess with them, right? Like that is not, those people are not the problem. Those conversations that we're all having that are like that, they're not the problem. The problem is when someone is unhappy because what they want out of the conversation is to understand something or to feel like they're being understood and they're not getting that. So with that, I will move along to my actual giant list of techniques. The first one sounds really dumb, but it is, finish your sentences. Yes, it really does sound dumb, but it works, right? Because if you have ever sat in a meeting and watched somebody like winding a sentence around them more and more and they're just trying to find their way out and they can't and you see them looking frantic and you're just like, I don't know, would it be better to interrupt them because they might explode or would it be better, or like when we get to the end faster, I just kind of like give them the free reign to let them unwind themselves. Right? I mean, so like, you know exactly what I mean, that it's like the sentence gets too convoluted and people can't find their way out again. Like there is a point where people are paying more attention to whether the speaker is ever going to extract themselves from that sentence than to what the person is actually saying. So you know, if you catch yourself not, if you catch yourself like winding a sentence around hoping that you'll get to the end, just stop it. Just stop that sentence, like everybody will be happier. Another one is to limit repetition. Like I'm not saying never repeat yourself. But if you find yourself repeating yourself, repeating your words a lot, that's a tell that you've lost track of your point. You know, that it's like this one I think is hard for people to deal with and I think that my ideal would be it's like, well, you could set an alerting threshold and it's like below the threshold, it's fine if you don't repeat yourself. But you know, it's like once you hit a threshold of repetition, then you know, just stop, just stop right there. In practice, that's a harder thing to pay attention to, but if you can do it, it is, like it's helpful, right? Like even if you can't do anything about it, just noticing, okay, I've said the same thing three times, I really need to stop this conversation. Like that's helpful, right? That's a way to be, that's just a way to present as more coherent. The next one is using can responses. So I think this one is really good for, like obviously since they're canned, they're things that you have to plan a little bit ahead of time. But it is good for things where you can sort of prep ahead of time. So what are can responses? Documentation, I like documentation. I understand not everybody does, I know I'm weird. But the reason why I like documentation is that I have no qualms about sending links to people with documentation to docs that I wrote. And I do it because it makes it easier for me to be helpful, right? Like I don't do very well at saying the same thing over and over again when I feel like I'm not being understood. And you know, it's not, sometimes people need time to absorb things. And it is, like I understand that, but in the moment I don't really understand it, right? So there are things where it's like, yes, if I know I'm going to get asked this question a lot, I will just write documentation and when people ask it, I will point them to the docs. So another way that documentation is useful is that you can sometimes get really good return on investment on writing docs. Someone I worked for once, my first ops boss, showed me a very detailed email that he had written at a previous job about everything that was wrong with their extremely complicated deployment. And it was a beast. You know, it was mostly manual, they were managing like a couple hundred machines. It was bad. Like their deployments took days and they didn't always work. Surprise. And he was at that job for years. And when he showed me that message, I noticed that it's like it had been forwarded so many times. Right? Like he had, he probably reset that email about 20 times to like different groups of people or sometimes the same people or whatever. But so he got a lot of good value out of that mail. And yeah, it's totally annoying that in the eight years he was at that job, the stuff did not get fixed. Right? Like, but you know, some of it did and a lot of it didn't. But he also didn't have to emotionally revisit every single thing that was wrong. Anytime somebody is like, well, why did that deployment fail? And I can't, you guys just nerd harder. Like, you know, he was pretty thorough. So he got a lot of value out of it. And he came off as really organized and really consistent because he was just like, you know, I told you this before and I'm telling you it again and maybe you didn't take it in. So here you go. Another of my favorite can responses, which many people who work with me have heard me say is that's interesting. Which is kind of a weird one, right? But it's for me, it's because I feel like I come across as less coherent when I get sucked into having a conversation that I sort of don't want to have. Right? Like it might be because I've had it too many times. It might be because I'm not really prepared to have this conversation. It might be because, I don't know, it's before lunch and I really just want to go and eat, okay? But sometimes it's just worth letting the conversation go to voicemail. And you know, that's interesting. I have to think about it, like is a way of doing that. So another one, conscious use of heuristics, right? So a heuristic is just a fancy word for a strategy that you form from previous experience with a similar problem. And you know, we do this all the time. Like we might not have the words for it, but we say things all the time like, okay, so you're having this problem that looks, did you update the lock file? Right? I don't know, it's like, so okay, did you upload the latest version? Is the thing that you're looking for actually there? Right? Like, so we just apply these all the time. Like somebody gives us a problem. It sounds like we're not really doing exact pattern matching to a thing that we've seen before, but we know it's probably in the neighborhood of something like, something we've seen before. So we throw out this suggestion. So I really like heuristics because they give me a way of getting at bad assumptions. And I use them all the time. Like, I use them to debug my own stuff as well as other people's. And I have a, the way that I do this is I have a set of questions that I can ask about a wide variety of problems. Like what problem are you trying to solve? Like anybody use that one? Right? Because, you know, when you get out of Rathole, it's, you kind of forget what yak you were trying to shave. And it's kind of good to like have it be brought back to like, okay, so what am I really trying to do here? And another one that I've been known to ask a lot is, so why do we have to do it this way? Like what are the alternatives? Like what could we do instead? Do we have to build this thing? Because you know, the software that you don't have to build, this is good software. We like that. So another general category of tactics I think of as corral your conversation. And this is really about organizing the conversation upfront so that it just kind of has fewer chances to wander off into the weeds. And remember, this is a public service, right? Incoherence is contagious. So once one person gets it, everybody else goes there too. And you're just all kind of like wandering around going like, hello, anybody else here? So what do I mean by corraling conversations? Sticky notes, they are your friend, right? So sticky notes are a great tool to have in hand when you know ahead of time that the conversation is likely to wander. Years ago I worked at a company with somebody who was a very smart guy, very good to work with, but he went off on tangents, very long tangents. And a bunch of us got really frustrated because we would go to him and ask a question, and this was in person because we were still like actually co-located physically. And you'd go to him and you'd ask a question and you'd walk out of his office an hour later having heard a lot of words, but just like wait, what did I go there for? What was I trying to get help with? I don't remember anymore, which is kind of demoralizing, right? So what we learned to do is we learned to write our questions on a sticky note and carry it with us. So that when we went in there, we had a sticky note and every time he started wandering, we could sort of look at the sticky notes like, oh, right, that's what I meant to ask. And we tried to be pretty subtle about it, and I don't think he ever noticed or his feelings were hurt if he did, or maybe he just thought, I don't know, they think they're really forgetful, so they wrote the question down. But their reason, I can see concerns that people have about doing a very explicit instrumental tactic like that, but it actually worked really well. It made it easier for all of us to work together. So another sticky note technique that I learned recently is from one of my friends who, when she knows she has to talk about a problem where she's likely to become less coherent for whatever reason, like it could be, it's something that she's really feeling very emotional about or it's something that's really complicated and she has all of the context and nobody else has any of it. What she does is she writes and rewrites what she wants to say until it fits on a sticky note. And by the way, it is totally a victory if she can boil down what she wants to say until it fits on a smaller sticky note. So this is about containing what you say so that it can fit into somebody else's brain. So another one, another technique that you can do is you can invite specific responses. I think that this one is, you know, this one takes a little bit of practice and it takes a little bit of, like you can't just, like this one's hard to deploy on this part of the moment. That's really what I'm trying to say. But what are specific responses? Well, this is a sketch of a new feature to do X, right? Like when you see this in a pull request, right, like what kind of feedback do you think the person's looking for? They're probably not looking for exact perfect, you know, this is going to be in production tomorrow. It's like, like they know, okay, this is an idea. Somebody is trying to say, this is how I'm thinking about it. Like, you know, you have a broader scope to talk about it. So if you've done tech reviewing for tech books, like it's very common for people to say I want feedback about content and I don't really care about spelling or punctuation right now. So, you know, it's very specific. It's very bounded. It might not be what you're able to do, but it's very specific and very bounded. A really good one to use when you are teaching or when you are trying to convey something complicated to somebody else is, so is what I'm saying making sense to you. Like get the feedback as you go so that, you know, you don't wind yourself up in the coil trying to explain something to somebody because you can see that they're not getting it until you just try to explain harder. You know, so I think that, so I think those are suggestions. And if all is fails, just reset the conversation. Sometimes I, and everybody who's worked with me has heard me say this, right, like what I just said was really complicated. I think I can say it more simply, would you like me to try again? And if they say no, then take no for an answer, right? Like filling the air with words is totally not helping you. On the flip side, people who are drowning in a stream of their own words are often relieved when somebody else just takes that conversation and puts it out of its misery. Humanely. Okay, so tech, those are sort of my suggested tactics. And they kind of fall into two classes, right? Like really, there's don't go there. And there's if you find yourself going there, stop and turn around. That's pretty much it, right? You know, it sounds easy, right? But it's like if it were easy, we would all be doing it. And we are not all doing it and we are certainly not all doing it all the time. So okay, strategic questions, which do not ask yourself these questions in the moment because if you think about them too hard, and you should think about them hard, right? But if you think about them too hard when you're trying to do something like talk to a person, your brain will freeze. You will not become more coherent. But these are questions that it's worth thinking about when you're not under pressure because they will help you determine what your tactics are. So one of them, when we were doing speaker training, Anna kept drilling into us, audience, audience, audience, like who are you talking to, what do they want from you? Like go through the list of people or the classes of people that you interact with frequently and think about like, okay, so how have these interactions gone for me? Like do I like talking to these people? Do I dread talking to these people? Why do I dread talking to these people? And if you feel able to ask some of them directly for feedback, it's totally worth doing that, like ask them if there's something that they would, you know, how does it feel to interact with you? Are there things that they would like from you that you're just not doing naturally? Another piece of that is like, are you having the right conversations with the right people? And so this is sort of a circle of commitment model, link is below. This was originally developed by a pastor at a very large church, and it has caught on and been modified by a bunch of different kinds of organizations. But I find this useful as a way to organize my thoughts around what conversations I'm having with what groups of people. Because a lot of us, especially when we're involved in something very deeply, we tend to just sort of treat everybody like their core, right? Like everybody is us, they share the same priorities, they share the same goals, they share the same level of commitment. And you know, that's just kind of not true. And when we treat everybody like their core, you know, like their priorities are exactly ours and they're just as dedicated to them as we are, that just throws the door wide open for incoherence to wander in. Like you hear this a lot with metrics data, like a thing that I hear a lot when people talk about metrics is, my audience is everyone because everybody should care about this. Well, I don't think that's helpful, right? It's probably true that everyone should care. I can tell you that everyone is not going to care in exactly the same way, at exactly the same time, about exactly the same thing. Like they're just not. So another strategic point is, is there a different conversation you need to have? And I actually think this is, I will preface this by saying that I think that one thing that causes people to gibber is that they really want to have a different conversation and that conversation is trying to sneak its way in into the one that they're actually having. So when we find ourselves bringing every conversation around to some topic, we need to stop doing that. We really need to stop doing that because we're making other people not want to hear about whatever it is. There are tools that I totally do not use because somebody has shown up every time. I've had my hands full with something and wanted to tell me how if we were using that tool, we would not be having this problem today. And they could be right. Like I am not disputing their correctness one bit, but that is not the conversation I needed to have. Another thing I should say is that different conversations, like that's actually, I think, a place where learners can push, right? Because a lot of times we try to fit in training into these very operational, very pragmatic conversations that we're having about like how do you do this thing, we want to do this and get this done. And a lot of times what I find is that when people are learning, they need to have a little bit of a wider conversation. So examples, there's historical ones. Why did we switch from that to, you know, why did we switch from MongoDB back to Postgres, right? Speculative. What would be the reason to switch from MongoDB to Postgres? Don't answer that. Deep technical questions or conversations, right? So Julia Evans wrote this really awesome blog post called How to Ask Good Questions. I think that that's sort of a good way to frame some of these things. Like at a good way to talk about how you initiate, having a conversation that's a little bit wider ranging than how do I do this thing right now? And affective ones. Like I am unhappy about whatever it is, right? And these are conversations that might be happening for you. They might not be happening for you just based on, you know, like what work you're doing and who you happen to be pairing with and who tends to be around when you feel like talking, right? So another one. How much conversational space do you tend to occupy? So imagine you're really excited to learn about something and I'll just throw distributed systems out there because it's a field that attracts this particular thing. But anytime somebody even thinks about distributed systems around you, like there you are, like you want to talk to them, right? Like because you're really excited and you want to hear what they have to say and you want to share what you've been reading, right? And the thing is that it's like sometimes this is awesome and sometimes, and you know, and I think it always comes from a good place. But did you pay enough attention to these conversations to know whether your interjection is relevant or whether people are okay with being pounced on while they're thinking about distributed systems, right? Like maybe two people are talking about something that's really stressing them out with, you know, some system that they're working on. Maybe like this is a one-on-one where one person really wants to hear very specifically what the other person thinks about this and they're just not ready to take in more feedback, right? Like having somebody show up and say, you know what, I read this really cool paper about the RAS theorem. It might not, you know, it's not quite so useful, right? On the flip side, like imagine a time when you were so nervous about asking for help debugging a problem that you've been working on for a really long time, right? And the nervousness is partly because you've been working on it for a really long time and you're ready to be done, but you also feel bad about working on it for so long. So you finally get somebody, you know, paying attention and you just blurt out everything that you've tried in one big, long sentence, right? Anybody ever done this? I've done this. Totally done this, right? Like, and this is a place where like you are so concerned about not taking up space that you aren't really thinking about whether anybody can process that one sentence, right? Like, wait, stop, no, what did you do? I don't know. So yeah, those are all things to think about. They won't help you in the moment, but thinking about them, I think, might help you. So sort of, my last thing is like strategy is situate yourself, right? And this goes back to my original definition of coherence as a good use of available bandwidth, right? And with such bandwidth do you really have in a given interaction? So we are not brains and jars isolated from our environments, right? Like, if someone is overworked, then it's going to be really hard for you to talk to them about something that's totally outside of their context, right? Like, it just is. Like, the available bandwidth there is just not that big. If you're that overworked person, like, how can you use the bandwidth the best, right? Like, if you're outside of that, what are you doing to make room for that person to talk about stuff? Because, you know, like, the bandwidth goes both ways, right? Like, they're probably going to have a really hard time bringing stuff to you. So like, that's one way that, you know, situation matters, right? Like another one is if you're just dealing with people who are not organized enough to be able to be transparent, right? And this happens a lot. You know, every interaction is going to require extracting and paging in a ton of information. In a ton of new context. And this is not a situation that makes people feel or sound more coherent. So at the end of the day, some of these might be things that you can't fix. Like, you sort of can't really do anything about somebody else being overworked or being the only person who knows about whatever it is. But what you can try to do is you can try to implement, try to pick your tactics well and try to do them as effectively as you can and acknowledge the constraints that you have. So that's pretty much it. And I'm going to do a slightly geeky thing and redo the last line of a, it's the last stands of a poem by William Stafford called A Ritual to Read to Each Other. And it is a poem about people missing each other like ships in the night. For this important that awake people be awake. Or a breaking line may discourage them back to sleep. The signals we give, yes or no or maybe should be clear. The darkness around us is deep. Thank you. Thank you. Thank you.
 Hi.  Thank you.  So, I forgot to do my forced breath breathing.  Oh, well.  There's this breathing exercise that we learned to calm us down before we speak.  And it just went in one ear and went out the other.  Sorry, Anna.  So, that's me.  Hi.  I'm Yvonne Lam.  My Twitter handle is up there.  Release Engineer is not a specific title at Chef.  We ranked along the SDE track.  Basically, I just tell people I'm a release engineer because it's shorter than saying  what I do, which is that I work in the team at Chef that does internal tools, CI, CD.  And we basically manage all the infrastructure for building, releasing, and publishing software  packages that Chef uses.  So that's what I do.  Everybody always says when I say a lot of things, but really that, wow, that was really  meta.  So, that's the kind of talk this is.  It's kind of who I am.  I've decided to own it.  So here we are.  So, what is coherence?  I realize this is kind of a weird title.  I mean, it's kind of a weird talk topic.  So, I'm going to take a couple of minutes and lead us into it.  So what is coherence?  Well, I think of it really, this is my geeky definition.  I think of it as getting the right amount of information into the amount of bandwidth  that you actually have available to convey it.  So I think of it as kind of a packing problem, right?  Like that it's like, okay, so you're interacting with another person or a group of people.  This is how much room you have to tell them stuff.  How are you going to tell them stuff efficiently?  Like what choices are you going to make around that?  Coherence isn't exactly easier to define, but I think it's really recognizable, right?  You all know when you get that feeling that it's like, oh, God, I've just told them a  whole bunch of stuff and I'm not sure if they took any of it in, right?  Like anybody here ever not feel that?  And I know that when somebody sort of loses track of their train of thought with me, that  my response is like, okay, I know they're trying to be helpful, but now I'm going to  have this bunch of stuff that I need to fish through to figure out what in that is actually  going to be useful to me.  And I'm not necessarily sure that anything is.  So I mean, it's a little bit of a loaded description, right?  I mean, because sometimes you really don't understand something and you really do have  to sit down and take the time to think about it and process, but I don't think it's an  inaccurate one.  Like it's not an inaccurate description of the feeling.  Okay, so why talk about coherence at all?  So my answer is actually, there's a little bit of backstory to it.  So I have a friend who is an early career academic and she's in a field that is very  competitive and as you probably know about academic jobs, like it's a very competitive  market.  There are a lot of people for very few jobs or can be and so the interview process is  pretty grueling.  And as an early career person, she had the opportunity to be involved in a bunch of hiring  loops at her institution.  So like people get really excited about this and they always ask her like, so what advice  can you give me?  Like it's my first time on the job market.  What you know, like tell me what I should do.  And her response, which I thought was really interesting was don't ramble and be as coherent  as you can manage, right?  And her point was not that you have to be perfect.  Her point was that in a video interview, which is how all of these things start, it's really  easy to weed somebody out because they're just not getting to the point.  And I thought this was really interesting because I have never heard anybody give that  advice to an engineer, right?  Even though I think a lot of us, there was a point in, you know, like there was a point  in our careers where we really needed that advice and really needed to take it in.  And you know, on a lot of days, it's like, yes, it would be good if somebody would just  remind us that it's like, it's good not to ramble, right?  Like it's good to be clear and to be as clear as you can be.  So, like, why do I care?  Like, why do I care about coherence?  And okay.  So the answer, so the short answer, right?  I mean, an answer that fits on a slide and that is good for somebody skimming through  the PDF of this thing afterwards, right?  It's, well, you're like, when people are coherent, right?  Like it's easier to work with them.  It's easier to get the work done.  You have less friction, less delay.  Lack of coherence creates friction.  So this is a good enough answer that fits on a slide, like I said.  And my real answer is more complicated because I'm meta and that's what I did.  So I think of coherence as invisible infrastructure.  So there's this great book by two scholars, Susan Lee Starr and Jeffrey Bunker, where  they talk about infrastructure.  And what they really talk about is how infrastructure is effective because it's invisible.  Like that's how you get the gain from infrastructure.  Like, it's invisible.  People don't need to know about it.  People don't need to think about it.  They can just sort of like go on and do the thing and not have to focus about like, I  don't know, like, are the lights going to turn on when I hit the light switch?  The other thing that they talk about though is that invisibility can also make infrastructure  less humane and less maintainable, right?  Because it's like, how do you talk about something that's supposed to be invisible?  Right?  Like, there's a lot of mental load against doing that.  So I listened to a lot of DevOps conference talks, which I expect a lot of you here do  too as well.  And a good chunk of them have a story, right, about a project that ended up better because  the participants worked through intense disagreement about something, right?  And they had a lot of positive friction and that ultimately made the project better, right?  Like, we have all heard this story and it's a great story.  I would love to be able to tell that story.  But as sort of a, I don't know, deep introvert, mildly the slimy type, like, when I hear these  stories, like, I always end up wondering about negative friction, right?  Like, I always end up wondering about like, how does the team repair negative friction,  right?  Like, you know that nobody is perfect and that people are sometimes short with each  other, you know, they misunderstand the question and they give a long answer to a question  that wasn't really asked.  But, you know, so there is negative friction, like, there's always going to be, and the  question is like, well, so how does the team repair it, right?  Like, and is it the team that's repairing it or are there individual people doing it because  they think it's important and nobody else really knows, notices that there even is  friction or that repair is happening all the time, right?  So I kind of think of that, like, that sort of ties into my thing about invisible infrastructure.  And I see managing coherence, learning how to be more coherent, creating space for people  to be less than perfect in their expressions, like, I see that as one aspect of that invisible  repair.  Okay.  So, how does lack of coherence create friction?  So, I think in a lot of ways, right, like, that it's like, we know that it takes time,  right, and attention and emotional labor to understand each other when we are less than,  you know, when we're just less than clear, right, for whatever reason.  And there are a lot of things that just go wrong when we're trying to deal with that  friction, right?  Like, there's a, like, it's just load.  And, you know, like, if we think about it, we can think of a ton of examples.  And, okay, so, like, what?  Well, did that bullet actually appear?  Come on.  So, well, one of them is, like, what are the things that could go wrong?  And one of them is, like, just inefficient message passing between humans, right?  So, that's my really sort of geeky, short hand for, we don't talk to the people we should  when we should, right?  So, anybody here ever give up, you know, just like you didn't give up, but you put off doing  code review or triaging a bug because, like, you read the description and you just did  not understand what the person was trying to do, right?  Like, this happened to anybody?  Okay, see?  Right, like, how many of you have put off talking to somebody because, like, you just  had it had enough coffee that you felt like you could make yourself understood?  Yeah?  Okay.  And how many of you put off talking to somebody indefinitely because you always have trouble  taking in what they're saying?  Yeah, see?  Okay, like, was that good?  Like, was that, like, exactly.  Like, so, like, this is the thing that happens all the time.  Like, we do this all the time, right?  Like, if it adds load and we can find an excuse to just, like, no, don't want to go there,  don't want that load today, then, you know, then we just kind of avoid it.  So another reason why I think coherence matters, right, is when we perceive somebody as being  coherent, right, like, or incoherent, we end up with a picture of, you know, their knowledge,  their authority or their capability.  And, you know, that might be us too.  Like, it's hard to feel like a competent person when you're just like, oh, I totally messed  up that explanation and all I did was confuse that person worse, right?  And this matters for a lot of reasons, right?  Like, so, one of them is that, you know, it just kind of feels bad not to be able to make  yourself understood or not to understand other people, right?  Like, my very neutral example of this is that if you're traveling in a country where you  don't speak the language and you're there for a really long time, you just kind of get  tired after a while, right?  I mean, you know, you just, you know, like, there are people who, like, I know people  who never go to McDonald's, but when they're traveling someplace where they don't speak  the language, they're just like, okay, I'm going to McDonald's because some things will  be in English, right?  And it will just be a break.  And, you know, it's hard to have a good opinion of somebody that you don't understand.  It's hard to have a good opinion of yourself when you're not making yourself understood.  So, that's the thing that I think matters.  Like, it's a reason to me why coherence matters.  The third thing is that in order for what you do to be valued, other people have to  understand, like, why it matters.  Like, they have to, I mean, they have to know that you're doing it.  They have to know why it matters.  They have to know that it is, you know, that it's a thing in the world.  It's not just the thing, it's not just like the light switch, right, where they can just  like the light switch and the lights come on and it's just kind of magic.  You know, and it's really hard to be valued if you feel like you can't get your point,  you know, you can't explain why you matter, why what you do matters, okay?  So why is faking coherence?  Like why not just fixing it, right?  Like, we're engineers, we're tech people, we want to fix things.  My really depressing answer is that I just don't think you can.  I don't think it's possible.  I wish it were because then I could stop having those days where it's like, no, I don't want  to talk to anybody for like the next three hours because I don't think I can possibly  be understandable.  So why not?  Well, nobody's perfect and that's a pun.  So we have bodies.  I can absolutely guarantee you that people will want to talk to you when you haven't  slept or when you've had too much caffeine or you're coming down with the cold or even  when you're just like thinking deeply about something else and just like don't, it's like,  sorry, all the swap is gone.  I don't have any room to page right now.  You know, like it's going to happen, right?  Like, it's not going to stop.  Another thing is that perception of coherence I think depends a lot on the conditions of  your labor, on the conditions of your work.  And so like I can probably best explain this with an example.  So I've been like the one ops person embedded with a team of devs.  How many of you have been in that situation, right?  Like security, QA, you know, like you're the one person on the team doing what you do and  the rest of the team, you know, it's not that they all do the same thing, but they have  very similar functions.  They understand what they do.  So I've been that one engineer and it was really hard to make my concerns hurt, right?  Like everybody else is their focus is on shipping new features.  And I'm trying to get somebody to sign off on a data retention policy so that we can  tell our customers how long we're keeping their stuff.  Yeah, sometimes I sounded completely incoherent because I was trying to talk to people who  had all of their contacts paged in and none of mine.  And sometimes I was completely incoherent because I got totally frustrated trying to  explain like, no, really, we need to be able to tell people how long we're keeping their  stuff.  And you know, there's sort of a point here, which is that even though there was probably  something that I could have done to get better at making my case, there was ultimately so  much I could, there was really only so much I could do to fix the fact that, you know,  everybody else just is doing something else, their focus is different.  I am the only person with my very specific context and I'm going to have to like get  all of that into their brains or, you know, a good chunk of it into their brains so that  we can actually talk about this thing and they can understand why it matters.  The next one is sort of, well, you know, other people are incoherent too, right?  Like other people are not perfect.  They're going to be coming down with colds.  They're going to be running late.  They ask questions that don't make sense, right?  Like they're stressed out because they're trying to explain something to you and you're  totally not getting it because they're the expert and you're not.  And the thing is that incoherence is really a state problem, right?  Like once somebody goes down the rabbit hole, it's hard to pull them out again and when  you have a group of people, it's even worse.  Like we've all been in that meeting, right?  Where like one person understands one thing, misunderstands one thing and they're just,  and they sort of like start running and then the rest of the room is like, wait, stop.  And then they try to explain it to them and, you know, this person gets like five different  explanations that aren't the same.  So yeah, you know, it's like, it's very easy for incoherence to spread.  So this is kind of why I think incoherence is a problem we're thinking about, right?  Like it's not just that it feels bad, but it does.  And that dealing with other people's incoherence is emotional labor that we might or might  not be able to equip to deal with like at any given moment.  It's, you know, it's just that it's like, yeah, the badness spreads.  And a really abstract one, right, like is we are a craft field, right?  And by that I mean, so this is a paraphrase from a professor named Jerry Rockwell, and  he describes a craft field as one that developed to share knowledge that cannot be adequately  captured in discourse, right?  Like so basically you can't just explain what it is that we do to somebody and expect them  to understand it, right?  Like, like we learn by doing.  That is how knowledge in our field spreads, right?  Computer science is a craft field, right?  Software engineering is more so and ops engineering is even more so.  And you know, one big feature of craft fields is that we learn by doing and that constrains  as practitioners how fast we can grow our individual scope, right?  Like, and we're not only in craft fields.  We are in craft fields that are expanding.  So what that means is there's a lot to know.  No one can do everything and doing is how we learn stuff.  So no one can know everything in any kind of level of usable detail.  And so we're all walking around not really understanding a lot of what it is that we  do or not being able to explain it well, right?  And so this is a reason for all of us to try to do better, right?  Like there's going to be a lot of incoherence and confusion around just by the nature of  what we do.  So there's something to be said for not adding to it when we don't have to.  I mean, in part, this creates slack for people who really don't have any choice about being  incoherent like because they're learning, because they're new, because they're working  in something that is their native language, because this is a completely new context for  them.  Like, you know, it's good.  I think it's as a value.  I think it's good to make space for people like that.  And you know, those of us who can reining in our incoherence a little bit when we can,  like I think that's sort of a good thing to do.  So, okay, so what can we do about incoherence, right?  Like I convinced you it's a thing.  You know that, like I didn't have to do that, right?  Like you knew that.  And I really see this as having two components, sort of tactics and techniques piece and a  strategy piece.  And because we are all engineers and we love us some life hacks and we love us some techniques,  I'm going to do the techniques first because it's the part that everybody thinks it's  fun.  Okay.  So, I think of this, yep, you're on the right side.  I think of this really as how to put a decent API in front of your brain, right?  Like you have all of this infrastructure, right?  Like where you're thinking about things and you're processing and you're taking any things  and you're trying to sort of juggle it all around.  And you know, and the people that you're dealing with, they don't really want to know all of  that.  Like they just kind of want to know, like, okay, like, like what parameters do I have  to send in to get the thing that I want back?  Like, so this is really how I think about it.  My disclaimer is because I think people in this field get a lot of pressure to be perfect,  is you don't have to do this all the time, right?  So coherence is very relational and it's very context dependent.  And I think of it as being like playing catch or tennis or ping pong or any of those other  games where like you're trying to move a ball back and forth between a bunch of players.  The theoretical ideal of this game, right?  Like this is the thing that we all sort of learn when we learn how to play ping pong  or whatever is that you want to maintain a volley so that the game has momentum, right?  Like it's not interesting if you're spending all of your time chasing the ball.  But that's theoretical, right?  If you're playing catch with a little kid, you probably don't really care all that much.  Like, you know, like it would be a very mean person who would just like yell at a little  kid because they couldn't throw the ball back or catch it every time, right?  Like if you're playing fetch with your dog, well, okay, I don't have dogs, I have cats.  Playing fetch with a cat is like you're not doing this to maintain smooth movements of  the ball.  Let me tell you this, it's just not a thing.  And you know, like if you're tossing a frisbee around while you have a drink or a cookie  or whatever on one hand, like, you know, you are not playing the perfect theoretical game  of catch.  Like you're just not doing that, right?  There are conversations where everyone involved is totally happy not being entirely coherent,  like, you know, and that's fine, right?  You know, like they're fine just like they're brainstorming so fast that it doesn't really  matter if they miss one idea out of three, you know, or that they don't really quite  understand how this other person got from point A to point B.  Like, but they're happy, it's fine, it's good, don't mess with them, right?  Like that is not, those people are not the problem.  Those conversations that we're all having that are like that, they're not the problem.  The problem is when someone is unhappy because what they want out of the conversation is  to understand something or to feel like they're being understood and they're not getting that.  So with that, I will move along to my actual giant list of techniques.  The first one sounds really dumb, but it is, finish your sentences.  Yes, it really does sound dumb, but it works, right?  Because if you have ever sat in a meeting and watched somebody like winding a sentence  around them more and more and they're just trying to find their way out and they can't  and you see them looking frantic and you're just like, I don't know, would it be better  to interrupt them because they might explode or would it be better, or like when we get  to the end faster, I just kind of like give them the free reign to let them unwind themselves.  Right?  I mean, so like, you know exactly what I mean, that it's like the sentence gets too convoluted  and people can't find their way out again.  Like there is a point where people are paying more attention to whether the speaker is ever  going to extract themselves from that sentence than to what the person is actually saying.  So you know, if you catch yourself not, if you catch yourself like winding a sentence  around hoping that you'll get to the end, just stop it.  Just stop that sentence, like everybody will be happier.  Another one is to limit repetition.  Like I'm not saying never repeat yourself.  But if you find yourself repeating yourself, repeating your words a lot, that's a tell  that you've lost track of your point.  You know, that it's like this one I think is hard for people to deal with and I think  that my ideal would be it's like, well, you could set an alerting threshold and it's like  below the threshold, it's fine if you don't repeat yourself.  But you know, it's like once you hit a threshold of repetition, then you know, just stop, just  stop right there.  In practice, that's a harder thing to pay attention to, but if you can do it, it is,  like it's helpful, right?  Like even if you can't do anything about it, just noticing, okay, I've said the same thing  three times, I really need to stop this conversation.  Like that's helpful, right?  That's a way to be, that's just a way to present as more coherent.  The next one is using can responses.  So I think this one is really good for, like obviously since they're canned, they're things  that you have to plan a little bit ahead of time.  But it is good for things where you can sort of prep ahead of time.  So what are can responses?  Documentation, I like documentation.  I understand not everybody does, I know I'm weird.  But the reason why I like documentation is that I have no qualms about sending links  to people with documentation to docs that I wrote.  And I do it because it makes it easier for me to be helpful, right?  Like I don't do very well at saying the same thing over and over again when I feel like  I'm not being understood.  And you know, it's not, sometimes people need time to absorb things.  And it is, like I understand that, but in the moment I don't really understand it, right?  So there are things where it's like, yes, if I know I'm going to get asked this question  a lot, I will just write documentation and when people ask it, I will point them to the  docs.  So another way that documentation is useful is that you can sometimes get really good  return on investment on writing docs.  Someone I worked for once, my first ops boss, showed me a very detailed email that he had  written at a previous job about everything that was wrong with their extremely complicated  deployment.  And it was a beast.  You know, it was mostly manual, they were managing like a couple hundred machines.  It was bad.  Like their deployments took days and they didn't always work.  Surprise.  And he was at that job for years.  And when he showed me that message, I noticed that it's like it had been forwarded so many  times.  Right?  Like he had, he probably reset that email about 20 times to like different groups of  people or sometimes the same people or whatever.  But so he got a lot of good value out of that mail.  And yeah, it's totally annoying that in the eight years he was at that job, the stuff  did not get fixed.  Right?  Like, but you know, some of it did and a lot of it didn't.  But he also didn't have to emotionally revisit every single thing that was wrong.  Anytime somebody is like, well, why did that deployment fail?  And I can't, you guys just nerd harder.  Like, you know, he was pretty thorough.  So he got a lot of value out of it.  And he came off as really organized and really consistent because he was just like, you know,  I told you this before and I'm telling you it again and maybe you didn't take it in.  So here you go.  Another of my favorite can responses, which many people who work with me have heard me  say is that's interesting.  Which is kind of a weird one, right?  But it's for me, it's because I feel like I come across as less coherent when I get  sucked into having a conversation that I sort of don't want to have.  Right?  Like it might be because I've had it too many times.  It might be because I'm not really prepared to have this conversation.  It might be because, I don't know, it's before lunch and I really just want to go and eat,  okay?  But sometimes it's just worth letting the conversation go to voicemail.  And you know, that's interesting.  I have to think about it, like is a way of doing that.  So another one, conscious use of heuristics, right?  So a heuristic is just a fancy word for a strategy that you form from previous experience  with a similar problem.  And you know, we do this all the time.  Like we might not have the words for it, but we say things all the time like, okay, so  you're having this problem that looks, did you update the lock file?  Right?  I don't know, it's like, so okay, did you upload the latest version?  Is the thing that you're looking for actually there?  Right?  Like, so we just apply these all the time.  Like somebody gives us a problem.  It sounds like we're not really doing exact pattern matching to a thing that we've seen  before, but we know it's probably in the neighborhood of something like, something we've seen before.  So we throw out this suggestion.  So I really like heuristics because they give me a way of getting at bad assumptions.  And I use them all the time.  Like, I use them to debug my own stuff as well as other people's.  And I have a, the way that I do this is I have a set of questions that I can ask about  a wide variety of problems.  Like what problem are you trying to solve?  Like anybody use that one?  Right?  Because, you know, when you get out of Rathole, it's, you kind of forget what yak you were  trying to shave.  And it's kind of good to like have it be brought back to like, okay, so what am I really trying  to do here?  And another one that I've been known to ask a lot is, so why do we have to do it this  way?  Like what are the alternatives?  Like what could we do instead?  Do we have to build this thing?  Because you know, the software that you don't have to build, this is good software.  We like that.  So another general category of tactics I think of as corral your conversation.  And this is really about organizing the conversation upfront so that it just kind of has fewer  chances to wander off into the weeds.  And remember, this is a public service, right?  Incoherence is contagious.  So once one person gets it, everybody else goes there too.  And you're just all kind of like wandering around going like, hello, anybody else here?  So what do I mean by corraling conversations?  Sticky notes, they are your friend, right?  So sticky notes are a great tool to have in hand when you know ahead of time that the  conversation is likely to wander.  Years ago I worked at a company with somebody who was a very smart guy, very good to work  with, but he went off on tangents, very long tangents.  And a bunch of us got really frustrated because we would go to him and ask a question, and  this was in person because we were still like actually co-located physically.  And you'd go to him and you'd ask a question and you'd walk out of his office an hour later  having heard a lot of words, but just like wait, what did I go there for?  What was I trying to get help with?  I don't remember anymore, which is kind of demoralizing, right?  So what we learned to do is we learned to write our questions on a sticky note and carry  it with us.  So that when we went in there, we had a sticky note and every time he started wandering, we  could sort of look at the sticky notes like, oh, right, that's what I meant to ask.  And we tried to be pretty subtle about it, and I don't think he ever noticed or his feelings  were hurt if he did, or maybe he just thought, I don't know, they think they're really forgetful,  so they wrote the question down.  But their reason, I can see concerns that people have about doing a very explicit instrumental  tactic like that, but it actually worked really well.  It made it easier for all of us to work together.  So another sticky note technique that I learned recently is from one of my friends who, when  she knows she has to talk about a problem where she's likely to become less coherent  for whatever reason, like it could be, it's something that she's really feeling very emotional  about or it's something that's really complicated and she has all of the context and nobody  else has any of it.  What she does is she writes and rewrites what she wants to say until it fits on a sticky  note.  And by the way, it is totally a victory if she can boil down what she wants to say until  it fits on a smaller sticky note.  So this is about containing what you say so that it can fit into somebody else's brain.  So another one, another technique that you can do is you can invite specific responses.  I think that this one is, you know, this one takes a little bit of practice and it takes  a little bit of, like you can't just, like this one's hard to deploy on this part of  the moment.  That's really what I'm trying to say.  But what are specific responses?  Well, this is a sketch of a new feature to do X, right?  Like when you see this in a pull request, right, like what kind of feedback do you think  the person's looking for?  They're probably not looking for exact perfect, you know, this is going to be in production  tomorrow.  It's like, like they know, okay, this is an idea.  Somebody is trying to say, this is how I'm thinking about it.  Like, you know, you have a broader scope to talk about it.  So if you've done tech reviewing for tech books, like it's very common for people to  say I want feedback about content and I don't really care about spelling or punctuation  right now.  So, you know, it's very specific.  It's very bounded.  It might not be what you're able to do, but it's very specific and very bounded.  A really good one to use when you are teaching or when you are trying to convey something  complicated to somebody else is, so is what I'm saying making sense to you.  Like get the feedback as you go so that, you know, you don't wind yourself up in the coil  trying to explain something to somebody because you can see that they're not getting it until  you just try to explain harder.  You know, so I think that, so I think those are suggestions.  And if all is fails, just reset the conversation.  Sometimes I, and everybody who's worked with me has heard me say this, right, like what  I just said was really complicated.  I think I can say it more simply, would you like me to try again?  And if they say no, then take no for an answer, right?  Like filling the air with words is totally not helping you.  On the flip side, people who are drowning in a stream of their own words are often relieved  when somebody else just takes that conversation and puts it out of its misery.  Humanely.  Okay, so tech, those are sort of my suggested tactics.  And they kind of fall into two classes, right?  Like really, there's don't go there.  And there's if you find yourself going there, stop and turn around.  That's pretty much it, right?  You know, it sounds easy, right?  But it's like if it were easy, we would all be doing it.  And we are not all doing it and we are certainly not all doing it all the time.  So okay, strategic questions, which do not ask yourself these questions in the moment  because if you think about them too hard, and you should think about them hard, right?  But if you think about them too hard when you're trying to do something like talk to  a person, your brain will freeze.  You will not become more coherent.  But these are questions that it's worth thinking about when you're not under pressure because  they will help you determine what your tactics are.  So one of them, when we were doing speaker training, Anna kept drilling into us, audience,  audience, audience, like who are you talking to, what do they want from you?  Like go through the list of people or the classes of people that you interact with frequently  and think about like, okay, so how have these interactions gone for me?  Like do I like talking to these people?  Do I dread talking to these people?  Why do I dread talking to these people?  And if you feel able to ask some of them directly for feedback, it's totally worth doing that,  like ask them if there's something that they would, you know, how does it feel to interact  with you?  Are there things that they would like from you that you're just not doing naturally?  Another piece of that is like, are you having the right conversations with the right people?  And so this is sort of a circle of commitment model, link is below.  This was originally developed by a pastor at a very large church, and it has caught on  and been modified by a bunch of different kinds of organizations.  But I find this useful as a way to organize my thoughts around what conversations I'm  having with what groups of people.  Because a lot of us, especially when we're involved in something very deeply, we tend  to just sort of treat everybody like their core, right?  Like everybody is us, they share the same priorities, they share the same goals, they  share the same level of commitment.  And you know, that's just kind of not true.  And when we treat everybody like their core, you know, like their priorities are exactly  ours and they're just as dedicated to them as we are, that just throws the door wide  open for incoherence to wander in.  Like you hear this a lot with metrics data, like a thing that I hear a lot when people  talk about metrics is, my audience is everyone because everybody should care about this.  Well, I don't think that's helpful, right?  It's probably true that everyone should care.  I can tell you that everyone is not going to care in exactly the same way, at exactly  the same time, about exactly the same thing.  Like they're just not.  So another strategic point is, is there a different conversation you need to have?  And I actually think this is, I will preface this by saying that I think that one thing  that causes people to gibber is that they really want to have a different conversation  and that conversation is trying to sneak its way in into the one that they're actually  having.  So when we find ourselves bringing every conversation around to some topic, we need to stop doing  that.  We really need to stop doing that because we're making other people not want to hear about  whatever it is.  There are tools that I totally do not use because somebody has shown up every time.  I've had my hands full with something and wanted to tell me how if we were using that  tool, we would not be having this problem today.  And they could be right.  Like I am not disputing their correctness one bit, but that is not the conversation I  needed to have.  Another thing I should say is that different conversations, like that's actually, I think,  a place where learners can push, right?  Because a lot of times we try to fit in training into these very operational, very pragmatic  conversations that we're having about like how do you do this thing, we want to do this  and get this done.  And a lot of times what I find is that when people are learning, they need to have a little  bit of a wider conversation.  So examples, there's historical ones.  Why did we switch from that to, you know, why did we switch from MongoDB back to Postgres,  right?  Speculative.  What would be the reason to switch from MongoDB to Postgres?  Don't answer that.  Deep technical questions or conversations, right?  So Julia Evans wrote this really awesome blog post called How to Ask Good Questions.  I think that that's sort of a good way to frame some of these things.  Like at a good way to talk about how you initiate, having a conversation that's a little bit  wider ranging than how do I do this thing right now?  And affective ones.  Like I am unhappy about whatever it is, right?  And these are conversations that might be happening for you.  They might not be happening for you just based on, you know, like what work you're doing  and who you happen to be pairing with and who tends to be around when you feel like talking,  right?  So another one.  How much conversational space do you tend to occupy?  So imagine you're really excited to learn about something and I'll just throw distributed  systems out there because it's a field that attracts this particular thing.  But anytime somebody even thinks about distributed systems around you, like there you are, like  you want to talk to them, right?  Like because you're really excited and you want to hear what they have to say and you  want to share what you've been reading, right?  And the thing is that it's like sometimes this is awesome and sometimes, and you know,  and I think it always comes from a good place.  But did you pay enough attention to these conversations to know whether your interjection  is relevant or whether people are okay with being pounced on while they're thinking about  distributed systems, right?  Like maybe two people are talking about something that's really stressing them out with, you  know, some system that they're working on.  Maybe like this is a one-on-one where one person really wants to hear very specifically  what the other person thinks about this and they're just not ready to take in more feedback,  right?  Like having somebody show up and say, you know what, I read this really cool paper about  the RAS theorem.  It might not, you know, it's not quite so useful, right?  On the flip side, like imagine a time when you were so nervous about asking for help  debugging a problem that you've been working on for a really long time, right?  And the nervousness is partly because you've been working on it for a really long time  and you're ready to be done, but you also feel bad about working on it for so long.  So you finally get somebody, you know, paying attention and you just blurt out everything  that you've tried in one big, long sentence, right?  Anybody ever done this?  I've done this.  Totally done this, right?  Like, and this is a place where like you are so concerned about not taking up space that  you aren't really thinking about whether anybody can process that one sentence, right?  Like, wait, stop, no, what did you do?  I don't know.  So yeah, those are all things to think about.  They won't help you in the moment, but thinking about them, I think, might help you.  So sort of, my last thing is like strategy is situate yourself, right?  And this goes back to my original definition of coherence as a good use of available bandwidth,  right?  And with such bandwidth do you really have in a given interaction?  So we are not brains and jars isolated from our environments, right?  Like, if someone is overworked, then it's going to be really hard for you to talk to  them about something that's totally outside of their context, right?  Like, it just is.  Like, the available bandwidth there is just not that big.  If you're that overworked person, like, how can you use the bandwidth the best, right?  Like, if you're outside of that, what are you doing to make room for that person to talk  about stuff?  Because, you know, like, the bandwidth goes both ways, right?  Like, they're probably going to have a really hard time bringing stuff to you.  So like, that's one way that, you know, situation matters, right?  Like another one is if you're just dealing with people who are not organized enough to  be able to be transparent, right?  And this happens a lot.  You know, every interaction is going to require extracting and paging in a ton of information.  In a ton of new context.  And this is not a situation that makes people feel or sound more coherent.  So at the end of the day, some of these might be things that you can't fix.  Like, you sort of can't really do anything about somebody else being overworked or being  the only person who knows about whatever it is.  But what you can try to do is you can try to implement, try to pick your tactics well  and try to do them as effectively as you can and acknowledge the constraints that you have.  So that's pretty much it.  And I'm going to do a slightly geeky thing and redo the last line of a, it's the last  stands of a poem by William Stafford called A Ritual to Read to Each Other.  And it is a poem about people missing each other like ships in the night.  For this important that awake people be awake.  Or a breaking line may discourage them back to sleep.  The signals we give, yes or no or maybe should be clear.  The darkness around us is deep.  Thank you.  Thank you.  Thank you.
Faking_Coherence_for_Engineers_0_131.png Faking_Coherence_for_Engineers_132_227.png Faking_Coherence_for_Engineers_228_1715.png Faking_Coherence_for_Engineers_1716_4079.png Faking_Coherence_for_Engineers_4080_6395.png Faking_Coherence_for_Engineers_6396_7367.png Faking_Coherence_for_Engineers_7368_11171.png Faking_Coherence_for_Engineers_11172_12107.png Faking_Coherence_for_Engineers_12108_16811.png Faking_Coherence_for_Engineers_16812_17063.png Faking_Coherence_for_Engineers_17064_17423.png Faking_Coherence_for_Engineers_17424_17507.png Faking_Coherence_for_Engineers_17508_18203.png Faking_Coherence_for_Engineers_18204_20735.png Faking_Coherence_for_Engineers_20736_22451.png Faking_Coherence_for_Engineers_22452_25343.png Faking_Coherence_for_Engineers_25344_25979.png Faking_Coherence_for_Engineers_25980_26855.png Faking_Coherence_for_Engineers_26856_30011.png Faking_Coherence_for_Engineers_30012_31571.png Faking_Coherence_for_Engineers_31572_33131.png Faking_Coherence_for_Engineers_33132_33503.png Faking_Coherence_for_Engineers_33504_40127.png Faking_Coherence_for_Engineers_40128_40811.png Faking_Coherence_for_Engineers_40812_44243.png Faking_Coherence_for_Engineers_44244_46895.png Faking_Coherence_for_Engineers_46896_47855.png Faking_Coherence_for_Engineers_47856_48443.png Faking_Coherence_for_Engineers_48444_49031.png Faking_Coherence_for_Engineers_49032_50015.png Faking_Coherence_for_Engineers_50016_52043.png Faking_Coherence_for_Engineers_52044_54059.png Faking_Coherence_for_Engineers_54060_55391.png Faking_Coherence_for_Engineers_55392_58247.png Faking_Coherence_for_Engineers_58248_58859.png Faking_Coherence_for_Engineers_58860_60899.png Faking_Coherence_for_Engineers_60900_61751.png Faking_Coherence_for_Engineers_61752_61859.png Faking_Coherence_for_Engineers_61860_61875.png
Hi. Thank you. So, I forgot to do my forced breath breathing. Oh, well. There's this breathing exercise that we learned to calm us down before we speak. And it just went in one ear and went out the other. Sorry, Anna. So, that's me. Hi. I'm Yvonne Lam. My Twitter handle is up there. Release Engineer is not a specific title at Chef. We ranked along the SDE track. Basically, I just tell people I'm a release engineer because it's shorter than saying what I do, which is that I work in the team at Chef that does internal tools, CI, CD. And we basically manage all the infrastructure for building, releasing, and publishing software packages that Chef uses. So that's what I do. Everybody always says when I say a lot of things, but really that, wow, that was really meta. So, that's the kind of talk this is. It's kind of who I am. I've decided to own it. So here we are. So, what is coherence? I realize this is kind of a weird title. I mean, it's kind of a weird talk topic. So, I'm going to take a couple of minutes and lead us into it. So what is coherence? Well, I think of it really, this is my geeky definition. I think of it as getting the right amount of information into the amount of bandwidth that you actually have available to convey it. So I think of it as kind of a packing problem, right? Like that it's like, okay, so you're interacting with another person or a group of people. This is how much room you have to tell them stuff. How are you going to tell them stuff efficiently? Like what choices are you going to make around that? Coherence isn't exactly easier to define, but I think it's really recognizable, right? You all know when you get that feeling that it's like, oh, God, I've just told them a whole bunch of stuff and I'm not sure if they took any of it in, right? Like anybody here ever not feel that? And I know that when somebody sort of loses track of their train of thought with me, that my response is like, okay, I know they're trying to be helpful, but now I'm going to have this bunch of stuff that I need to fish through to figure out what in that is actually going to be useful to me. And I'm not necessarily sure that anything is. So I mean, it's a little bit of a loaded description, right? I mean, because sometimes you really don't understand something and you really do have to sit down and take the time to think about it and process, but I don't think it's an inaccurate one. Like it's not an inaccurate description of the feeling. Okay, so why talk about coherence at all? So my answer is actually, there's a little bit of backstory to it. So I have a friend who is an early career academic and she's in a field that is very competitive and as you probably know about academic jobs, like it's a very competitive market. There are a lot of people for very few jobs or can be and so the interview process is pretty grueling. And as an early career person, she had the opportunity to be involved in a bunch of hiring loops at her institution. So like people get really excited about this and they always ask her like, so what advice can you give me? Like it's my first time on the job market. What you know, like tell me what I should do. And her response, which I thought was really interesting was don't ramble and be as coherent as you can manage, right? And her point was not that you have to be perfect. Her point was that in a video interview, which is how all of these things start, it's really easy to weed somebody out because they're just not getting to the point. And I thought this was really interesting because I have never heard anybody give that advice to an engineer, right? Even though I think a lot of us, there was a point in, you know, like there was a point in our careers where we really needed that advice and really needed to take it in. And you know, on a lot of days, it's like, yes, it would be good if somebody would just remind us that it's like, it's good not to ramble, right? Like it's good to be clear and to be as clear as you can be. So, like, why do I care? Like, why do I care about coherence? And okay. So the answer, so the short answer, right? I mean, an answer that fits on a slide and that is good for somebody skimming through the PDF of this thing afterwards, right? It's, well, you're like, when people are coherent, right? Like it's easier to work with them. It's easier to get the work done. You have less friction, less delay. Lack of coherence creates friction. So this is a good enough answer that fits on a slide, like I said. And my real answer is more complicated because I'm meta and that's what I did. So I think of coherence as invisible infrastructure. So there's this great book by two scholars, Susan Lee Starr and Jeffrey Bunker, where they talk about infrastructure. And what they really talk about is how infrastructure is effective because it's invisible. Like that's how you get the gain from infrastructure. Like, it's invisible. People don't need to know about it. People don't need to think about it. They can just sort of like go on and do the thing and not have to focus about like, I don't know, like, are the lights going to turn on when I hit the light switch? The other thing that they talk about though is that invisibility can also make infrastructure less humane and less maintainable, right? Because it's like, how do you talk about something that's supposed to be invisible? Right? Like, there's a lot of mental load against doing that. So I listened to a lot of DevOps conference talks, which I expect a lot of you here do too as well. And a good chunk of them have a story, right, about a project that ended up better because the participants worked through intense disagreement about something, right? And they had a lot of positive friction and that ultimately made the project better, right? Like, we have all heard this story and it's a great story. I would love to be able to tell that story. But as sort of a, I don't know, deep introvert, mildly the slimy type, like, when I hear these stories, like, I always end up wondering about negative friction, right? Like, I always end up wondering about like, how does the team repair negative friction, right? Like, you know that nobody is perfect and that people are sometimes short with each other, you know, they misunderstand the question and they give a long answer to a question that wasn't really asked. But, you know, so there is negative friction, like, there's always going to be, and the question is like, well, so how does the team repair it, right? Like, and is it the team that's repairing it or are there individual people doing it because they think it's important and nobody else really knows, notices that there even is friction or that repair is happening all the time, right? So I kind of think of that, like, that sort of ties into my thing about invisible infrastructure. And I see managing coherence, learning how to be more coherent, creating space for people to be less than perfect in their expressions, like, I see that as one aspect of that invisible repair. Okay. So, how does lack of coherence create friction? So, I think in a lot of ways, right, like, that it's like, we know that it takes time, right, and attention and emotional labor to understand each other when we are less than, you know, when we're just less than clear, right, for whatever reason. And there are a lot of things that just go wrong when we're trying to deal with that friction, right? Like, there's a, like, it's just load. And, you know, like, if we think about it, we can think of a ton of examples. And, okay, so, like, what? Well, did that bullet actually appear? Come on. So, well, one of them is, like, what are the things that could go wrong? And one of them is, like, just inefficient message passing between humans, right? So, that's my really sort of geeky, short hand for, we don't talk to the people we should when we should, right? So, anybody here ever give up, you know, just like you didn't give up, but you put off doing code review or triaging a bug because, like, you read the description and you just did not understand what the person was trying to do, right? Like, this happened to anybody? Okay, see? Right, like, how many of you have put off talking to somebody because, like, you just had it had enough coffee that you felt like you could make yourself understood? Yeah? Okay. And how many of you put off talking to somebody indefinitely because you always have trouble taking in what they're saying? Yeah, see? Okay, like, was that good? Like, was that, like, exactly. Like, so, like, this is the thing that happens all the time. Like, we do this all the time, right? Like, if it adds load and we can find an excuse to just, like, no, don't want to go there, don't want that load today, then, you know, then we just kind of avoid it. So another reason why I think coherence matters, right, is when we perceive somebody as being coherent, right, like, or incoherent, we end up with a picture of, you know, their knowledge, their authority or their capability. And, you know, that might be us too. Like, it's hard to feel like a competent person when you're just like, oh, I totally messed up that explanation and all I did was confuse that person worse, right? And this matters for a lot of reasons, right? Like, so, one of them is that, you know, it just kind of feels bad not to be able to make yourself understood or not to understand other people, right? Like, my very neutral example of this is that if you're traveling in a country where you don't speak the language and you're there for a really long time, you just kind of get tired after a while, right? I mean, you know, you just, you know, like, there are people who, like, I know people who never go to McDonald's, but when they're traveling someplace where they don't speak the language, they're just like, okay, I'm going to McDonald's because some things will be in English, right? And it will just be a break. And, you know, it's hard to have a good opinion of somebody that you don't understand. It's hard to have a good opinion of yourself when you're not making yourself understood. So, that's the thing that I think matters. Like, it's a reason to me why coherence matters. The third thing is that in order for what you do to be valued, other people have to understand, like, why it matters. Like, they have to, I mean, they have to know that you're doing it. They have to know why it matters. They have to know that it is, you know, that it's a thing in the world. It's not just the thing, it's not just like the light switch, right, where they can just like the light switch and the lights come on and it's just kind of magic. You know, and it's really hard to be valued if you feel like you can't get your point, you know, you can't explain why you matter, why what you do matters, okay? So why is faking coherence? Like why not just fixing it, right? Like, we're engineers, we're tech people, we want to fix things. My really depressing answer is that I just don't think you can. I don't think it's possible. I wish it were because then I could stop having those days where it's like, no, I don't want to talk to anybody for like the next three hours because I don't think I can possibly be understandable. So why not? Well, nobody's perfect and that's a pun. So we have bodies. I can absolutely guarantee you that people will want to talk to you when you haven't slept or when you've had too much caffeine or you're coming down with the cold or even when you're just like thinking deeply about something else and just like don't, it's like, sorry, all the swap is gone. I don't have any room to page right now. You know, like it's going to happen, right? Like, it's not going to stop. Another thing is that perception of coherence I think depends a lot on the conditions of your labor, on the conditions of your work. And so like I can probably best explain this with an example. So I've been like the one ops person embedded with a team of devs. How many of you have been in that situation, right? Like security, QA, you know, like you're the one person on the team doing what you do and the rest of the team, you know, it's not that they all do the same thing, but they have very similar functions. They understand what they do. So I've been that one engineer and it was really hard to make my concerns hurt, right? Like everybody else is their focus is on shipping new features. And I'm trying to get somebody to sign off on a data retention policy so that we can tell our customers how long we're keeping their stuff. Yeah, sometimes I sounded completely incoherent because I was trying to talk to people who had all of their contacts paged in and none of mine. And sometimes I was completely incoherent because I got totally frustrated trying to explain like, no, really, we need to be able to tell people how long we're keeping their stuff. And you know, there's sort of a point here, which is that even though there was probably something that I could have done to get better at making my case, there was ultimately so much I could, there was really only so much I could do to fix the fact that, you know, everybody else just is doing something else, their focus is different. I am the only person with my very specific context and I'm going to have to like get all of that into their brains or, you know, a good chunk of it into their brains so that we can actually talk about this thing and they can understand why it matters. The next one is sort of, well, you know, other people are incoherent too, right? Like other people are not perfect. They're going to be coming down with colds. They're going to be running late. They ask questions that don't make sense, right? Like they're stressed out because they're trying to explain something to you and you're totally not getting it because they're the expert and you're not. And the thing is that incoherence is really a state problem, right? Like once somebody goes down the rabbit hole, it's hard to pull them out again and when you have a group of people, it's even worse. Like we've all been in that meeting, right? Where like one person understands one thing, misunderstands one thing and they're just, and they sort of like start running and then the rest of the room is like, wait, stop. And then they try to explain it to them and, you know, this person gets like five different explanations that aren't the same. So yeah, you know, it's like, it's very easy for incoherence to spread. So this is kind of why I think incoherence is a problem we're thinking about, right? Like it's not just that it feels bad, but it does. And that dealing with other people's incoherence is emotional labor that we might or might not be able to equip to deal with like at any given moment. It's, you know, it's just that it's like, yeah, the badness spreads. And a really abstract one, right, like is we are a craft field, right? And by that I mean, so this is a paraphrase from a professor named Jerry Rockwell, and he describes a craft field as one that developed to share knowledge that cannot be adequately captured in discourse, right? Like so basically you can't just explain what it is that we do to somebody and expect them to understand it, right? Like, like we learn by doing. That is how knowledge in our field spreads, right? Computer science is a craft field, right? Software engineering is more so and ops engineering is even more so. And you know, one big feature of craft fields is that we learn by doing and that constrains as practitioners how fast we can grow our individual scope, right? Like, and we're not only in craft fields. We are in craft fields that are expanding. So what that means is there's a lot to know. No one can do everything and doing is how we learn stuff. So no one can know everything in any kind of level of usable detail. And so we're all walking around not really understanding a lot of what it is that we do or not being able to explain it well, right? And so this is a reason for all of us to try to do better, right? Like there's going to be a lot of incoherence and confusion around just by the nature of what we do. So there's something to be said for not adding to it when we don't have to. I mean, in part, this creates slack for people who really don't have any choice about being incoherent like because they're learning, because they're new, because they're working in something that is their native language, because this is a completely new context for them. Like, you know, it's good. I think it's as a value. I think it's good to make space for people like that. And you know, those of us who can reining in our incoherence a little bit when we can, like I think that's sort of a good thing to do. So, okay, so what can we do about incoherence, right? Like I convinced you it's a thing. You know that, like I didn't have to do that, right? Like you knew that. And I really see this as having two components, sort of tactics and techniques piece and a strategy piece. And because we are all engineers and we love us some life hacks and we love us some techniques, I'm going to do the techniques first because it's the part that everybody thinks it's fun. Okay. So, I think of this, yep, you're on the right side. I think of this really as how to put a decent API in front of your brain, right? Like you have all of this infrastructure, right? Like where you're thinking about things and you're processing and you're taking any things and you're trying to sort of juggle it all around. And you know, and the people that you're dealing with, they don't really want to know all of that. Like they just kind of want to know, like, okay, like, like what parameters do I have to send in to get the thing that I want back? Like, so this is really how I think about it. My disclaimer is because I think people in this field get a lot of pressure to be perfect, is you don't have to do this all the time, right? So coherence is very relational and it's very context dependent. And I think of it as being like playing catch or tennis or ping pong or any of those other games where like you're trying to move a ball back and forth between a bunch of players. The theoretical ideal of this game, right? Like this is the thing that we all sort of learn when we learn how to play ping pong or whatever is that you want to maintain a volley so that the game has momentum, right? Like it's not interesting if you're spending all of your time chasing the ball. But that's theoretical, right? If you're playing catch with a little kid, you probably don't really care all that much. Like, you know, like it would be a very mean person who would just like yell at a little kid because they couldn't throw the ball back or catch it every time, right? Like if you're playing fetch with your dog, well, okay, I don't have dogs, I have cats. Playing fetch with a cat is like you're not doing this to maintain smooth movements of the ball. Let me tell you this, it's just not a thing. And you know, like if you're tossing a frisbee around while you have a drink or a cookie or whatever on one hand, like, you know, you are not playing the perfect theoretical game of catch. Like you're just not doing that, right? There are conversations where everyone involved is totally happy not being entirely coherent, like, you know, and that's fine, right? You know, like they're fine just like they're brainstorming so fast that it doesn't really matter if they miss one idea out of three, you know, or that they don't really quite understand how this other person got from point A to point B. Like, but they're happy, it's fine, it's good, don't mess with them, right? Like that is not, those people are not the problem. Those conversations that we're all having that are like that, they're not the problem. The problem is when someone is unhappy because what they want out of the conversation is to understand something or to feel like they're being understood and they're not getting that. So with that, I will move along to my actual giant list of techniques. The first one sounds really dumb, but it is, finish your sentences. Yes, it really does sound dumb, but it works, right? Because if you have ever sat in a meeting and watched somebody like winding a sentence around them more and more and they're just trying to find their way out and they can't and you see them looking frantic and you're just like, I don't know, would it be better to interrupt them because they might explode or would it be better, or like when we get to the end faster, I just kind of like give them the free reign to let them unwind themselves. Right? I mean, so like, you know exactly what I mean, that it's like the sentence gets too convoluted and people can't find their way out again. Like there is a point where people are paying more attention to whether the speaker is ever going to extract themselves from that sentence than to what the person is actually saying. So you know, if you catch yourself not, if you catch yourself like winding a sentence around hoping that you'll get to the end, just stop it. Just stop that sentence, like everybody will be happier. Another one is to limit repetition. Like I'm not saying never repeat yourself. But if you find yourself repeating yourself, repeating your words a lot, that's a tell that you've lost track of your point. You know, that it's like this one I think is hard for people to deal with and I think that my ideal would be it's like, well, you could set an alerting threshold and it's like below the threshold, it's fine if you don't repeat yourself. But you know, it's like once you hit a threshold of repetition, then you know, just stop, just stop right there. In practice, that's a harder thing to pay attention to, but if you can do it, it is, like it's helpful, right? Like even if you can't do anything about it, just noticing, okay, I've said the same thing three times, I really need to stop this conversation. Like that's helpful, right? That's a way to be, that's just a way to present as more coherent. The next one is using can responses. So I think this one is really good for, like obviously since they're canned, they're things that you have to plan a little bit ahead of time. But it is good for things where you can sort of prep ahead of time. So what are can responses? Documentation, I like documentation. I understand not everybody does, I know I'm weird. But the reason why I like documentation is that I have no qualms about sending links to people with documentation to docs that I wrote. And I do it because it makes it easier for me to be helpful, right? Like I don't do very well at saying the same thing over and over again when I feel like I'm not being understood. And you know, it's not, sometimes people need time to absorb things. And it is, like I understand that, but in the moment I don't really understand it, right? So there are things where it's like, yes, if I know I'm going to get asked this question a lot, I will just write documentation and when people ask it, I will point them to the docs. So another way that documentation is useful is that you can sometimes get really good return on investment on writing docs. Someone I worked for once, my first ops boss, showed me a very detailed email that he had written at a previous job about everything that was wrong with their extremely complicated deployment. And it was a beast. You know, it was mostly manual, they were managing like a couple hundred machines. It was bad. Like their deployments took days and they didn't always work. Surprise. And he was at that job for years. And when he showed me that message, I noticed that it's like it had been forwarded so many times. Right? Like he had, he probably reset that email about 20 times to like different groups of people or sometimes the same people or whatever. But so he got a lot of good value out of that mail. And yeah, it's totally annoying that in the eight years he was at that job, the stuff did not get fixed. Right? Like, but you know, some of it did and a lot of it didn't. But he also didn't have to emotionally revisit every single thing that was wrong. Anytime somebody is like, well, why did that deployment fail? And I can't, you guys just nerd harder. Like, you know, he was pretty thorough. So he got a lot of value out of it. And he came off as really organized and really consistent because he was just like, you know, I told you this before and I'm telling you it again and maybe you didn't take it in. So here you go. Another of my favorite can responses, which many people who work with me have heard me say is that's interesting. Which is kind of a weird one, right? But it's for me, it's because I feel like I come across as less coherent when I get sucked into having a conversation that I sort of don't want to have. Right? Like it might be because I've had it too many times. It might be because I'm not really prepared to have this conversation. It might be because, I don't know, it's before lunch and I really just want to go and eat, okay? But sometimes it's just worth letting the conversation go to voicemail. And you know, that's interesting. I have to think about it, like is a way of doing that. So another one, conscious use of heuristics, right? So a heuristic is just a fancy word for a strategy that you form from previous experience with a similar problem. And you know, we do this all the time. Like we might not have the words for it, but we say things all the time like, okay, so you're having this problem that looks, did you update the lock file? Right? I don't know, it's like, so okay, did you upload the latest version? Is the thing that you're looking for actually there? Right? Like, so we just apply these all the time. Like somebody gives us a problem. It sounds like we're not really doing exact pattern matching to a thing that we've seen before, but we know it's probably in the neighborhood of something like, something we've seen before. So we throw out this suggestion. So I really like heuristics because they give me a way of getting at bad assumptions. And I use them all the time. Like, I use them to debug my own stuff as well as other people's. And I have a, the way that I do this is I have a set of questions that I can ask about a wide variety of problems. Like what problem are you trying to solve? Like anybody use that one? Right? Because, you know, when you get out of Rathole, it's, you kind of forget what yak you were trying to shave. And it's kind of good to like have it be brought back to like, okay, so what am I really trying to do here? And another one that I've been known to ask a lot is, so why do we have to do it this way? Like what are the alternatives? Like what could we do instead? Do we have to build this thing? Because you know, the software that you don't have to build, this is good software. We like that. So another general category of tactics I think of as corral your conversation. And this is really about organizing the conversation upfront so that it just kind of has fewer chances to wander off into the weeds. And remember, this is a public service, right? Incoherence is contagious. So once one person gets it, everybody else goes there too. And you're just all kind of like wandering around going like, hello, anybody else here? So what do I mean by corraling conversations? Sticky notes, they are your friend, right? So sticky notes are a great tool to have in hand when you know ahead of time that the conversation is likely to wander. Years ago I worked at a company with somebody who was a very smart guy, very good to work with, but he went off on tangents, very long tangents. And a bunch of us got really frustrated because we would go to him and ask a question, and this was in person because we were still like actually co-located physically. And you'd go to him and you'd ask a question and you'd walk out of his office an hour later having heard a lot of words, but just like wait, what did I go there for? What was I trying to get help with? I don't remember anymore, which is kind of demoralizing, right? So what we learned to do is we learned to write our questions on a sticky note and carry it with us. So that when we went in there, we had a sticky note and every time he started wandering, we could sort of look at the sticky notes like, oh, right, that's what I meant to ask. And we tried to be pretty subtle about it, and I don't think he ever noticed or his feelings were hurt if he did, or maybe he just thought, I don't know, they think they're really forgetful, so they wrote the question down. But their reason, I can see concerns that people have about doing a very explicit instrumental tactic like that, but it actually worked really well. It made it easier for all of us to work together. So another sticky note technique that I learned recently is from one of my friends who, when she knows she has to talk about a problem where she's likely to become less coherent for whatever reason, like it could be, it's something that she's really feeling very emotional about or it's something that's really complicated and she has all of the context and nobody else has any of it. What she does is she writes and rewrites what she wants to say until it fits on a sticky note. And by the way, it is totally a victory if she can boil down what she wants to say until it fits on a smaller sticky note. So this is about containing what you say so that it can fit into somebody else's brain. So another one, another technique that you can do is you can invite specific responses. I think that this one is, you know, this one takes a little bit of practice and it takes a little bit of, like you can't just, like this one's hard to deploy on this part of the moment. That's really what I'm trying to say. But what are specific responses? Well, this is a sketch of a new feature to do X, right? Like when you see this in a pull request, right, like what kind of feedback do you think the person's looking for? They're probably not looking for exact perfect, you know, this is going to be in production tomorrow. It's like, like they know, okay, this is an idea. Somebody is trying to say, this is how I'm thinking about it. Like, you know, you have a broader scope to talk about it. So if you've done tech reviewing for tech books, like it's very common for people to say I want feedback about content and I don't really care about spelling or punctuation right now. So, you know, it's very specific. It's very bounded. It might not be what you're able to do, but it's very specific and very bounded. A really good one to use when you are teaching or when you are trying to convey something complicated to somebody else is, so is what I'm saying making sense to you. Like get the feedback as you go so that, you know, you don't wind yourself up in the coil trying to explain something to somebody because you can see that they're not getting it until you just try to explain harder. You know, so I think that, so I think those are suggestions. And if all is fails, just reset the conversation. Sometimes I, and everybody who's worked with me has heard me say this, right, like what I just said was really complicated. I think I can say it more simply, would you like me to try again? And if they say no, then take no for an answer, right? Like filling the air with words is totally not helping you. On the flip side, people who are drowning in a stream of their own words are often relieved when somebody else just takes that conversation and puts it out of its misery. Humanely. Okay, so tech, those are sort of my suggested tactics. And they kind of fall into two classes, right? Like really, there's don't go there. And there's if you find yourself going there, stop and turn around. That's pretty much it, right? You know, it sounds easy, right? But it's like if it were easy, we would all be doing it. And we are not all doing it and we are certainly not all doing it all the time. So okay, strategic questions, which do not ask yourself these questions in the moment because if you think about them too hard, and you should think about them hard, right? But if you think about them too hard when you're trying to do something like talk to a person, your brain will freeze. You will not become more coherent. But these are questions that it's worth thinking about when you're not under pressure because they will help you determine what your tactics are. So one of them, when we were doing speaker training, Anna kept drilling into us, audience, audience, audience, like who are you talking to, what do they want from you? Like go through the list of people or the classes of people that you interact with frequently and think about like, okay, so how have these interactions gone for me? Like do I like talking to these people? Do I dread talking to these people? Why do I dread talking to these people? And if you feel able to ask some of them directly for feedback, it's totally worth doing that, like ask them if there's something that they would, you know, how does it feel to interact with you? Are there things that they would like from you that you're just not doing naturally? Another piece of that is like, are you having the right conversations with the right people? And so this is sort of a circle of commitment model, link is below. This was originally developed by a pastor at a very large church, and it has caught on and been modified by a bunch of different kinds of organizations. But I find this useful as a way to organize my thoughts around what conversations I'm having with what groups of people. Because a lot of us, especially when we're involved in something very deeply, we tend to just sort of treat everybody like their core, right? Like everybody is us, they share the same priorities, they share the same goals, they share the same level of commitment. And you know, that's just kind of not true. And when we treat everybody like their core, you know, like their priorities are exactly ours and they're just as dedicated to them as we are, that just throws the door wide open for incoherence to wander in. Like you hear this a lot with metrics data, like a thing that I hear a lot when people talk about metrics is, my audience is everyone because everybody should care about this. Well, I don't think that's helpful, right? It's probably true that everyone should care. I can tell you that everyone is not going to care in exactly the same way, at exactly the same time, about exactly the same thing. Like they're just not. So another strategic point is, is there a different conversation you need to have? And I actually think this is, I will preface this by saying that I think that one thing that causes people to gibber is that they really want to have a different conversation and that conversation is trying to sneak its way in into the one that they're actually having. So when we find ourselves bringing every conversation around to some topic, we need to stop doing that. We really need to stop doing that because we're making other people not want to hear about whatever it is. There are tools that I totally do not use because somebody has shown up every time. I've had my hands full with something and wanted to tell me how if we were using that tool, we would not be having this problem today. And they could be right. Like I am not disputing their correctness one bit, but that is not the conversation I needed to have. Another thing I should say is that different conversations, like that's actually, I think, a place where learners can push, right? Because a lot of times we try to fit in training into these very operational, very pragmatic conversations that we're having about like how do you do this thing, we want to do this and get this done. And a lot of times what I find is that when people are learning, they need to have a little bit of a wider conversation. So examples, there's historical ones. Why did we switch from that to, you know, why did we switch from MongoDB back to Postgres, right? Speculative. What would be the reason to switch from MongoDB to Postgres? Don't answer that. Deep technical questions or conversations, right? So Julia Evans wrote this really awesome blog post called How to Ask Good Questions. I think that that's sort of a good way to frame some of these things. Like at a good way to talk about how you initiate, having a conversation that's a little bit wider ranging than how do I do this thing right now? And affective ones. Like I am unhappy about whatever it is, right? And these are conversations that might be happening for you. They might not be happening for you just based on, you know, like what work you're doing and who you happen to be pairing with and who tends to be around when you feel like talking, right? So another one. How much conversational space do you tend to occupy? So imagine you're really excited to learn about something and I'll just throw distributed systems out there because it's a field that attracts this particular thing. But anytime somebody even thinks about distributed systems around you, like there you are, like you want to talk to them, right? Like because you're really excited and you want to hear what they have to say and you want to share what you've been reading, right? And the thing is that it's like sometimes this is awesome and sometimes, and you know, and I think it always comes from a good place. But did you pay enough attention to these conversations to know whether your interjection is relevant or whether people are okay with being pounced on while they're thinking about distributed systems, right? Like maybe two people are talking about something that's really stressing them out with, you know, some system that they're working on. Maybe like this is a one-on-one where one person really wants to hear very specifically what the other person thinks about this and they're just not ready to take in more feedback, right? Like having somebody show up and say, you know what, I read this really cool paper about the RAS theorem. It might not, you know, it's not quite so useful, right? On the flip side, like imagine a time when you were so nervous about asking for help debugging a problem that you've been working on for a really long time, right? And the nervousness is partly because you've been working on it for a really long time and you're ready to be done, but you also feel bad about working on it for so long. So you finally get somebody, you know, paying attention and you just blurt out everything that you've tried in one big, long sentence, right? Anybody ever done this? I've done this. Totally done this, right? Like, and this is a place where like you are so concerned about not taking up space that you aren't really thinking about whether anybody can process that one sentence, right? Like, wait, stop, no, what did you do? I don't know. So yeah, those are all things to think about. They won't help you in the moment, but thinking about them, I think, might help you. So sort of, my last thing is like strategy is situate yourself, right? And this goes back to my original definition of coherence as a good use of available bandwidth, right? And with such bandwidth do you really have in a given interaction? So we are not brains and jars isolated from our environments, right? Like, if someone is overworked, then it's going to be really hard for you to talk to them about something that's totally outside of their context, right? Like, it just is. Like, the available bandwidth there is just not that big. If you're that overworked person, like, how can you use the bandwidth the best, right? Like, if you're outside of that, what are you doing to make room for that person to talk about stuff? Because, you know, like, the bandwidth goes both ways, right? Like, they're probably going to have a really hard time bringing stuff to you. So like, that's one way that, you know, situation matters, right? Like another one is if you're just dealing with people who are not organized enough to be able to be transparent, right? And this happens a lot. You know, every interaction is going to require extracting and paging in a ton of information. In a ton of new context. And this is not a situation that makes people feel or sound more coherent. So at the end of the day, some of these might be things that you can't fix. Like, you sort of can't really do anything about somebody else being overworked or being the only person who knows about whatever it is. But what you can try to do is you can try to implement, try to pick your tactics well and try to do them as effectively as you can and acknowledge the constraints that you have. So that's pretty much it. And I'm going to do a slightly geeky thing and redo the last line of a, it's the last stands of a poem by William Stafford called A Ritual to Read to Each Other. And it is a poem about people missing each other like ships in the night. For this important that awake people be awake. Or a breaking line may discourage them back to sleep. The signals we give, yes or no or maybe should be clear. The darkness around us is deep. Thank you. Thank you. Thank you.
it's kind of a weird talk topic. So, I'm going to that is very competitive and as you probably know are less than, you know, when we're just less is how we learn stuff. So no one can know who really don't have any choice about being is kind of demoralizing, right? So what we lot of us, especially when we're involved in