Fix unintelligibles

Author: kball

jsparty/js-party-93.md

@@ -104,7 +104,7 @@ And then I think there's "pebble", which is a tiny change, maybe a stylistic twe
 
 And then for someone giving feedback, I could also allow the person who submitted the PR - what exactly they should focus on, so things could be merged quickly, rather than starting a huge conversation and then having to jump on a call. And it made it much easier and clearer, because there were no feelings hurt; you weren't saying someone's a terrible programmer. You were just purely talking about the specific syntax or the thing that they're working on.
 
-**Jerod Santo:** \[00:20:29.05\] I've been on the giving end and on the receiving end of lots of rejection online... \[unintelligible 00:20:33.09\] so on the requester side, whether it's a PR or an issue, it's like "I have this problem, or this goal in mind, and I would like it to be solved, or I would like to fix it, I would like it to be a part of this project." And then on the maintainer side, or the receiver of the issue, or the PR, it's like "Well, does this fit into my worldview? Is this a place that we're going?" There's a whole bunch of things involved. So just a general rule of thumb - this goes for all writing, by the way; pretty much all communication - but specifically the context of potential conflict... Because this is a potential conflict every single time; it could be great, it could be bad... There's a potential of this not going so well, whether I'm giving or receiving, so one thing I always like to remember is the primary audience is the key thing to any sort of communications. "Who is my primary audience?" And the first step in realizing that, before you say "Well, it's a software engineer", or "It's Feross again. He keeps opening PRs on my thing" - before any of that, it's like "This is a person. This is a human, with their own strengths, their own weaknesses, their own context, their own goals, personality..." We're this huge, messy thing, all of us. And we're the same in many ways, and we're different in many ways... But before I start writing, I have to remind myself, it'a person just like you on the other side of that text box. Remember that first. That, I think, helps me craft my responses, whether in the positive or in the negative, with care and with some level of empathy.
+**Jerod Santo:** \[00:20:29.05\] I've been on the giving end and on the receiving end of lots of rejection online... talking about PRs, so on the requester side, whether it's a PR or an issue, it's like "I have this problem, or this goal in mind, and I would like it to be solved, or I would like to fix it, I would like it to be a part of this project." And then on the maintainer side, or the receiver of the issue, or the PR, it's like "Well, does this fit into my worldview? Is this a place that we're going?" There's a whole bunch of things involved. So just a general rule of thumb - this goes for all writing, by the way; pretty much all communication - but specifically the context of potential conflict... Because this is a potential conflict every single time; it could be great, it could be bad... There's a potential of this not going so well, whether I'm giving or receiving, so one thing I always like to remember is the primary audience is the key thing to any sort of communications. "Who is my primary audience?" And the first step in realizing that, before you say "Well, it's a software engineer", or "It's Feross again. He keeps opening PRs on my thing" - before any of that, it's like "This is a person. This is a human, with their own strengths, their own weaknesses, their own context, their own goals, personality..." We're this huge, messy thing, all of us. And we're the same in many ways, and we're different in many ways... But before I start writing, I have to remind myself, it'a person just like you on the other side of that text box. Remember that first. That, I think, helps me craft my responses, whether in the positive or in the negative, with care and with some level of empathy.
 
 **Kevin Ball:** That's a great place - both because we're talking about remembering people are human, and because we're talking about conflict - to take a break before our next segment, where we will be talking about communicating with stakeholders and non-technical co-workers.
 
@@ -176,7 +176,7 @@ You've gotta start from "What does this person actually care about?" I guarantee
 
 So listening is hard to do, especially in long form, especially when you just can't wait to say that thing that you've been thinking about for this whole time... But if you don't have the context of the person and if you can't gauge their technical level, you ask them.
 
-One complete failure of this - which I think we all have had, or probably been on the receiving side of, is when you call a help support desk of any kind, as a technical person. They do not ask you that question, like "Do you know...?" I \[unintelligible 00:39:52.25\] the other day, because our vacuum was on the fritz. And the person doesn't have any idea what context I bring besides "My vacuum is broken." In that case it's a pretty easy solution, but lots of times you call and they're "I'm going to read you my script."
+One complete failure of this - which I think we all have had, or probably been on the receiving side of, is when you call a help support desk of any kind, as a technical person. They do not ask you that question, like "Do you know...?" I just called Dyson the other day, because our vacuum was on the fritz. And the person doesn't have any idea what context I bring besides "My vacuum is broken." In that case it's a pretty easy solution, but lots of times you call and they're "I'm going to read you my script."
 
 \[00:40:09.19\] And when the first thing is "Did you try rebooting?" or "Is your Ethernet cable plugged in?", if it's these things which can very well be the problem, but as a technical person you're like "I know what's going on...! I understand the OSI model. I can understand networking. Please stop talking to me like this", well, they didn't do any listening at all; they're just reading their script. So that's a really good example - they have no idea what your context is, they don't care, and they offend a bunch of people, because they never hit that level very well, unless you're a total noob. So that's an example of failure on that.
 
@@ -338,6 +338,6 @@ Because you, knowing the software, or knowing the situation, or knowing all of t
 
 **Jerod Santo:** Don't hate on them, don't hit on them... What else shouldn't we do? Hm... \[laughter\]
 
-**Kevin Ball:** Generally, I think - coming back to your point, Jerod, of remembering they're human. They're people. They're trying to do real things. We should feel compassion for them, despite the fact that they may not be thinking about things the way that we think about things. They're still, at the core, human, the same as us, and so we should be relatable, we should be empathetic, we should be sympathetic to their challenges, and not always think in our heads "Oh \[unintelligible 01:03:06.12\]"
+**Kevin Ball:** Generally, I think - coming back to your point, Jerod, of remembering they're human. They're people. They're trying to do real things. We should feel compassion for them, despite the fact that they may not be thinking about things the way that we think about things. They're still, at the core, human, the same as us, and so we should be relatable, we should be empathetic, we should be sympathetic to their challenges, and not always think in our heads "Oh PEBKAC"
 
 I think we're about at time, so let us wrap this episode of JS Party. Thank you for joining us for the party, as always. Thank you, panelists - thank you, Jerod, thank you, Feross, thank you, Divya. It's been a good time, and we'll catch you next week!