Soft Skills Engineering - Episode 73: A Rampant Rewriter and Overexplainers

Episode Date: August 31, 2017

Jamison and Dave will be at the UtahJS Conference on September 18th. See conf.utahjs.com for more info and to buy tickets. Come say hi! This week Jamison and Dave answer these questions: A developer on my team has been rewriting my code under the guise of “code cleanup” without saying anything to me. Is this normal? What should I do? How do you deal with co-workers who over-explain unimportant issues?

It takes more than great code to be a great engineer. This is episode 73 of the Soft Skills Engineering Podcast. I'm your host, Jameson Dance. I'm your host, Dave Smith. Hey, coming up on September 18th, Dave, or sorry, Dave, that's me, Jameson and I will be at the Utah JS Conference in Salt Lake City on Monday, September 18th. Come and join us. I will actually be emceeing the conference and Jameson will be heckling me from the audience

I bought some of those glasses with the googly eyes and I'm gonna try and make Dave laugh You may have noticed it's actually pretty easy to make me laugh. Yeah, it's not that hard I probably wouldn't need those I would just show up and I don't know stare at you and you'd laugh So go hit the website conf.utahjs.com and get some tickets and come join us. We'd love to see you Yeah, come say hi i didn't think of anything to say after this i was too caught up in saying the right words at the beginning soft skills engineering is a podcast where we answer non-technical questions about technical fields like software development it turns out there's

a lot of that yeah way honestly way more than i ever expected questions or or just soft non-technical things in general just questions like the things people ask i was like oh yeah that's a soft skill oh that is too and then you know 200 questions later i'm like oh my gosh they're everywhere i think we've said this before but when we started the show i really thought after three or four weeks we would run out of things to talk about like we would solve the problem well i just didn't i didn't have a sense for the size of the problem uh-huh but you did you were like no no trust me dave pat you kind of patted me on the shoulder easy for you you're right what problem this is the this is i am the living and naturally and everything works out

i am in the embodiment of the dunning-kruger effect when it comes to soft skills and with those credentials firmly implanted in the minds of our listeners let's get to our first question yeah i'll read it all right thank you okay i have titled this question rampant rewriter okay uh this comes from listener named abigail hey guys i am a new software engineer at a systems integration company that contracts engineers to customers for projects i am currently on a joint project that includes an experienced engineer from another company who acts as the architect for the web-based product we are developing recently i've noticed that he has been going back and rewriting almost every line of code that i commit under the guise of quote

code cleanup whenever i ask if there is a specific thing i can do to improve he shrugs off my question and i am beginning to feel like i am not contributing anything to the project i thought maybe this was happening because i am new to software but i found out that he does this to other team members from my company as well someone who is much more experienced than me should i be frustrated or is it common practice to rewrite someone else's code oh ouch is there a way to confront him about this while still respecting the authority as the architect yeah i'll often just go delete a certain member's code from a project and say i'm cleaning it up it's definitely cleaner this is a stinky code and i removed it and now it's clean

time to take out the trash yeah exactly uh i love i love code cleanup as an excuse for all kinds of just like oh yeah bad behavior tabs to spaces code clean up it's clean now yeah it's this fake word that sounds objective but really means like i like it better yep yep um abigail says that she's new to software and i could see this being like a weird experience when you don't have a lot of context yeah maybe you're like this is normal yeah oh oh someone just goes and removes your work all the time that's fine because that's how it works that's iterative right i write it someone else rewrites it quote cleans it up have you ever seen a situation like this uh i i have not seen a situation where you have two companies separate companies sharing a code

base and delivering for a shared customer that's that's in my opinion nuts i don't know i feel like that would happen with with multiple contractors or or contractors working at a company or something that doesn't seem that weird working for the same company yeah sure contractors working for the same company yeah like staff augmentation somebody hires some contractors to work with a team on a project okay okay so you you i'm gonna guess this is government a government contract uh because that's the only time i've seen the term systems integration company but so like maybe the government or the customer hired two different contractors to come work on some shared project but they're they're effectively peers but they don't

report to the same people they don't get their paychecks from the same company yeah right oh that sounds really hard why does it sound so hard well you don't have shared management structure so i mean the buck doesn't stop with anyone who do you turn to with issues like this i would normally say go to your manager and yeah that's that's like the dave smith advice talk to your manager about it right but in this case like what am i gonna do go to the other guy's manager yeah exactly and they'll be like you don't work here

yeah uh why doesn't my badge get me in the building here i need to talk to someone yeah i wasn't even talking about the broader structure of the project more just the specific incident of someone going through and writing all your code sorry i answered the wrong question no that was the right question that's a good question to answer but you're saying that that that affects your actions basically that affects what you can do to solve this problem i think so i think it limits your capability your ability to at least complain about the problem i mean who are you going to go talk to i don't think it's clear in this case the other developer from your

company who's experiencing the same thing i guess see that that's what you do you form a support group for all the people who have had their code like spuriously rewritten by this guy and you have a weekly meeting where you just vent out the frustration and share common experiences and you will bond it'll be great yeah yeah at least it's not only you yeah so i i've rewritten code before but it's never been i've never been like following a developer it feels like there's a little toddler running around with snacks and she just like leaves a mess and someone's falling with a vacuum i've never like tracked someone and been like this person cannot be trusted to do good work so i'm gonna fix everything they break i'll just as i'm working on a feature i will write code and

and rewrite code that touches the thing that i'm working on there is a lot of yourself tied up in your code i think and i i've definitely felt pangs of of uh what would it be ego i don't know yeah some something related to ego where when someone works in a code base that i wrote a large portion of and then it looks different when they're done like what what was wrong with the stuff i did wasn't that good enough so i think that's that's really common you'll hear a lot about code ownership and you can read a lot about it and there are different philosophies on whether it's good or bad to have one person own a code base or portion of a code base but everyone talks about how it feels weird when you feel like someone is changing the stuff you made have you

ever rewritten some code under the guys not okay not under the guys but to clean it up because in your eyes it was objectively bad and then later you looked it up and found out it was your code i think i've never done that without knowing it was my code okay eyes wide open yeah like oh yeah i wrote this bad thing well i've done that to myself i'm well aware of the bad stuff i've done where you didn't realize it was you yeah like i think i i have this foggy memory of doing that once um where i was just like god what who and then it was me and then i rewrote it you use the get congratulate command that's right get praise get praise yeah so i i think since there isn't that shared management structure dave talked about a lot of what you do

is uh is develop your own patience um it's it's definitely worth bringing up to this person but if if they're rewriting your code and you ask for feedback and they're like i don't know no it's fine and then they still do it um they're probably not the best mentor uh yeah yeah like one reason why someone would do this is because they think it could be done better a different way but if they're not willing to explain that way to you then i don't know that you can force someone into like giving you the truth tie them to a chair put a bright hot light in their face yeah exactly answer yeah that's that's unlikely to work well i guess the best mentoring comes under duress threat of hot bright lights which will dry out your eyeballs which you need to be

a developer yep actually you don't even know there are blind developers yep so i have an idea for kind of a nuclear option okay so you could go to the customer in this case because ultimately both of these two contracting companies will ultimately report to the same customer in the sense that they get their revenue from the customer and ask the customer if they're okay with having one of the vendors rewrite the code of the other vendor because they're probably being paid by the hour and see with see how they react to that and like i said this is kind of a nuclear option but it would certainly get a conversation started that feels like tattling to me i don't know why that just feels really weird yeah like the engineer should be able to work it out themselves

yeah yeah like you're trying to go to the parent except the parent isn't a parent who created you it's like this company that is paying money to get stuff done yeah you i don't know i i just can't see that working out well you might end up souring the relationship from both of you and yeah exactly maybe they're like well why are we paying this person who needs their code rewritten and then yeah bingo i feel like that would backfire yeah probably most nuclear options have pretty bad outcomes yeah i guess nuclear isn't a great word so you you ask specifically should i be frustrated or is it a common practice to rewrite someone else's code um i think it's fair to be frustrated i think it also happens a lot but i think especially when

you're newer to software um you need to be learning stuff and if there is legitimately something like real bad that your code is doing this person i mean you should know that maybe can you ask the other developer on your team for feedback on the code that is being rewritten because that might at least help you get a sense of whether it's um this is really really horrible for these reasons and these are things you need to learn or is it just like they like this specific pattern that you're not using that is less um less crucial to the quality of the code and more about making the architect feel good yeah is it a preference or is this really a bad practice yeah if the architect isn't going to give you that info maybe your

co-worker can and then that'll at least help you feel better about the situation one of the reasons that i could imagine this architect is shrugging off the questions that are being asked about the quality of the code is that maybe he feels like the answer is too big to give in uh the amount of time allotted so maybe you could go to this architect with a specific change and say can you tell me why this particular change needed to be rewritten what did you see that was making it bad um and uh maybe with a reduced scope of question you might get some specific answers dave you also brought up before we started recording if uh there's some kind of code review process in place yeah yeah i i detect that there is not yeah because if you just put code in

and then it silently changes to other code that means that no one probably the architect didn't look at it and say like this is good and then silent that would be even worse if they're like yeah it's fine and then they like passive aggressively go in and rewrite it afterwards ship it i'll rewrite it yeah um yeah that so i detect there is no code review process here and if there was then that would give this architect a vehicle for communicating feedback on the quality of the code before it gets committed and pushed so that to me might actually be the root the crux of this problem here is that you don't have a process for assessing quality of code before it gets committed sure and uh i i feel like that's a thing you could try and explore i mean it might

be hard to make work with all these different companies and people working together but you you can already commit the code somehow so hopefully you're doing it with a system that allows you to put some kind of review on top of it yeah you could just do what the get or sorry what the linux kernel does and like mail dips to each other yeah how they make that work is just beyond me but anyway that's because linus is immortal benevolent dictator anyway um i i think that he's like the least benevolent benevolent dictator that is so true he's like look i use the term benevolent in quotes okay guys benevolent means i don't kill people that disagree with me i just kill their feelings oh man so true so i think a code review process is essential in

this situation because here you have two different companies different reporting hierarchies different like kpis different cultures you need a review process to keep them on the same page technically i think it's essential i think that it will make huge improvements to your company's ability to deliver this product and if the architect is worried about maintaining the integrity of their designs or making sure things get done the way that they want them to you could sell that to them you could sell code review to them as a way to do that because if there isn't code review right now they're probably just like going in and checking up and that's kind of a waste of time yep um this way they don't have to check up they can be proactive about it and help guide the

direction of the project instead of react to what they see as the wrong direction i you know i have uh tendencies like this architect um i do have to check myself one of my weaknesses is that i see code and i want to change it and code review processes have helped me to a um deal with that in a in at the right time which is before code gets delivered and b because your comments tend to be shareable to the whole team it has made me really carefully consider what i spend time analyzing in a code review and i i do not spend time on trivialities like indentation levels and and stuff like that. We have computers to do that crap. Instead, I focus on architecture and overall design and interfaces. You know, the things that really make your software have,

in my opinion, better quality attributes. So I'm telling you, I would push hard for a code review process in this case. And I know we're assuming it doesn't exist. I think it's a pretty safe assumption here. But I would really push for it. I want to see a code review process that focuses on rhyme and meter and rhythm and the aesthetic beauty of the the characters that you choose an iambic pentameter pull request yeah exactly each function must be a haiku oh three lines oh man now i want to do that yeah that is not bad does the return oh you're saying it's actually good because it means it should be short i i think maybe you know it might it might be good

i want to okay here's what i want to do i want to write a transpiler that will take your code and transpile it into haiku functions it just inserts arbitrary line breaks yeah just like re it like renames your variables so they're the right number of syllables okay i love it this will be my great labor in computer science then you can make your money and retire off that then yeah i'll make that sweet sweet poetry money those poets have all the money yeah they do great well did we answer this question yeah i think so sounds like a tough situation it's it is tricky um it's both good and bad that you're experiencing this at the beginning of your career because uh it'll get better afterwards soon you'll be the one rewriting

the newbies code oh no i'm just saying it's it's yeah there's good things about experiencing tricky situations early on because they teach you a lot but also you have fewer tools to deal with them yeah that's true but it sounds like you're approaching it conscientiously which is good yeah it's great good job all right should i read the next one yes you shall okay this is from a listener named j the letter j um escaped from sesame street as opposed to the number j just want to clarify it's the letter j not the number j yeah um i mean if you turn it enough it could kind of look like a weird seven okay anyways how do you deal with co-workers who elaborate on unimportant issues often in conversations with other employees they will

spend a great deal of time reciting the basic established facts before they get to a point this can happen when i ask a yes no question or when they are speaking in meetings i don't want to be rude so if it's simply the way they communicate that's great however sometimes it feels like they believe i need every detail put out in front of me and it's getting old is this what mansplaining is thanks and love the show also bring back the guitar intros oh i forgot about those yeah i touched my guitar yesterday for the first time in a long time um and my daughter had like twisted all the pegs for fun so i just like strummed it and wanted to die was it it would have been amazing if it was perfectly in tune

yeah wow she open g how did she know how to tune it that way toddler prodigy she's a slide guitar fan weird no she did not tune it to open g she tuned it to like satan's chord all right jay hmm you've got a you've got a co-worker who over explains i like the contrast between the abundance of detail that they're experiencing and they're short to the point name yeah no extra detail there not even actual letters like yeah listen getting to the point the letter you care about my name is j i'm not gonna waste your time with any other context or details um hmm well i would say in support of this over explaining engineer that in the immortal words of treebeard if something is

worth saying it's worth taking a long time to say it are you suggesting that they're doing this deliberately as part of a life philosophy to tell people to slow down yeah listen you're also caught up in your smartphones and your insta chats just relax and listen to me read the slides for the next five minutes so that you can see the last slide in the beginning says what should we do in the beginning there were and gates this is a good place to start oh man let's start from the ground up there was a guy named sisyphus okay um i'm actually feeling a little adversarial on this um because i appreciate the craft

of explaining well and when someone sits down with me and lays out context and background even if i already know the context and they do a great job of laying out the facts i just sit there and i appreciate it like good art i don't know maybe you're maybe other people are different that's really interesting it's like when you see when you eat a good sandwich and you you could make a good sandwich already but you're like this is still a good sandwich yeah i appreciate it this the person who made the sandwich did a great job and i've had a grilled cheese sandwich before but this one was done well and i appreciate i feel like this would be more like you already you just ate a sandwich and they're taking a long time to craft you a sandwich and you're like

but i'm not hungry yeah that's probably a better analogy you're like i can appreciate that you put the bun on perfectly but i'm not gonna eat it you know how they do that art in coffee i don't drink coffee so i there's probably a word for it that i sound like an idiot for not knowing but i think i know what you're like latte art or whatever it's like that but with the the way that the butter and the crisping happens on the piece of bread in the grilled cheese they'll like draw the eiffel tower on your grilled cheese right right by spreading the butter correctly is that i want that to be a thing now i'll check after the show butter toast yeah artisanal art toast yeah that's gotta be a thing stupid millennials we're ruining everything um so you're saying that this this

doesn't bother you because you appreciate it even if you already know the thing usually i mean sometimes i get what if it's not a good explanation though you're saying you appreciate skill in explaining things what if what if there is no skill what if someone hands you a crappily made sandwich where the bread and toppings are all over the place yeah and you're still not you're still not hungry it's a deconstructed sandwich which millennials invented i don't even know what that is is that a thing yeah it's you take food and you pull it apart into its ingredients and then you serve those ingredients and do the consumers recombine the ingredients uh you can if you want you can just like eat them separately too oh okay okay it's very fancy

and kind of dumb okay um you you are a millennial right i am yeah okay i'm firmly in that camp just so you know no one has to call in to be mad jameson is a millennial so yeah what if it's not great well i mean of course then i'm gonna be pissed off okay because you're crapping on the art right i mean it's like yeah yeah you're destroying the art that dave loves the art of explaining huh so what should they do so so you're saying um you suspect that sometimes these explanations are good and this person is being impatient is that what you're saying it's a it's a possibility and let me tell you because i have sat in meetings where someone did not take the time to carefully explain the background and

context and they launch into the details and everyone in the room or not everyone i mean there's obviously some people who are already plugged in, but some people are going to be just totally lost and unable to contribute to the discussion. And by taking the time to reiterate all the facts, even if you're restating things that people already know, you're A, making sure that everyone is up to speed, and B, even for the people who aren't, who are already up to speed, you're framing the conversation in the right context for them. So, for example, I already know that you know our software has some certain characteristic that needs to be changed but when you reiterate all that before the meeting i can scope my thoughts to understand that we're talking

about that and not something else so maybe that i mean that can be really really helpful yeah i think this tendency could be more useful for for people that talk to lots of different groups like product managers or business people oh yeah yeah i don't know anyone that just inter i don't want say that word anyone that talks to a lot of different people they almost said interfaces whoa what's happening to me dave oh no your transition to the business side is complete no i want to go back anyways if so so they might just have this this reflex developed where they need to explain the context to people and so they they start conversations by doing that maybe now i want to zero in on one thing he said which i i totally agree with when i ask someone a yes

no question and they launch into like a multi-minute monologue that oh man that really bugs me yeah does it bug you dave well let me go back to the beginning and let me lay out all the facts i i think you gotta say yes or no and then or i don't know and then if you want to you can give your explanation that's just that's human kindness exactly like so that i can leave in the middle of your explanation if i want yeah yeah well gotta go have you ever just talked to someone that has a pet topic and they use any conversation as a way to segue it onto their pet topic yes um yeah that i feel like this could be abused in those hands well i see you asked a question about code reviews um and i'll take this opportunity to talk

about my favorite thing which is haskell and how haskell would eliminate the need for code reviews and to do that i will explain the concept of purity to you and then they just like pull a whiteboard out i just saw aladdin again recently and i remember there's this part where the genie just like pulls a whiteboard out of thin air and writes stuff on it and i imagine this is what um haskell enthusiasts have oh my goodness available to them i love how you went straight to functional programming like i love functional programming and i do it and i love it to make fun of it because it's goofy but you went straight to the i mean for over explaining you went straight to functional programming because the fact is you can't talk about anything in functional

programming without like a one hour monologue beforehand yeah that's so true oh man this this describes my experience in lots of irc channels asking questions but in that case it's more like i don't know the details i i can't understand them and they give me the same explanations i can't understand before they give me an answer i can't understand um super helpful this has been jameson's functional programming soapbox that he'll get off of now uh you also say that it happens in meetings and i think meetings make people stupid they they they perform in weird ways i mean that in the like performance yeah yeah the theatrical performative behavior yeah there are other people around so suddenly they they think they need to like act

in a certain way which sometimes involves looking smart by explaining stuff i don't know how you fix that culture without calling people out on bs in a nice way i don't know because i'm like the meeting context to me is the most valuable place to make sure that you explain everything thoroughly before diving into yeah yeah so i'm i'm gonna call i'm gonna say that in meetings it's okay for people to err on the side of over explaining i really do okay i think it'll save time in in aggregate instead of having people be like now what are we talking about again because no one wants to be that person right yeah no one will ever say that raise your hand and say i have no idea what you're talking about they'll just nod in agreement yeah yeah great idea yeah i agree

but but the yes no thing so here's what i do i i've gone to people with yes no questions and and i'll actually say to them this was a yes no question and that's actually a little rude so um it's better tell by the question mark at the end of the sentence so that's a little rude to just jump down and say yes no and i remember one time not not too long ago actually i asked a question the person started going on a bit of a monologue and after a couple of minutes i stopped them and said now i was just asking yes or no on this and they said yeah i'm getting to that you need to have this background for me to understand to be able to explain the answer and i was like oh okay like i thought maybe they had

misunderstood my question because they were taking a long time to get to yes or no um and i was wrong and it was embarrassing maybe they were just messing with you like how long can i talk without giving an answer before dave will go away there's like a pool people are betting yeah they got a stopwatch okay oh he interrupted once all right buddy he's still there he's still there yeah okay what are the odds he's gonna interrupt twice i did notice like three or four people with their heads popping over the neighboring cubicles maybe that was you saw some cash exchange yeah that explains so much i think i mean you might try and shortcut this by explaining what you already

know um and like before beforehand right before yeah yeah say i'm asking this question here's what i got yes give me the answer oh that is such a good idea jameson and if they still do it uh i mean you might you might have to bring this up to them directly and say like i feel like i understand this already and it might be did you already talk about this how you you actually don't understand it no yeah we haven't talked about that let's do it okay yeah that's that's what dave was talking about before the show too that sometimes you think you understand it and you actually don't yes in fact maybe there's a flaw in your very question you know like hey do you like to you know do you like to put the wings on your car in the front or the back you know

it's a simple question a simple yes or no question and you're like well now hold on i need to explain something to you cars don't have wings cars are for driving about your stupid history lessons just get to the yes or no give me that facts and i have had that happen where people come to me with yes no question and i can sense from the way they ask the question that they're missing some important context that needs to be clarified um and and in that in those cases i think it's polite to explain that uh you don't want to say your question is nonsense instead i which i have had someone say to me before which actually hurt my feelings but no instead they said those words he said literally your question

is nonsensical by the way it was a git question so and i still it still burns that was five it all fits it still burns anyway all fitting together i think when once you go to someone with a question like that uh it i love what you said jameson state the stuff you know first and maybe they'll correct you before you even get to the point of asking the question so you you like out context them i'm gonna monologue you context yeah before you can monologue me you give them shorter context first fight fire with fire yeah cool yeah or you just get let's see I mean ninja vanish isn't a valid solution to

I think poof give on two minutes carry smoke bombs if they're still going you disappear when you reappear they say and that's why my answer is yeah they reappear where you appear again they're like i wasn't done they also have smoke bombs oh man they're more powerful than i thought we did an episode a few weeks back on and asking good questions right uh yeah we've we've talked about it a few times i think asking good questions can really help to alleviate this like you're saying and then uh you know i would i would take stock of yourself and and maybe maybe these these things aren't as basic as as you think and maybe other people in the room

actually do benefit from the what you perceive as over explaining while we've been talking about this i've just been thinking how much work this all sounds right you have to you have to summarize all the stuff you know and you have to think about what this person knows and you have to navigate all the social context around are they in a meeting are they showing off for other people or what what meeting did they just come out of maybe they were in a meeting with people that didn't know and and it's just like a lot of work it really is communication it's it's a lot of work but i think that work goes away when you find people you get along with really well and communicate with well so i i think if you're scared by how much work this

sounds as i have been as we talk about all the stuff you could try i think over time you just develop uh instincts with other people and and it becomes a little more automatic hmm yeah where you find the right people that you communicate well with and then it's more automatic like i'm sure that person that answered your get question uh has people that talk he talks to about like like a robot and it's fine and they're not offended because they don't care that that their logic does not compute or whatever when someone says that to them because they have no feelings yeah exactly no yeah i feel like that's all i'm gonna say never mind no more words communication is heavy though and it's hard and it's loaded with overhead activities like this

you know exchanging it's like a gigantic tcp handshake where you have to exchange some state before you can actually begin transmitting any real information you know that's a good analogy except it's way heavier it's like it's like 80 overhead you know it's like not only are you handshaking tcp you're also dumping your entire database across the wire before you can say and now i want to do a query huh um so all you have to do is write a more efficient protocol that's right which includes i think the blockchain will solve oh yeah absolutely yeah okay just it's just a matter of proof of work and then it'll be fine have we answered the question absolutely jay we

definitely communicated about it we did we oh no the only question he was asking was is this what mansplaining is and we never answered a yes no uh dang yeah that was the only question mark in the whole question shoot we wow this we just got trolled that was all the detail you needed we're out of time hopefully about 15 minutes ago you ninja vanished and reappeared right now and the answer is i don't know yeah i don't know either uh it does sound tricky but i'm i believe in you jay that's the letter that my name starts with so we have a connection and i'm using that connection to feel that you're capable of solving this problem good job dave yes what should people do now that they're done

listening to this episode uh let your podcast app delete it and move on with your life that's what i would say okay don't let this thing take up too much storage on your phone because that's a pain just delete it and move on okay anything else they should do also after you've done that if you would like to ask your own question you can go hit our website softskills.audio where you can write a question with as much or little detail as you want and we will answer it on the show at some point in the mysterious future yep yeah thank you again for sending in questions we love reading them we love answering them we love not answering them and remembering we didn't answer them we've also gotten many very

complimentary and uh touching tweets we appreciate that also some people have gone to itunes or even in your little podcast app on iphone and i guess android has this and and submitted nice reviews we have a 5 star iTunes rating which I've never had 5 star anything in my life so that's great if you'd like to submit a 1 star rating that's fine too if you want to crush our streak

of superlatives we will accept your feedback that's right so go do that I guess that helps us in some way people say it does so it must all the NPR podcasts say that it helps listen to how happy Dave sounds

and tell me it doesn't help him yeah i i don't know what it does either it's cargo cult we're cargo cult podcasters basically that's true all right thanks very much catch you next week