Soft Skills Engineering - Episode 30: Reaching Consensus and Code Editing Etiquette

Episode Date: October 8, 2016

In this episode, Dave and Jamison answer these questions: How should you reach consensus on a team? Should you always have consensus? What is the etiquette around editing code in a shared repository?

It takes more than great code to be a great engineer. This is Soft Skills Engineering episode 30. Can you believe we made it to 30? Yes. Because we just did. I didn't doubt us. I'm surprised the producers haven't canceled us yet, those TV execs. Yeah.

Well, if we get canceled, then we'll just develop a cult following. I was just about to say, I think we've produced more episodes than Serenity. and better too obviously no controversy there oh poor serenity rip you mean firefly right oh did i say the name of the movie and not the tv show i always get those confused yes i did mean firefly but serenity is ratted also okay should i read our first question absolutely i will do it how do you reach consensus on a team should you in meetings it's hard for some leaders to reach consensus with a team like for example whether to use doc strings in python code what styles have you seen work well for managing this how

do you make sure everyone on the team gets a chance to be heard without being stymied stymied that's like a 64 word yeah this is from an anonymous listener um so thank you thank you mysterious stranger thank you okay uh consensus so what is consensus do you want like a dictionary definition agreement yeah i think that's does it does it imply unanimity i don't know all right let me let me check really quick i just got my mechanical keyboard working again so you can you can tell i'm yeah it sounds like a sounds like a machine gun range consensus general agreement

oh that doesn't sound like you that's not very helpful so consensus on a team what i would ask is why do you need consensus like what's the point of getting consensus i'll tell you why because i absolutely refuse to put on a pair of socks until i have a hundred percent buy-in from my whole team they gotta be right yeah otherwise the morale suffers that's right um i guess to me the goal of consensus seems to be to make sure that everyone is i guess i i joked about morale but it seems like a morale thing that Um, hopefully if you decide something, people won't just be like rebelling and doing the opposite, but they might be grumpy about it if they feel like they don't agree with the

decision. So maybe go ahead. I was going to ask then, is it, is it about making sure that everybody gets their two bits in or is it more about making sure you have good outcomes on the team? Yeah, that's, that's what I was going to say that if, if the goal is morale and if, if you can make people feel like, okay, I expressed my concerns, they understood them. there are these valid objections and we went a different direction even though i disagree like they listen to me maybe that's enough uh to to to achieve the same goal which is you're all moving

in the same direction and no one's no one's like sabotaging the ship yeah that can be a bad situation so it's more about making sure everyone can move forward see i don't even know i just i really have a hard time with defining this one even though i know when consensus is working right like i know i the feeling on a team is like really apparent yeah well there's an easy example in the question about about some kind of code style issue or kind of documentation style issue like whether you use doc strings in python code and and you could substitute that for whatever language and style issue you want um in my experience those those are fraught discussions because everyone has strong opinions about code style and and yet it's really valuable to have

an agreed upon code style as a team so how would you do it that way it's it's basically impossible to get everyone in a room and have them all agree on every aspect of code style but somehow it's it's valuable to have a shared team style so how do you do that yeah because a lot of times it just ends up being with whoever has the strongest personality gets to govern what the code style is yep yep i've known lots of people like that where they win arguments through exhaustion people just give up because they're never gonna that the other person will never give up so i have argument stamina yeah exactly they just win because they're still standing and everyone else just walks away it's like whatever i don't i don't care they were like well i guess my style

was best um it is true and these these conversations can go way too long and it takes a strong leader to stand at the front of the group and say okay i think we've discussed this enough um if you feel strongly about it come talk to me privately and if not i'm gonna send out a style and or like a maybe i'll send out an email or write a wiki page and uh if i get enough plus ones we'll just go for it you know yeah that's a great point about the length of time thing where you sometimes there's value in any decision and you just got to make one and if you're worried about everyone agreeing 100 and not making anyone upset then you might just be paralyzed about uh about two years ago we were um going to implement code reviews at my current company and i was the the lead of the

engineering team and we had about 30 developers on the team and we were going to choose a web-based code review tool and we basically had several contenders and people felt pretty strongly about it they were like well i've used garrett in the past and i've and other people said i've used review board and there was this you know there was github of course which we couldn't use for contractual reasons but and then there was this up-and-coming project called git lab which is basically an open source github clone and it was my job to basically lead the team to choosing the right tool and notice how i that's how i felt my job was and i didn't say to choose the right tool but my job was to help lead the team toward it and i actually had several meetings

where i actually asked people hey if you have opinions about code review tools i'm going to schedule some time and sit down with you and collect all your thoughts privately, like one on one, tell me everything you like and dislike about various tools and options around the table, rather than having like, okay, we're going to do a gigantic roundtable meeting with 30 people, and everyone's going to try to chime in, you know, and it actually came out, it was pretty fruitful. And we ended up making a choice. And there was not consensus 100%. There were people who said, I would rather have x or y. And, but it still worked out because everybody had a chance to voice their concerns and when we when i finally did present the final choice i was able to say

look here are the trade-offs we're making here's the good here's the bad you know this one has this feature that's better than this other thing but it doesn't have this which this other thing does have but we're not choosing it and i think at the end of the day we were able to be productive and work without getting stuck into argument by exhaustion that makes a lot of sense how do you decide when it's been enough time when you've heard enough feedback because there's always some in these kind of decisions if there's not some element of trade-off then the decision is easy and you don't it's clear you don't need to worry about people being mad because because everyone will agree so you're you're in a place where you feel like you kind of know what people

think and there are just different things that seem balanced against each other how do you how do you actually as a team member or a leader how do you participate in that like in a if you're like in an open discussion with everyone at the time is that what you're saying like no not in an open discussion just just a team like i'm not thinking about like the time when you're all in the meeting together i'm thinking about how you get to the decision however however i don't know however that looks i mean i think once you've heard from everybody you know you're never good by the way you're never going to hear from everybody because there will always be team members who just don't really care that much right or at least aren't expressive enough to

really go after it with you but when you start hearing the same things repeated and you haven't you've talked to several people and you haven't heard anything new i think that's when you say okay i think i've pretty well fully exhausted this space you know and then you have to make a call i'm talking so you say you make a call is your are you saying that the leader is is responsible for um sifting through it all and making the decision um not necessarily in fact no in fact i would say specifically no because the best decisions are the ones where the team like obviously the best easiest would be like you said if everyone already agrees but that would actually be a terrible situation um but i think uh the leader doesn't necessarily

make the call but when they do present the final decision it's like the team feels like they all arrived at that decision together that's the best situation even if it disagrees with their personal opinion yeah this is all pretty amorphous it is very amorphous because this is such this is like the softest of the soft skills this feels really really context super soft yeah just marshmallow downy soft i'm thinking about when this has happened throughout my career and i feel like i've seen all kinds of cases where it's worked well and where it hasn't worked well and it's very wildly what the approach was and it doesn't seem like it's correlated very strongly with what the outcome was like i've i've been on teams where it was uh someone took feedback from

everyone and then they just made a decision i've been on teams where it was just top down someone just made a decision they didn't even get that much feedback i've been on teams where there was exhaustive in-depth discussion for a long time and the team made the decision and all of those things have worked and not worked and and by worked i mean like were good technical decisions and the team was happy with how it worked out later on so i don't really know yeah there is definitely a way you can do it wrong which is letting it devolve into like you said like this stamina situation where people start repeating themselves yeah like once you've heard the same argument more than once from the same

person in one of these conversations it's like okay we're done here you know like you've already trotted that argument out and now we need to put it to rest yep so how do you figure out when you need to actually build unanimity with these kinds of things like what what is there like a certain level of importance on the decision that like the higher the importance the more unanimity is important um i don't i don't think so i'm i'm just trying to think and and really this one seems so so incredibly context dependent that i'm having trouble coming up with hard and fast rules yeah i think you're right i mean as far as like what the outcomes are i think for approaches it makes sense to make sure the team feels heard i think you could go either way between the team

making the decision and the team lead hearing everybody and making the decision but if you with either of those if if the team feels like they've been heard i think that seems okay i think that's a number one ingredient and there's probably trade-offs uh you you might be trading more time efficiency if one person is responsible for making the decision like they'll just hear it all and then go off in a room and then come back and that's the end of it versus the team might kind of go back and forth a lot yeah it's i guess it's it's hard to make decisions as a group if you if you have disagreement and there's no one in charge of resolving that disagreement if it's just everyone's job to make a decision um it tends

to just kind of stay with whatever it is right now i would say it's actually impossible yeah based on human experience yep yeah i've i've definitely been on flat teams and they have some great things and one thing that's really hard is making broad technical decisions like this or for example like should we switch to a new database or or what tech stack should we build this new thing in or whatever those kind of things where there are lots of opinions and everyone's opinion counts the same and there's no one in charge of gathering them all and kind of uh collating them those are those are hard they just stagnate yeah or like uh i don't know we haven't had great test coverage should we add 100 test coverage like those in in my experience those

work way better as you need 100 test coverage than like what should we do and then you all just talk about the trade-offs forever until you die and then it doesn't matter well i guess it didn't matter we're all dead yeah so i read this tweet from julia evans a couple of weeks ago that i I think she might be the most quoted person on this podcast. I feel like I've quoted her like four or five times. We should reach out to her and say, hey, you just earned an honor you didn't even know you wanted. She's like, I don't think it's an honor. So she said that, you know, it's hard to read a tweet sometimes, but it says,

old Julia says, it's hard to build consensus around decisions. New Julia says, getting 10 people to all 100% agree with you isn't how you do it. and i think that's totally true but it's so hard to figure out what is the subset of people that need to agree before you can really proceed and do you remember we talked about oh this uh it was a great changelog episode um interviewing the guy who created the c4 the code contribution their community code contribution contract or something and one of the aspects of it which we've talked about before is that you always move forward which means that if you have a problem with the way something is done, then you show your willingness to fix it by doing something

additional. Like if you have a problem with the way some code is written, submit a new pull request to fix it rather than just stymieing an existing pull request. And I think that with decision making on a team, that's important too. And it's like, Hey, you want to help write our style guide? Great. You can contribute. Your input has to be that you have to help write it. You know, it's not just, I have to say some things in a meeting and suddenly they become gospel. Sure. you know like the barrier to entry there is too low and so i think that'll help weed out the people who really don't actually care that much because sometimes engineers express an opinion and it

sounds like it's life or death but really they don't care that much right they're just saying what they think i have done that and i've seen other people do it too you just you just want to feel like you've thrown your blurb in and sometimes it feels powerful to have a strong dissenting opinion so you just i don't know it just comes up from nowhere yeah not to mention as engineers we're basically trained to identify the outlier in the edge case right it's like hey i just want to point out that if we do that database we're not going to be able to do inner joins everyone hear me you know yep like oh and that hush falls over the crowd dave knew that wow how did he know that what an impressive human being so i think as a contributor you need to

avoid that and also make sure to share not just your opinion but the strength of it as well like you could say i feel really strongly about this or i don't feel too strongly about this and then share your opinion that's a good point about strength of opinion that also made me think of um that there are some decisions that have larger impact than others and some that you're probably more okay uh kind of steamrolling people on or having dissenters on um something major like the core architecture of your product or or the the programming language that you work in every day that one you might want to try a little bit harder to get consensus but something like i don't know the the style of your documentation that that the outcome of the of the decision is not going to

affect things as much like for for some reason i i tend to get really really uh heated about little tiny style things and and i just need to be steamrolled in those because really they're not that big of a deal even though i have a strong opinion about it right but like say they follow my opinion or they don't the the delta between those two is probably not that big so and and it's mostly in your head in your particular brain i mean yeah that's where most of the delta is yep yep exactly every time you type a semicolon you're like i wish i didn't have to type this semicolon dave i am a weird human being because as soon as i said that i thought what about some visionary that finds out about this new language that's so productive and will like change the teams

the course of the team and they just make everyone do it and then they're all better off like you hear these stories sometimes uh i'd really love to hear the next blog post from like two years later once they've been using it for two years but but i feel like i have heard these stories about like this one person just really loved closure or whatever and they started using it and then the team fell in love and we're so glad we're using it's so awesome and yeah but for every one of those there's 10 people who try to do the same thing with haskell yeah you know and they didn't get the blog post yeah that's true there's no glory in avoiding success at all costs no no offense hasklers we love you guys but just wanted to make just wanted to use that

closet haskler that's good i i feel comfortable with you insulting my people all hasklers closet has i'm just basing that on their mantra of avoiding success at all costs there are dozens of us dave careful okay do we so speaking of consensus do we have consensus on this question i think we it's easier to identify the things not to do than the things to do and let me just try summarizing the things not to do you should not let these conversations spiral out of control into long running conversations. And you should not exclude people's voices inadvertently by choosing forums that aren't conducive to everybody contributing, right? Like not everybody is super comfortable just piping up in the middle of a, you know, 20 person

meeting. Um, and what else? Are those the only two things? Yeah. I think if, if you are a leader, So I'm going to say some things to do. If you're a leader and you're in the model where you will make the decision, if there are dissenters, I think you owe it to them to put effort into making sure they know that you understand their concerns, even if you disagree with them. I think that would help them feel better about it. if you're a team member if you feel like you're in a situation where the team has just been spinning its wheels i think it's perfectly fair to say like hey we're kind of going in circles and we we need to make a decision um and and that will work even better if you say and i'm i'm okay like i think this is the right thing but i'm okay if the decision is something else but we just need to make some progress yeah i like that and in fact the other thing i like to do is say hey everybody if this doesn't turn out how will we know and make sure people can say like for

example on the coding style thing like you were pointing out a minute ago there's probably not going to be huge dire repercussions if he goes if you choose the wrong one right but you could say how will we know so first of all establish like some kind of metric for success like if if this goes well it should look this way if it goes poorly it would look this way and then also put like a pilot period on it and say you know what we're going to do this for a month and see how that month goes and at the end of it we'll look back and say was it good or bad and i know some decisions you can't really do that with because they're too too much upheaval but with a lot of them you really can you know and just say hey we'll try it and see how it goes it was going real

well and then the moon turned to blood and we switched back to using single quotes instead of double quotes in our javascript strings and then it was fine and the moon yeah the moon blood color turned unbloody cheese yep back to cheese all right i think that means the question has been answered consensus achieved we did it do you want to read our second question dave yes this comes from listener kevin stone the subject is code editing etiquette which by the way is a tongue twister try saying that five times fast you said it impressively well editing etiquette it takes all my concentration what you didn't see is dave just slumped over in his chair in exhaustion okay from listener kevin stone he writes what is the etiquette around editing code in a shared

repository to put it simply there are two cultural factions at our company one is the older generation who has been at the company for over 20 years and feels very strong ownership of the files they touch the other consists of relatively newer but still senior engineers who prefer a more collaborative approach and don't mind if code they work on has changed frequently i often find it difficult to navigate the divide between these two approaches so what do we advise maybe we can talk about what you think the ideal etiquette would be just in a vacuum and then and then see if there are differences here so like the because maybe this is fine right like i don't know that's fine somebody punches you in the face when you when you edit their file it's okay you shouldn't

touch their dang file that's what you get told you not to touch my file johnny not in my house i was thinking we could explore the tongue twisting nature a little bit more and say what if it's editor editing etiquette okay edit don't edit my editor editing etiquette oh what if you're writing a document about editor editing etiquette would that be editing the editor etiqueting etiquette document you've lost me i just slumped over my chair again so so what do you think it should be like in the ideal world this is this is going to be purely opinion on my part um because i think that's weird you mispronounced fact

this is going to be purely my fact but um it seems to me like a healthy team is able to work in each other's code this is my experience and as soon as you have a piece of code that can only be edited by one person you have two problems the first one is a bus factor which you know it's kind of the gruesome metaphor which says what if this person gets hit by a bus and dies then what because of course at that point the only thing you need to worry about is the code no not the undo redo code oh that's so our quarterly profits are gonna suffer percentages that's so heartless um so the bus factors is number one thing to consider but the other one is um how do you know that that

code is like um well i guess really it's just the bus factor like i was gonna say how do you know it's like able to be maintained by your peers and high quality and stuff but but really that just goes back to the the bus factor like anytime you have one piece of code that can only be touched by one person you have a problem if that person disappears or goes on vacation or gets sick or any number of things yeah i think there are that feels right to me there are some places that practice um kind of like radical no one can own any code and they're everyone works in every part I think there could be value in that what I prefer is so definitely anyone can edit any code but people still kind of have just areas of specialty maybe because they've developed a

feature and I don't I don't know that you need to aggressively stamp those out but I agree with the premise that I should be able to just pull open any file and change a thing and make it better add a feature yeah and and I agree with that as well and when I say there shouldn't be ownership like that of a person sorry that a person shouldn't own a single file i don't mean that teams shouldn't own files i do actually believe team ownership is important because otherwise when there's a bug like who fixes it like who's who's on the line to get that done you know yeah that makes sense excuse me so i actually still remember the first time i still as if it was that long ago i still remember the first time i was a team lead it has been 10 years but i remember it

was me and one other developer and we were tasked with creating this new product together and we had had these nice conversations about how it was going to go and we talked about the architecture and stuff and then i got sucked into some meetings at one point and he just went whole hog and implemented a ton of stuff and i came back to the office and he's showing me all the stuff he built And I'm like, oh, oh. And at first I felt like this twinge of frustration, like how could you go behind my back and build all this stuff without talking to me?

I'm like, how am I going to edit this code in the future if I don't see how it's written? Or, you know, and I got kind of upset. I didn't really verbalize this. This all happened over the course of just a few seconds. But then I realized as the light drenched me, so, you know, rolled over me, the light of enlightenment, it hit me like a bus.

Did you get that? i did but you're supposed to laugh we don't have a laugh track jameson anyway the i got a little bit of enlightenment and i realized hey my feelings on this are unimportant i can catch up on this code i can get it i can figure it out but progress was made and that was the important thing and i've realized at that moment that i had to learn to let go so that other people could make progress on the project without me like hanging over them and you know reviewing every line and and uh just basically micromanaging so i did i let go and now i know there is no spoon there is a bus though there is a bus

so yeah it sounds like we agree that this is a bad situation this is a bad and wrong situation what does uh what does kevin do about it so that's it depends on his role on the team like is kevin responsible for this team or is he a contributing member of the team kevin is a dang whippersnapper he has not been here for 20 years i i'm assuming he's part of the other generation of newer but still senior engineers um which is the same thing as a little baby to the older generation you can edit my code as soon as i don't have to change your diapers yeah yeah once you tell me about the time you shook ronald reagan's hand

oh wait you didn't because you weren't alive yeah i i do think 20 years is a really long time to stay at the same company i just do i mean not all companies are like this but wow or at least to be working in the same code base good greek let's be honest that's a long time for a company to exist a software company yeah that's true uh yeah so you were talking about whether he is a leader or a member on the team so how do you influence the team to change this behavior without um basically tattletailing right yeah yeah i mean well even what if uh actually go ahead never mind i was gonna say that in this situation, I would probably have a conversation with the team leadership, but you have to be

careful not to come across as a tattletale because the last thing you want is to undermine the people on your team and throw them under the bus. Another bus metaphor just got in there. That's our third for those of you that are keeping track. And the way that I would do that is I would go to leadership and say, hey, I just want to understand our process and our, you know, areas of responsibility and how we work is this cool you know this way like is it okay is it cool if i edit other people's code or is that just completely taboo you know and make sure that the leadership on your team which is maybe even more than one person are aware that this is happening and then let them make a decision on it there because it could be that they don't realize that this level of code hoarding is

going on it could also be a thing that has just sprung up kind of yeah over time without any intention like it evolved yeah so so um not even that they don't realize it's there but that they they're kind of aware of it in the background but they're not yeah they're not they're not recognizing it as a problem and it definitely definitely is a problem it's like the missing step problem have you heard that before no this is like where you have you live in an old house and it's missing a step on the stairwell and everyone's lived there so long that they've just gotten in the habit of stepping over that step but then someone new moves into the house and they literally fall through the stairs you know and everyone's like oh why didn't you just

step over it it's like well i what a dummy you can't even walk on stairs so that that's what this feels like to me it's like if what you're saying is true james and this kind of evolved it could be a missing step missing stair step so um you can talk to the leadership and bring it up And then hopefully the outcome of that would be them kind of, I don't know, recognizing it's a problem and talking to the team and saying like, hey, everyone can edit everyone's code. Make sure they're not breaking your code or our code. See, I even did it. Make sure they're not breaking it, but it's not your code. It is our code.

See, and if I was in this situation, if I was the leader of this team and this complaint came to my ears, the first thing I would say is, where's our code review process? because a good code review process could probably mediate this situation how so well because it feels a lot different it feels different to me to have someone edit my project and then like say push it to production than it does for them to send me a pull request which is very different it's it's like asking forgiveness versus permission right you're like saying hey can i edit this code in the following way and give me feedback it gives you a chance to give feedback to review make sure it's going to be solid rather than saying hey you know just so you know i broke into your house last night and rearranged the furniture in your living room i hope that's cool i love what you've done

with the place it's so cool okay so you know mentally like psychologically even if you like the way that they rearranged your furniture you're still going to be upset so it's like a softer way of of introducing them to the idea that you are going to be editing their code instead of them just finding out and and it being a surprise okay and that makes sense even in the code review language that we often use like pull request merge request these words are like permission words right it's like i am requesting to edit your code yeah you know and i mean hey on open source projects it's not like we just give open commit rights to everyone right there's a review process and that means that there's ownership and yeah we don't just allow anybody to come in here and edit

stuff yeah so on a team you know why not have the same thing and i think this i think it would help a lot in this situation i'm just assuming that they don't have code review already yeah yeah i'm i'm reading the question again what if it's so bad what if it's so uh balkanized that um you're editing like 10 people's files if you're just making a change because often you have to make a change in a bunch of different files for a feature and what if the problem is just you're just like crossing so many borders that everyone is mad at you hmm I that seems like it just has to be a top-down thing at that point yeah yeah because Dave you mentioned this um when we were prepping you said that this is this seems like a symptom of a broken culture and yeah that's

really hard to change is just an individual member on the team with the authority of just like a person on the team yeah it really is hey heck it's hard to change culture even if you're the team lead yeah exactly if if you're highly influential on the team it's still really hard let alone if you're if you're kind of pushing against the the grain um i think didn't you have a story about uh yeah i do have a story about about something yes about words so i i have been in this situation before where it was a little bit less stodgy and formal the way that i'm hearing it described in this question but there was one time when i i learned that a peer of mine was working on a feature and i had also just learned about this new programming concept that i thought

oh this would be a perfect application of this concept and so i uh wrote up the feet the feature using this new programming concept and i made a diff and i emailed it to him and i just said hey check out this diff this might solve the problem i've heard about this concept and i think it really elegantly solves the problem that you've been trying to solve and he actually wrote back and was a little upset and he said you've now put me in a in a tough spot because i had a different solution in mind and now you've put me in a place where i have to choose between your solution which is already done and my solution which is not done yet but is different and more thorough than the one you've done because mine was actually a little bit of a shortcut and he was a little upset with

that and i realized that i've been in this situation before and i think that the key is in this situation would have been earlier communication with the people to say to them hey i want to make these changes but i need your help and guidance and just try to communicate up front what your intentions are rather than just saying here's your broken code i fixed you know hey i found all these stupid things and i made them smart that's a great point dave i um even if it feels like it's going to take you longer and there's all this overhead and you might have to incorporate some feedback that that on an absolute scale isn't exactly perfect or the thing you think is the right thing it can definitely pay um like productivity and team

dividends over the long term by by encouraging more collaboration i'm just thinking about some times where i've kind of like tried to cowboy code it up because i'm like ah these people don't know what they're doing i'll just do it myself and uh most of the time i was wrong but even the times where i was right it it i think it was still a net negative even because uh it just hurt the the team unity a little bit like you you kind of broke trust a little bit right yeah yeah exactly so so um this was the thing i had to learn that sometimes you can sacrifice like raw efficiency and productivity in the short term but it can be better overall if you just talk to people a little bit more yeah totally agree so i love that and that that might actually be a great solution i

mean pull requests are a a newfangled technology if people have been here for 20 years uh there's probably lots of code that's not on github or some other code review tool um so so just the old fashion code review of like look at this code on my computer uh or talking in person might be an easier or shorter term solution it's so hard though because there's like this mental block in my mind where it's different it's like sending a request like emphasis on the request to someone to say i'm asking permission to enter your castle well you could do it in a you could do it in a like a design doc then you could just say i mean you don't even need code written at that point you can just say hey i've looked at the feature here's my thoughts i think i'm gonna have to touch these

files too what do you think about it and yeah not make it explicitly like chief captain of this file may i may i modify it just say hey here's my idea and then if if they say your idea is awesome then that implicitly means you can touch this code ken has in your base yeah you can use words like proposal and uh like that to make it come off a little softer you know where you can say i have a proposal for an idea you know for a potential implementation instead of just saying here's how to fix all the things yep i like that idea one other key is this is a cultural thing but one other key culture element is to try to separate the concept of ownership from the concept of sole contributor. Like ownership should mean responsibility for something, not that you're

the only person contributing to that thing. In other words, if there's issues with it, like you have to help get them fixed, but you should, ownership means that you should create a environment where other people can contribute as well and still be productive. And I think they've actually conflated those two things here on this team yeah that's a thing that i think open source has really exposed a lot of developers to where there's usually some kind of owner of a project but all kinds of people just swarm on it and help if it's a large enough project and and lots of people welcome that participation because it means the code has more eyeballs on it there's more test coverage more features all that kind of stuff so but it also means you have to give up a certain

degree of control yeah you know you have to be willing to read other people's code yep and that takes time and effort and just get like furious messages on github about how much of a moron you are for not thinking in this use case exactly all right i think we've answered this question we definitely provided some answers we did code editing etiquette so this is a great question absolutely as with all of our questions if you uh are the asker or even a listener and find yourself in a similar situation and you uh either take or ignore our advice i'd love to hear the outcome of it and what happened afterwards absolutely we're just kind of tossing stuff out and it can be nice to see what comes back sometimes i would say we would especially like

to hear it if it comes out badly sure why is that serious i don't know just those are more interesting okay it's like i tried it and here's a new perspective your advice didn't work because of this other factor you didn't consider and it's like oh enlightenment as opposed to hey guys worked great you know high five if you're not failing you're not learning yeah just wait long enough that the pain has passed and you're not too mad at us anymore all right dave how can people hear more from us hit up our website on softskills.audio you can subscribe there you can link it to your friends and they can subscribe you can even listen to episodes in real time right there and stream them on the web page which is all good and fun and you can also hit us up on twitter if

you're a twitter user so follow us at soft skills eng where we publish each episode as it comes out you can be the first to know and that is also the place where you can submit your own questions that we will answer the questions we answered today came from twitter and we have so many in our backlog now it is fantastic we promise we'll work through all of them as quickly as we can feel free to send us a direct message on twitter you do have to have a twitter account to do that but you do not have to be a follower and we don't have to follow you but we might just dangle that out there yeah here's a little follower fruit that i'm dangling all right we'll catch you next week