Update Go Time 147 & JS Party 143 (#808)

Edits to Go Time 147 & JS Party 143

Co-authored-by: Thom Obarski <thom@thoughtbot.com>

gotime/go-time-147.md

@@ -520,7 +520,7 @@ Well, it's that time of the show where we do our unpopular opinions.
 
 **Peter Bourgon:** Don't bring us into your \[unintelligible 01:04:38.04\]
 
-**Mat Ryer:** Well, Jon does. In the privacy of his own dungeon is his own business; in his own code dungeon.
+**Mat Ryer:** What Jon does in the privacy of his own dungeon is his own business; in his own code dungeon.
 
 **Jon Calhoun:** I write this code thinking "I'm gonna have a real treat for myself later, when I try to read this..." \[laughter\]
 

jsparty/js-party-143.md

@@ -98,7 +98,7 @@ The patterns that I've noticed, again, in big enterprises, in small companies, i
 
 So if I'm a developer and I'm given a story in a backlog or a task as part of a team to implement a frontend experience, or a mobile app, or a backend server, or an API, or whatever - yeah, sure, the company has these big values about users first, blah-blah-blah; it doesn't matter, because the code needs to be the code, right? That's how most people think.
 
-But the reality is there's this concept of -- again, as a person who has to own budgets and has to own long-term planning for team members and technology, there's a concept of the total cost of ownership of something. If I'm gonna make a decision on something, I need to measure the total cost of ownership about it. And to me, that kind of breaks down into five different things - the cost of knowledge, meaning if I'm gonna adopt their library, what do I have to expense in terms of time, energy and dollars to make sure that the knowledge of that library is equally distributed across the team members that I have? And there's a relation there to how big the team, and also in relation to how long I need to keep this thing going...
+But the reality is there's this concept of -- again, as a person who has to own budgets and has to own long-term planning for team members and technology, there's a concept of the total cost of ownership of something. If I'm gonna make a decision on something, I need to measure the total cost of ownership about it. And to me, that kind of breaks down into five different things - the cost of knowledge, meaning if I'm gonna adopt their library, what do I have to expense in terms of time, energy, and dollars to make sure that the knowledge of that library is equally distributed across the team members that I have? And there's a relation there to how big the team, and also in relation to how long I need to keep this thing going...
 
 Which leads to the next one, which is the cost of maintenance. Like, fine, you've adopted a library, you've adopted a service, you've adopted an infrastructure tool, but how long is this gonna be going on, and how long are you gonna be invested in maintaining it and invested in having team members continue to run it, or update it, or deploy it, or monitor it - whatever the functionality is, given the component that we're discussing.
 
@@ -110,7 +110,7 @@ There's all these kinds of concepts that people have to measure before they get
 
 So when I look at this big picture of the cost of ownership, I look at the way people make their decisions and the way people try to take shortcuts by saying "You know what - I can build a login system myself. It's only a couple of libraries, and my cost of adoption is a day's worth of work, or two days' worth of work before I go and just deploy it... And then I'm done and it's clean. This is it, this is the cost." And they forget about the maintenance, they forget about knowledge sharing, they forget about the ecosystem around it, and they forget about the infrastructure involved.
 
-So that's kind of like the preamble to where are those solved problems that exist already, and how people try to re-solve them or reinvent the wheel around them... And my experience has been also in - like Amal has earlier pointed - all the stuff that I was able to get things shipped; I get things shipped by simplifying the problem and getting down to the basics, rather than trying to break things apart and say "Hey, let's use this library instead of that." I start with the basic thing of saying "Why were you even doing this to begin with? Let's discuss there. Are there shortcuts and cheaper options to follow?"
+So that's kind of like the preamble to where are those solved problems that exist already, and how people try to re-solve them or reinvent the wheel around them... And my experience has been also in - like Amal's earlier point - all the stuff that I was able to get things shipped; I get things shipped by simplifying the problem and getting down to the basics, rather than trying to break things apart and say "Hey, let's use this library instead of that." I start with the basic thing of saying "Why were you even doing this to begin with? Let's discuss there. Are there shortcuts and cheaper options to follow?"
 
 **Break:** \[00:17:44.18\]
 
@@ -146,7 +146,7 @@ So that's kind of like the preamble to where are those solved problems that exis
 
 **Amal Hussein:** Exactly. No, and why.
 
-**Ahmad Nassri:** Yes. Because you can say no all day long, and it can be a benevolent dictator for life type of thing, but that doesn't help the person grow... But if you invest the time in showing them - so to your point, Jerod, yes, kids are not gonna learn until their burn their hands. And the same thing happens with developers and professionals in general. Until they actually experience the thing, they can read about it in a book, they can hear it from a person, they can be shown to it indirectly, but until they've experienced it... I cannot call myself an expert until I've experienced it, right? And the same applies for software development in all aspects, and professionals in all aspects.
+**Ahmad Nassri:** Yes. Because you can say no all day long, and it can be a benevolent dictator for life type of thing, but that doesn't help the person grow... But if you invest the time in showing them - so to your point, Jerod, yes, kids are not gonna learn until they burn their hands. And the same thing happens with developers and professionals in general. Until they actually experience the thing, they can read about it in a book, they can hear it from a person, they can be shown to it indirectly, but until they've experienced it... I cannot call myself an expert until I've experienced it, right? And the same applies for software development in all aspects, and professionals in all aspects.
 
 So how do you make that opportunity of the "We're not gonna do this, because I know from experience it's bad, but how do we make sure that you don't go into that pitfall or similar pitfalls later on?" And that's where the "No, and..." context come to meet, where it's like -- and Amal knows this... I'll be like "Go create something. I'm gonna tell you some things to avoid, but go do it, and then we're gonna see if we're gonna launch it or not." Then we're gonna see if we're gonna deploy it or not. Because if you have the opportunity as a manager or a leader to give the team members the time - and the critical point is the time, because it's costly - to go down that path, get their hands burned, and come back, then great. Let's do that. That's a great experience for learning, as long as you're also holding on to the no.