Hi. Thank you. So, I forgot to do my four square 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 Lamb. My Twitter handle's up there. Release engineer is not a specific title at Chef. We rank 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, literally, 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, and 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, 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, what choices are you going to make around that? Incoherence isn't exactly easier to define, but I think it's really recognizable. 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 like 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 whole bunch of stuff that I need to fish through to figure out

what in that was actually, 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, 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 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, you know, 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, is, well, 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 do. So, I think of coherence as invisible infrastructure. So, there's this great book by two scholars, Susan Lee Star and Jeffrey

Barker, 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, right? 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 listen 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 spymic 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, because you know that it happens, 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, 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 shorthand for we don't talk

to the people we should when we should, right? Like, 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 happen 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, and, like, was that good? Like, was that, like, right, exactly. Like, so, like, this is a thing that happens all the time.

Like, we do this all the time, right? Like, it's, 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,

how we perceive, 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, then 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 a 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 like the light switch, right, where they can just flick 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 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.

Like, 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 a 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 misunderstands one thing,

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. Right? 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, and it does, and that dealing with other people's incoherence is emotional labor that we might or might not be able 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, named Jeffrey 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, 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 at 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. Okay, so what can we do about incoherence, right? Like, I've convinced you it's a thing. I didn't have to do that, right, like, you knew that. And I really see this as having two components.

Sort of, a tactics and techniques piece, and a strategy piece, and because we are all engineers, and we loves us some life hacks, and we loves us some techniques, I'm gonna do the techniques first, because it's the part that everybody thinks is fun. Okay, 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 in new 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 wanna know all of that. Like, they just kind of wanna know, like, okay, 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 wanna 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? Like, 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 movement 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, will we get to the end faster if I just kind of like give them the free rein 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, if you find 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 notice it, 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, you know, that's a way to present as more coherent. So next one is using canned 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 canned 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 gonna 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 get, 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. It was mostly manual. They were managing a couple hundred machines. It was bad. 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 had been forwarded so many times. He probably re-sent that email about 20 times to different groups of people, or sometimes the same people, or whatever. So he got a lot of good value out of that mail.

Yeah, it's totally annoying that in the eight years he was at that job, the stuff did not get fixed. But 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 any time somebody was like, well, why did that deployment fail? Can't you guys just nerd harder? 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. Maybe you didn't take it in, so here you go. Another of my favorite canned 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 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. 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, or I have to think about it as 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. We might not have the words for it, but we say things all the time like, oh, 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? So we just apply these all the time. Somebody gives us a problem, 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 we've seen before, so we throw out the suggestion. So I really like heuristics, because they give me a way of getting at bad assumptions,

and I use them all the time. 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 go down a rat hole,

you kind of forget what yak you were trying to shave, and it's kind of good to 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 up front, 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 wandering around going like, hello, anybody else here? So, what do I mean by corralling 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 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, you know, like, the reason, like, 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, okay, 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, this one's hard to deploy on the spur 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, right? They're probably not looking for exact, perfect, you know, this is going to be in production tomorrow. It's 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, and so you just try to explain harder. You know, so I think those are suggestions. And if all else fails, just reset the conversation. Sometimes, 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. Right, 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, 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. Who are you talking to? What do they want from you? Go through the list of people, or the classes of people that you interact with frequently, and think about, okay, so how have these interactions gone for me?

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. Ask them if there's something that they would, 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 one, another piece of that is 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. Everybody is us, they share the same priorities, they share the same goals, they share the same level of commitment.

And that's just kind of not true. And when we treat everybody like their core, 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? Like 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, right? Like there are tools that I totally do not use because somebody has shown up every time, like 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. 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 thing, 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, like why did we switch from MongoDB back to Postgres? 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, and 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 what work you're doing and who you happen to be pairing with and who tends to be around when you feel like talking. 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, there you are, you want to talk to them, right? Because you're really excited

and you want to hear what they have to say. 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 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? Maybe two people are talking about something that's really stressing them out with some system that they're working on. Maybe 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 wrath theorem. It's not quite so useful, right? On the flip side, 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 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? And this is a place where 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. Like, so yeah, those are all things to think about. Like, 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? Like, how much bandwidth do you really have in a given interaction? So we are not brains in 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's going to require extracting and paging in a ton of information and 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 stanza 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 it is 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.