Soft Skills Engineering - Episode 321: Politely, no and participation at scale

Episode Date: September 12, 2022

In this episode, Dave and Jamison answer these questions: How do you politely tell a reviewer politely, “Your suggestion is stupid. I will not do it” when you get stupid review comments. If you don’t do it then the pull request can’t move forward because of unresolved issues. If you do it, then you’re compromising your design you’ve worked weeks on for some fly-by random comment. A few months back, I volunteered as co-facilitator for my department’s NodeJS Guild meeting. At first, it was a struggle to get people to present. But I tried to lower the bar more and more until it was easy. I asked for 10-15m presentations, and eventually I realized people are happier “Kicking off a discussion” than they are “giving a presentation”. All the listeners are more engaged too, at least after the first 2 meetings doing this. Now I want people to share half-baked code, or problems they are struggling with, as part of our discussions. I want people to be able to be vulnerable. If we don’t collaborate on common problems until we feel they’re polished and won’t reflect badly on us, then we will all waste time solving the same problems. I also want this to scale across 15-25 small scrum teams. I think success could be my demise–if we have good discussions, then more people will come, but people won’t want to be as vulnerable with a larger group. In general, I think my own scrum team is very open and vulnerable to each other, but the remote work in the deparment has created distance. I want to help create more collaboration on similar problems and solutions. What would you do to keep this going, and improve it?

it takes more than great code to be a great software engineer this is episode 321 of the soft skills engineering podcast i'm your host jamison dance i'm your host dave smith soft skills engineering is a weekly advice show about all the non-technical things that go into the technical field of software development besides code i decided to go earnest this week or maybe i just couldn't think of a good intro but let's go with earnest yes i'm not lazy i'm earnest what exactly did you mean by earnest in this context i don't know it's not a joke intro it's it's like a real intro oh okay although some could argue that many of our intros are not jokes because they're not funny failing one of the key criteria of being a joke but this one's not funny

on purpose ah yeah it's not supposed to be funny it's supposed to be deep and meaningful it's ironically unfunny which actually makes it a joke again it cancels out okay yeah it the irony has under flowed overflowed yeah it's wrapped around yeah now it's funny again too many levels of irony do you want to thank our sponsor i do this episode is sponsored by compiler an original podcast from red hat discussing tech topics big small and strange more about them later i also want to thank our patrons thank you to the folks we shout out every week who are kent c dodds theodore savin memester josh jenny kim owen shardle craig motlin i love mavis the stochastic parrot alice jost andrew pollock no cheating leanne fair for the good

i'm lost in there robin williams did someone put robin williams in the name of this go go go uh that name of the really long town in wales kashokton ohio patron.com.au we're hiring ira chan monkey face emoji jonathan king testing is documenting.org oladapo fadie will angel who does not have stinky feet then who has stinky feet that is the next person who sponsored so they're communicating now this is a chat system with very high latency nick hathaway travis sanders braden canes john grant nick cantar and philip john basile thank you thank you to all those people and if you would like to join this group you can go to softskills.audio and click support us on patreon all right shall i read our first question yeah i

guess i you wouldn't even believe the benefits so i won't even say them too numerous to list so we just better not the benefits of reading the question of sponsoring us supporting us on patron okay you can do it but it's probably good and it's a surprise you'll find out when you do it so if you want to be surprised go to soft skills.audio and click support us on patreon is what you're trying to say here is this what i'm getting i think so yeah or if you can hear my child in the background maybe you can support us at the level where i can afford podcast specific child care and then the audio quality won't prove that's that's a good point we should create a new level for that jameson's babysitter yeah right now that babysitter is called ipad

but it's failing it was rejected today what you don't know is that we're actually recording this in a professional studio uh it just happens to be that the podcast next door is full of children they're delightful children yeah do you want to read our first question now yes this comes from an anonymous listener who says how do you politely tell a reviewer politely yeah it does say politely twice that wasn't just me okay uh quote your suggestion is stupid i will not do it when you get stupid review comment if you don't do it then the pull request can't move forward because of unresolved issues if you do it then you're compromising your design you've worked weeks on for some flyby random comment oh i feel this one in my bones are you the commenter or the

person the recipient of the comment how do i tell you i will not do this without blocking this i know for a fact jamison this one has to resonate with you on the receiving end because you're a people pleaser as am i yeah it depends on if i don't have any approvals though it depends on what the what the structure is like is it that they have rejected the pull request is it that they did not approve it but i have other approvals if that's the case then i'm happy to leave a pull request to this pull request welcome comment and then just merge it i'm actually surprised to hear this about you i would have expected you to get hamstrung on the fact that there's someone out there who does not absolutely love your code i hate my code so i'm fine if other people don't

love it that's just something we have in common we're just better friends you're like i agree squash and merge yeah i don't know that's a good point i don't know i i don't think i'm paralyzed if i have a way around it that's interesting to hear about you this is it's not every day that i learned something new about you given how many how many hours we've spent talking on this podcast. But I'm the kind of person where it's like, okay, I've got all my approvals. I'm going to go, uh-oh, someone thinks there's something different. I would then spend a bunch of time either trying to build a persuasive argument that they should agree with me and just let me ship it or incorporating their changes or something. Or maybe what you said, similar to what you said is,

yeah, I'll circle back and address those in a future PR. Yeah. Which means never. Yeah. When we have time to clean up that tech debt, your suggestion sounds great and you will never have time. And you get stupid review comments. So I have seen a variety of comments that you might call stupid. And I think the ones that are most frustrating to me are when I feel like the commenter is expressing a really clear opinion that makes me feel like they just have totally missed the point like they i don't know they just they came fresh out of a blog post that

says the word solid a lot and so they're like all pumped about just like these principles and and are not really responding to the content of the pull request but have this kind of just personal feeling of like code should be written this way without really talking about the the thing you're trying to do that's the stuff that is the most frustrating to me like disagreements of the right way to do things i think i'm i'm better at engaging with but if someone's like well actually i read on dev.to or whatever that website is that you're supposed to like put this many numbers of spaces then uh what do i do yeah when i say pull request welcome pull request on my pull request yeah and then when what happens when you complain about their

pull request on your pull request do they have to then say the same thing back to you pull request on my pull request on your pull request welcome yeah it's an endlessly rising tower it's pull requests all the way down yes what if the suggestion is truly stupid and i don't mean stupid i don't mean to say like the person is stupid it's just look they made a they had a bad idea and you you know like do you explain it to them do you explain why it's a bad idea it also probably depends on the power dynamics between you two like if your peers or if you're maybe more senior experience than this person then it's a lot easier to say i think i disagree and here's why you kind of like acknowledge it and then move on but but again i think it comes down to if they

are currently blocking this from going forward yeah uh and if they are then that's a harder problem because you you have to talk to them it's going to take longer you can't just you can't just do it i think you're right on with the power dynamic thing like if you're a senior more senior engineer and the person leaving the the suggestion that you think is stupid i'm going to just put this right back on the question asker because i don't usually like to say the word stupid to describe someone's pr comments but if you think something is stupid and you're more senior i think you owe it to the person because of your seniority to take it as a teaching moment and explain why it's not a great idea and this is a very fine line to balance but this is what makes

a great senior engineer great is the ability to explain something with the heart of a teacher that's not condescending and doesn't wreck the relationship but does educate you know so like there's an objective reason why it's a bad idea you should explain that reason like you owe it to them because if you don't they're just going to go make that same comment on some other pr and end up just wasting time there's that have you heard that phrase that it takes way more time to refute bs than to say bs oh no but man that is so true like it's a lot of work to be a kind careful teacher it's it's way more work than it is to say like i think you should invert the order these arguments because i like it better i think the the benefit of teaching is people learn but

the cost is it sure takes a lot more of your time and if this happens a lot then you might need to address this problem at a cheaper place than in pull request comments or in code review comments by by i mean what would the cheaper place be it's kind of like getting ahead of it i guess i don't know i had a more concrete suggestion here it's distracted by a child building an imagination scape in my room while i'm trying to record this podcast what um he's he's got a bunch of magnet tiles and is constructing a castle of some kind it's a castle of pull requests stacked on top of each other and i have to go tell him it's stupid actually this does describe this describes the interaction when i'm helping my kids build lego

which is i say why don't we put this thing here and they say dad your suggestion is stupid and i will not do it and then i stop suggesting and say okay tell me where to put stuff oh i'm trying of fished the useful thing back out of the brain soup the lukewarm stew of late afternoon post-work brain juice how about we flip this one on its head and say are you the person doing random flyby comments on someone else's code that's like been you know had weeks of thought investment into it and uh you're just like oh yeah well maybe you should have camel cased that variable that's how you get points that's how you win so you prove value oh i remembered what the thing was and it's gone dang it that was fast i have holes in my brain oh yes yes yes yes i got

it okay is it gone again no it's here it's fixed firmly in my mind there is a related thing that might help here that isn't directly solving this problem but could maybe work around it which is some kind of agreement on the team about what kind of things are okay to block a pull request for versus what aren't oh i've seen oh there's a blog post floating around somewhere using like rock terminology not rock and roll like uh builders geological yeah this is a boulder this is like a blocking thing that has to get fixed this is a pebble this is a little thing you might want to think about and that way you can give some information about how important you think it is that your feedback be followed if you're just pointing out like hey did you think

about this other place in the code and you probably didn't it's not a huge deal if you didn't don't require any change necessarily like if you don't qualify it this way then each comment in the ui for code review looks like it carries the same weight but some of them might be neat things that you noticed and some of them might be disasters that you're trying to avoid so if you get some agreement on your team about uh like when you're commenting and reviewing code be clear about how how blocking or how serious this is and also some kind of agreement of like what kinds of things merit blocking a a change from being merged in then the suggestion might be stupid still but it might be a non-blocking suggestion the suggestion might be like change all the variable

names to spongebob case but this is this is a pebble so i think it'd be cool if you did yes not blocking and you can say it would be cool if i did it but i'm not cool so i'm not going to do that yeah i like that a lot maybe that helps in the future yeah i don't know that doesn't work around the core disagreement of like sometimes people disagree on what the right thing to do is and sometimes they disagree strongly it kind of does help though because what in my experience when people have disagreements on code like this especially if it seems like quote unquote stupid it's because the team has not established guidelines on what they should be doing in the code reviews for each other and so it just turns into whatever my human mind thinks of while

reading your code i will write on your comments you know yeah it's just this is just stream of consciousness exactly this is the the real-time human meat winter running your function definition made me think of the taste of bananas and that's what i'm going to tell you now not approved and i hate bananas so you better change this um and so yeah i think your idea to establish ground rules about what is and isn't acceptable in a code review is a really good idea so okay like let's say that you do that but then you still get stupid comments and quote unquote stupid um because it's And they're stupid boulders. They're mountains.

Yeah. Stupid mountain dangers. Your mountain is stupid. I think that in this case, I like to ask people point blank. Hey, should we hold up the merging of this code review for your comment? Just ask them point blank. Do they insist on it? Right?

And if the answer is no, we can talk about it later. If the answer is yes, we have to talk about it now and get it sorted. and and because like you said jameson like what was it the phrase you used a minute ago it's easier to something than respond to something what was it oh it's easier to say bs than to refute it exactly and the problem there is externalities right like the the bs writer or producer does not have to pay the cost of the bs consumer right um so why not share that cost by forcing them to um answer answer the question ah write write me a blog post about why this isn't stupid instead of i write you a blog post about why this is stupid yeah yeah can you imagine

getting that response you're like i think you should change your variable name and the response is please write a blog post about why your idea isn't stupid it's like the most passive aggressive response ever yeah if you could just help me understand why this isn't stupid i'd be happy to take your suggestion i never came out and said it was stupid i just need you to justify why it isn't oh my gosh can you imagine anyway my point is that make them carry some of the load of substantiating their claims by asking by asking them if they think we should hold up the pr like let's get very explicit about this like should we hold it up or not um it's kind of like forcing what you were saying like force them to identify this as a mountain boulder or pebble yeah i like

that hmm well have we answered it i think so it's so hard to know the right thing to do but i think in the end kindness will prevail and should prevail right so don't tell them their idea is stupid but do say you could definitely say something like from my perspective this doesn't seem like a good idea i have a few reasons for it but can you give me more perspective on you like in other words don't invest a whole crap ton of time right yeah but do the minimum amount of effort to kindly express that you don't agree necessarily with their approach and could they please explain more and if they can't i feel like i never mind move on great yeah and and maybe actually sometimes you might find out that you're the stupid one that's happened to me before the

stupid was coming from inside the house it was within you this whole time yeah yeah i also like your suggestion a lot about asking them if this is worth blocking shipping this because that's a hard question to say yes to there's just a lot of there's a lot of pressure um so this is you could use that for for evil potentially but like that will require more justification on their part than like yeah i think i think this should be different because you're making the cost more clear to them of of following that i agree all right okay now it's been answered hey jameson have you heard about that podcast from red hat called compiler isn't it the podcast that transforms human voices into bytes interpretable by machines yes that's the one like every podcast

so the show compiler comes to you from the makers of command line heroes and is hosted by angela andrews and brent simono yeah i've listened to it a bit i listened to episode 18 which is about productivity and i learned about the co-action effect which i will not explain to you so that you go listen to it i hadn't heard of that before and it was cool they also had an episode on compilers and there were fewer really corny jokes about the name of the podcast than I expected, but very informative. They had one of the GCC developers on there to talk about compilers, which was great. Yeah, I've been listening too. It's an awesome show. I liked the episode on how Red Hat ran a long standing, like multi-year, I want to say

10 year challenge for employees to hack their monitors inside the building to put up a meme image. And I don't want to spoil it, but let's just say that it ends with a business gap. Probably my favorite kind of podcasts are shows that tell outsiders how things work inside big tech companies and have access to people and perspectives that you don't see every day. Very interesting. You can listen to Compiler on Apple Podcasts or anywhere else that you listen to podcasts, and we'll also add a link in the show notes. Check it out. Now I will read the next question, which is from an anonymous listener who says, a few months back i volunteered as a co-facilitator for my department's node.js guild meeting at first it was a struggle to get people to present but i tried to lower the bar more and more until it was easy i asked for 10 to 15 minute presentations and eventually i realized people are happier

kicking off a discussion than they are giving a presentation all the listeners are more engaged too at least after the first two meetings doing this now i want people to share half-baked code or problems they're struggling with as part of our discussions i want people to be able to be vulnerable. If we don't collaborate on common problems until we feel they're polished and won't reflect badly on us, then we will all waste time solving the same problems. I also want to scale this across 15 to 25 small scrum teams. I think success could be my demise. If we have good discussions, then more people will come, but people don't want to be vulnerable with a larger group. In general, I think my own scrum team is very open and vulnerable to each other, but the remote work

in the department has created distance. I want to help create more collaboration on similar problems and solutions what would you do to keep this going and improve it huh i want to scale this across 15 25 small scrum teams does that mean 15 to 25 individual teams doing the same thing or one giant mega guild meeting with 15 to 25 teams worth of people in it i feel like the second one is those are both hard but for very different reasons i guess the different failure modes having 15 to 25 different teams do it individually means that like most of them will do it poorly but some teams will probably do it well and if you have them all in one big group that means that probably nobody will nobody will do it well probably all at once though okay i have an idea i'm gonna assume

that this is for they mentioned a larger group so i'm assuming this this means like the guild meeting becomes larger and more people participate and how do you keep it open and vulnerable you can't first of all like there's just a different vibe to a meeting with 10 times as many people however many times as many people will be in here there will be people who no matter what you do will not participate fully in a group this big so so you are making some trade-offs of like the there's there's just a ceiling you will not go above of how comfortable and vulnerable it can be but one thing you can do is is use people who are respected to model the behavior that you want so if you want this to be vulnerable if you want this to be about showing off half-baked ideas

and things people are struggling with you need to find people that are well known to be competent and capable and have them demonstrate the level of half-bakedness that you want brought to this meeting people who are well known for being competent and capable who are about to expose that they're imposters yeah like if you want to make it clear that i mean one thing you could be afraid of is if you say i'm struggling with this thing then someone will just scoff you and say why don't you google that you poor fool and i don't know just just get get feedback that equates to you are dumb so you take these people that you know are are smart and you show them being vulnerable and and that will engage the group i think to to participate in a healthy way

with with this vulnerability and also show this is like like if this person can show off their dumb thing they're stuck on then i should be able to as well it'll make it feel a little bit safer i think yeah a little safer they don't and they finish their presentation they don't get mocked or tomatoes yeah but they get praise maybe unless in the course of them presenting it they're they they just like figure it out so masterfully and you just see the gears turning and they're how they how they their brilliance shines through yeah exactly like i i started off not knowing how to do this in the end i wrote a compiler to produce a language that does this actually i live coded it during the during yeah exactly i built a gui in excel that is rendering in 3d

yeah probably that won't happen though i think that the fundamental problem here while while acknowledging the progress you've made with your small team which is great and i congratulate you for that i think vulnerability simply doesn't scale yeah like who's willing to be vulnerable in front of a hundred people i'm willing to be vulnerable in front of a hundred people if i know i can defeat them all in single combat is this how you get through conference talks it is yeah none of this imagining people in their underwear no imagine them at my feet boxing gloves on head yeah as i stand in a victory pose all of them with the ref holding one of your one of your uh glove clad hands in the air that's pretty violent

that was good of you to be vulnerable about what's actually going on fortunately there's only three people listening and they're all related to you yeah even my family doesn't listen to this well they want to know more about me my vulnerability then tell them like is there a way to i don't know is i really don't think true vulnerability will ever scale to the degree that you want it to with 15 to 25 scrum teams i mean we're talking if a team is two people this is 30 to 50 people if a team is three people we're talking 45 to 75 people that's a pretty big group for someone to come and quote be vulnerable maybe you have to reduce the size of

your teams oh well then it scales very well yeah that's true it's like big o of zero better than constant time i mean you're just not gonna i think you're gonna be challenged to find what you'll find is that the same 10 of people are willing to stand up in front of 30 to 75 people and say i made the following mistakes and here's you know here's everything on display if you want people to consistently and uniformly contribute i think you've either got to keep it a small group or pivot the format so that vulnerability is not a prerequisite to present you know feel free to have people share things that are good you know share things share accomplishments but not hey i'm gonna do a open art retrospective right in front of you on

all my mistakes i i don't see that scaling i think similarly to how if you're if your technical systems have to scale an order of magnitude they usually have to change i think that's probably true for meetings too if you're scaling the attendees in order of magnitude then yeah it's gonna have to be redesigned i think uh if you want another thing you could do that would involve more work is partnering with folks especially people who might be less comfortable sharing or less inclined to just like pop in and and start talking in front of this large group of people you are going a little bit more towards the formal presentation side it doesn't have to be totally you know conference talk style but some amount of of prep to help them feel comfortable with

the material that they are presenting people being willing to be vulnerable means that they're more comfortable you can also make people more comfortable by having them feel more prepared it's not quite the same as vulnerability but you might you might get some folks who might be more junior and more shy if you help them feel more prepared and comfortable they could still participate even if it's not the same off-the-cuff type of vibe you could also help people feel more comfortable by explaining to them that the consequences of feeling uncomfortable are severe. You may have noticed a new little icon in the corner of your Zoom window.

Sensing discomfort. A little color code that turned red as the algorithm detects discomfort and invulnerability. Lack of engagement. yeah i also think just going back to your comment about how when you scale things to a new order of magnitude you have to redesign the things the premise here is that you've got people who are comfortable to kick off a discussion rather than giving a presentation well in my experience it's hard to kick off a discussion with 30 to 75 people yeah you know like there are no discussions at that

level yeah there is only a one-to-many broadcast of information there is not a many-to-many or you're watching like a performance of like two people discuss in front of 70 people yes a panel and they oh hey maybe there's your answer is like a panel discussion like do that on purpose okay yeah yeah now again you're back to the vulnerability thing who's willing to be on the the panel and and i think the answer is it might be easier for people to kick off a panel discussion where there's some vulnerability involved knowing that the audience is not invited to chime in except for the the three people you're sitting in chairs with in front of the stage yeah or you train them to be able to defeat the audience in single combat

perfect that way you don't have to have everyone feel like they can defeat everyone else in single combat which is impossible obviously yeah but if you pick the panel then you can say okay these people are just yeah they have good things to say and also they are there they've got the most potential to be experts in martial arts and it's mathematically feasible again yeah especially if they group up then like stand back to back to back and i'm imagining the google form for signing up to be on the panel it's like how many weeks of martial arts training are you willing to take one week two weeks or 10 weeks yeah this will affect the likelihood of you being chosen it's a blind interview process but we do need to know how much martial arts training you're

it's blind because you need to put on a blindfold and kick the lid off of a off of a like a soda bottle right that's what we mean by blind audition yeah you're blindfolded precision strikes yeah it's a good these are good answers yeah they are these are really good answers i agree i'm glad we could be vulnerable together with each other to come to this place oh geez all right well did we answer the question yeah i think so what do you do to keep this going yeah just bring food that's the secret yeah also bring food willing to be vulnerable for pizza my vulnerability can be purchased yeah what can people do if they want their own questions answered okay if you want your own question answered go to softskills.audio and click the

ask a question button and as usual we want to say to each of you who have submitted your questions thank you so much for doing so you are the lifeblood of the show and we love reading them we do we've talked a lot about vulnerability it is a vulnerable thing to submit a question about this like tricky problem you're struggling with so thank you for doing that we appreciate it we learn from it. And we will catch you next week.