Soft Skills Engineering - Episode 103: Team Dynamics and Bad Code

Episode Date: March 31, 2018

A listener named Dan talks about ThanksBot, an internal tool at Facebook to support gratitude. Dave and Jamison answer these questions: I became an engineer because I loved my programming assignments and CS degree. However, at work I’m struggling to contribute beyond competing the tasks assigned to me. How do I participate more in broader technical solutions, process, etc? I recently started a new job, and a lot of the existing code is really bad. How can I raise this concern, or make improvements to the code, without offending my teammates who wrote it? Thanks!

It takes more than detailed knowledge of BGP to be a great software engineer. This is episode 103 of the Soft Skills Engineering Podcast. I'm your host, Jameson Dance. I'm your host, Dave Smith. I guess we should say what BGP is. We don't have to explain it. Border Gateway Protocol. It's a thing.

I thought it was Big Grumpy Patreon. Let's see. What else could it be? um buttered gnu pre-processor that was an early iteration of the macro pre-processor butter to grep psychology okay i like yeah i like that one i think we could do a whole episode of this oh yeah i mean we got 40 minutes to burn let's do it all right buckle in buckle group podcast buckle great protection i feel like i want to say like buckle your seat belt in a way that says bgp but but i won't that's okay i'm watching i'm watching our real-time

metrics we just lost 300 users or listeners okay you know what double down those are the people that weren't committed we just thinned the herd yeah well speaking of herds i'd like to thank our three patrons who are contributing at the monthly level so they get a shout out every week we have ken howard sean clayton and dustin codes thanks patrons we love you thank you so much if you want to join their illustrious ranks you can go to www.patreon.com slash soft skills eng or there's a link on our website that'll take you there we we don't have a lot of leverage over you because you know like we like doing this so we might just do it anyways

but it certainly helps it helps make us feel appreciated and it helps pay for stuff around the podcast just so you know jameson is really bad at sales i totally am oh i i negotiated my money down in the thing i did a couple days ago it was great what oh it wasn't like a big deal but okay it wasn't for my job all right should we answer some questions well yeah but first we had a cool story that someone wrote in from facebook um not we don't have a facebook page this is actually from a facebook engineer oh yeah do you want to share this one i totally do this is from a listener named dan in episode 101 you covered giving gratitude to other developers for good things they've done

at facebook we have a tool called thanks bot it was built in a hackathon a few years ago and quickly became a core part of our culture we can write hashtag thanks with a message in post comments and chat messages on our internal facebook instance on pull requests tasks and pretty much any other internal tool the message goes to you and your manager and is aggregated into your performance review cycle this style of feedback can be transformative for satisfaction that's awesome that is so cool i really like having a codified way to recognize people at one of my early jobs we had just a little chat bot and you could just plus plus someone's name and it just became a way of recognizing people that helped you and it i mean there was a command

you could do to like list people's helpfulness so maybe that could create some leaderboard weird incentives to get on the leaderboard but but it was just habit there every time someone did a little thing to help you just say like this person plus plus and it was it was a little public shout out to them and made people feel good what happened next where did it go did it go to their manager nothing no no it was just it was just like a everybody kind of knew that that person helped you it was just kind of a points thing like a yeah just a point for points just well i like the facebook one because i think it scales really well to the whole organization and um it's actually integrated into your annual review process i like that yeah there was no annual review process at

this job yeah i like that a lot that's cool yeah super cool thanks dan thanks for writing that in And if anyone else has a comment you'd like to add, feel free to hit us up on softskills.audio and click ask a question and then just do a head fake and write a comment instead. It's like, all right. Speaking of questions, would you like to read our first one? Yeah, sure.

This one comes from an anonymous listener who says, I became a software engineer because I love my CS classes and the process of writing software solo for school assignments. I'm in my first job out of school working on a cross-functional product engineering team. I'm struggling to contribute anything other than finishing the tasks that are assigned to me.

Other engineers take initiative to prioritize work for our team, propose solutions regarding specs and organizational alignment, and volunteer to take care of blockers. I pay attention during stand-up, but when I try to participate in the conversation, my teammates' responses indicate that the questions or concerns I bring up are irrelevant and should not be discussed during stand-up. Someone suggested I volunteer for more things as a way to learn about the organization and team process, but it's not intuitive to me what the team needs that I can volunteer to help with.

My knee-jerk reaction is to find a job at another organization that values hard skills more. But I would like to first give my best effort to improve on this front. Any suggestions for how to be a more effective team player, not just someone who goes through JIRA tickets? Sounds like JIRA is the problem here. There's your problem. What if we just blame it all on the tool? What do you think, Dave? well i have some good news for you if all you ever do is work on jira tickets and don't

do anything else to help your team you'll probably get a chance to get another job anyway why is that well i i don't quite get what you mean pardon you suggesting jira is not an effective measurement of someone's output and productivity and value even though it is the ultimate measure of all human value I was being a little bit subtle in suggesting that team members who do nothing but work tickets off the ticket queue and nothing else, in my opinion, are missing out on a lot of the most important things that we do as engineers, which is basically think of new and exciting ways to do things or more effective ways to serve our customers and build software that

works better. And you really have to participate in the social dynamic of the team in a greater capacity than just fixing Jira tickets, I think. Yeah, I think that's the question askers desire. It sounds like they are interested in that. They're just not sure where to start. And it feels like they've maybe tried a little bit and it hasn't gone super well.

Yeah, and I want to read into a little bit of what this listener wrote. I might go somewhere else that values hard skills more. Did that stand out to you, Jameson? Yeah, it did. yeah me too in in my experience a developer's effectiveness is much more bounded by their soft skills than by their technical skills as long as their technical skills meet some minimum bar the minimum bar is probably different depending on what team and organization and product space

you're in but there's there's a minimum technical bar and then above that it helps you but it's it's way more effective in lots of places to invest in soft skills uh this is a sales pitch for our podcast i just realized hence you should listen to us you are good at sales after all yeah i don't think there's this magical verdant land of just hardcore hard skills don't have to worry about this messy people stuff especially if you work in large systems because the the world we live in those are so interconnected and you're building components that other people use and you're using other people's components and like you just can't build a lot of really successful commercial software by yourself these days and if you do build it by yourself congratulations you're now

like a full-time salesperson marketer support ceo accountant like folk just saying like well there's got to be a place where i can just put my head down and crank out technical work that doesn't feel like a great solution to this problem for me yeah me too so your heart's in the right place wanting to contribute in more ways than just closing out jira tickets it sounds like maybe this listener picked the wrong time to bring it up uh you mentioned during stand-up and uh got shut down pretty quick right like says here that uh my concerns are not relevant and should not be discussed during stand-up and that's probably true stand-up is usually a time for a quick short status reporting and focus rerouting and motivational and whatnot accountability time but

it's not really the time to discuss broader problems like hey i think we have an issue with our code review process or i think we have too many bugs and we need to find a way to do a better bug triage ingest process and so on like that's not the time for that discussion everyone's literally standing on their feet and it's supposed to make you uncomfortable so you don't stand there for too long yeah i wonder if some of it is other engineers sometimes talk about things like that in stand-up but they have more context so it's a quicker conversation so maybe they're just like remember this thing we talked about i'm i'm tweaking our process and everyone's like oh yeah um whereas if you don't if you're newer to the team and newer to the code base and organization

it you you might be instead saying what if we tried this totally new thing just because you don't you don't have all the context and that's a good fit for a different place than stand up like dave said yeah yeah i think i feel like i need to clarify what i said earlier about hard skills i i really think if if what you want to do is just sit in a room and code uh that's going to be hard to find especially on more interesting problems but you you like unlock the ability to do hard fun technical things by working with other people yes so it's more like it's more like a carrot than a stick if you want to work on the fun interesting stuff you need consensus and you need other people's support and just going off and doing it by yourself isn't isn't a great fit

i think for a lot of teams you also mentioned that someone suggested that you volunteer as a way to learn about the organization and team process but you're kind of unsure what to volunteer with specifically you could just ask for help in that right just say i'm not sure what the biggest pain points are do you have any suggestions and then guaranteed there's some stuff that people wish was different that they would love someone to help out when should they do that like what's the right time to to broach that question i mean you could just ask your manager i i guess yeah stand up might not be the best time is that what you're getting at yeah i'm thinking that i think asking your manager is a great idea

yeah you or you could just like send an email to the team ask people in chat i don't know i would ask your manager as a default yeah start there maybe even talk to some people one-on-one and just say hey what are some of the things that are frustrating or hard to work with or you know things like that yeah as as a newer person on the team you also have you lack a lot of the baggage so you don't have a lot of the context but you also have fresh just un un i don't know your eyes are undimmed by cynicism. So I think in some ways, newer people on teams are great fits for tackling these longer standing problems or things that are just kind of lingered and nagged for a while, but no one has ever just said, you know, this is causing us pain every time we should just

buckle down and fix it. So I imagine there are great things to work on. And if you don't know off the top of your head, you can ask people for help. Another suggestion is instead of just kind of thinking up a thing and then just going off and doing it i would try pretty hard to validate the problem with other people first that will both make sure that people know what you're doing it'll give them time to give input if you're not sure what to work on and and also you want to make sure that if you go off and work on this thing people will care that you did it instead of seeing it as a waste of time taking you away from the valuable jira ticket closing work that you're doing because you have to do that right that's like part of the job you have to get some

of the stuff done that we said we were going to get done yeah and i i think i kind of made fun of that a little bit too much right like you still have to do that that needs to be like 80 90 of your focus but uh yeah it shouldn't be the only thing you do sure and and ideally you would work broader improvements into that jira ticket process yeah you have to balance those things a little bit some of it too might just be paying your dues right you got to show you can just get normal things done yeah also these things take time to recognize and really internalize you know i mean i remember being new to a team and you're like wow everything's great no one has any problems our team has good processes and then like six months later you're like this whole place is

a dumpster fire yeah that's true some of it is you only see problems in in there are certain situations that trigger problems to crop up and that's not the day-to-day operation of the team sometimes it's just like oh yeah every time this other system's version bumps then we have this horrible thing we have to deal with that doesn't happen regularly it's just like every time it happens it sucks right like a couple times a year you have all this pain and if you haven't been here long enough to experience it then how would you ever know yeah exactly so true yeah so take your time and enjoy this honeymoon phase of your existence i'm only assuming you're new to the team but if you are just enjoy it don't worry the pain will come i think that pain's already there

they're experiencing pain because they want to help out in ways they don't feel they can yet a new kind of pain will come i i mean a person on a team who finds the most painful thing and fixes it and then finds the most pain the next most painful thing and fixes it they they buy a lot of goodwill and they create a lot of value so if that's what you're interested in you can definitely help out and be recognized for that just make sure you're identifying the right most painful things and the way you do that is by talking to people but not during stand-up yeah i guess sometimes too the most painful thing is very coincidentally aligned with that cool technical thing you want to do and you're like

the pain is we're not using kubernetes and it hurts my resume right or whatever you're i don't know you got to be careful to uh take a clear look at your motivations for those kinds of things this team has a distinct kubernetes deficiency you know it would be better than a mysql database the blockchain i was just wondering i was like three two blockchain cool well have we answered the question we have but first we need to mention that i mean lastly we need to mention that replacing jira which is obviously the source of this problem with a distributed blockchain ticket tracker is clearly a viable solution i think i think you're right yeah i was gonna say the problem with tickets is it's centrally managed ah yeah we need to

That's true. Take it to the people. Yeah, you got to distribute those. Those tickets. What if, okay, what if you could somehow use the blockchain for assigning tickets? Okay. You mine by moving. See, I don't know anything about the blockchain, and I think I'm realizing that when I talk.

Anyways, question answered. Question answered. Good luck. The blockchain certifies. you want to read our next one i totally do this is from another anonymous listener i recently started a new job and a lot of the existing code is really bad how can i raise this concern or make improvements to the code without offending my teammates who wrote it i am shocked to hear that there's bad code at your job you must have landed at that

one company that has bad code yeah i read a lot of blog posts and all i hear about is all the good code that people write they never go back and update those blog posts five years later and say actually the opposite of all this that's true maybe the blockchain could help with that anyways uh we're poking fun at you but i think part of the fun is under that is is the truth that bad code is like a bad code is everywhere man i mean there's there's definitely code that's worse than other code and i can think back and think of the worst code like the job i had where the code was the worst but i've never worked anywhere where there hasn't been bad code the only time i've seen good code is the code i wrote about 30 seconds ago

and then after those 30 seconds elapse and i push it to get it's bad and it stays bad for the rest of its life yeah i feel like bad code often comes from just the way we build software not necessarily people being dumb and wrong all the time and and have you ever heard the phrase if you meet a jerk in the morning they might just be a jerk and if everyone you meet during the whole day is a jerk you might be a jerk yeah i feel like that applies to bad code sometimes where if every piece of code you ever look at is bad code it's not like you write bad you're the bad like your expectations of what bad code are don't really match the reality of how people program yeah maybe and and by that i mean have you ever had a deadline then you've written

bad code probably right like there are just there are things about the way we work that make people write bad code um changing changing requirements are often a source of bad code you wrote it and it was good and then you had to add one new thing and then that happens five times and then you had to totally change some core assumptions of it and you didn't have any time and you just kind of crammed it in there like code just it just devolves so there are lots of reasons for bad code and the point of all this is i think if you recognize that it makes it an easier problem to tackle so instead of going to your teammate and say this code you wrote is just horrible and so therefore you must write really bad code and be a bad programmer you can recognize like this was

written 10 years ago by someone in their first programming job or by people under intense deadline pressure or by just uh people that were multitasking too hard or i don't know just recognize it's we're human and we make mistakes and people write bad code and are still capable of writing good code yes so you have empathy for them i think that's that's the first step yeah i mean people will be offended if you think they suck right there's no way to tell someone you suck at writing code without offending them i think your code is bad and you are bad yeah but if you're saying like we just need to make this better and i understand why it's the way it is but we can make it better i don't think that offends people as much for sure i think you

can minimize the the offense by about 10 okay just kidding um you know i really don't like the phrase the word bad i feel like it's a i feel like it's a lazy word you know it doesn't really describe what's actually wrong with the code like bad could mean so many things bad could mean that the variables are named poorly that they don't make they don't match what they actually are used for it could mean that there's lots of coupling in the system that has negative effects when you try to change seemingly unrelated parts of the system and cause breakage it could mean so much stuff and so i think if you're going to go to your team with a recommendation for changing their code saying bad is like the worst way sorry worst is also a bad word in my opinion oh i just said

how dare you it is it is not a very effective way for getting change to happen on your code base but if you really want to point out how something is bad quantify it tell them why it's bad and exactly how it's bad and um and then it still probably won't help yeah i really like that though there's an underlying thing besides just bad and i think you're right that bad is kind of a lazy word it if you say it's bad because we have 25 dependencies in this module or whatever and and that is bad because it means that it's probably doing too much work and it depends it it well see now i'm even struggling why is that bad i know it's bad but why 25 dependencies are bad because every time we want to release it we have to bump all these revisions and those things

sometimes introduce changes and bugs and we have to do a lot of testing um you know it's doing at least 25 different things because it's using all those and yeah yeah so if you can yeah i like that if you can if you can specify it i also think sometimes bad code gets used to mean code i didn't write right we have these strong personal preferences around style and choice and some people really really really like more procedural programming some people go nuts into functional programming some people think object oriented is the right way and even within all these broad definitions there everyone points at someone who does it a slightly different way and says they're wrong and bad so some of it is is like the developer who cried bad code right it's like

that's not it just it's just different it's not it's not necessarily bad just because someone else besides you wrote it in the way they thought was good yes for sure and i think for me like you said bad code means someone else wrote it for me bad code means someone else or i myself wrote it more than a few seconds ago yeah i don't know why like i come back to my own code sometimes i'm like this was such a bad idea yeah i think recognizing that process in yourself really helps you avoid thinking people are bad for writing bad code because if you do it all the time right and hopefully you're learning so every six months you look back on your code and you're like man that was so much worse than the way i do it now why not why not give other people the

ability to learn in that same way so you talk you also ask about how specifically do you raise this concern or make improvements i think if you can attack the underlying problem that helps right were there really intense time pressures on people that caused them to have to just crank it out um was it a lack of knowledge type of thing where people just didn't know any better so they did what they knew and then could that be addressed by training yeah for sure sometimes there's like really obvious things where you're like oh did you know you've been writing like four lines of code every time you want to do this one thing but there's a helper function you can call that does that for you you know or there's a idiomatic way to do that that saves you a bunch of typing

those are i think those are the easy cases the harder ones that's not bad code right like not knowing about some flag you can pass to a function that's not that's that's that's the small details that doesn't i don't know that's not what makes a code base bad right exactly at worst i would call that annoying to read because you have to read like a bunch of lines and you go oh this is just doing zip which is a python thing but you know stuff like that what was i going to say about that i think i was going to say those are easy because um all you have to do is approach the person and say look you can save time doing it this way and it's actually pretty simple to fix too to go back and fix the harder ones to fix are the things like jameson was talking about

like you have so many dependencies right it's like oh crap i'm gonna have to dig through all these dependencies and they've just grown and grown over the years or everyone has every project has like that one file that's like 10 000 lines long and no one wants to touch it and it just slowly grows and people only add to it somehow people always touch it yeah and uh i mean it is so hard to fix that my last company we actually set up a like a little metric that we would report on every two weeks at our sprint kickoff meetings where we'd say hey here are the people who removed lines of code from this humongous file um congrats to them you know so and so removed 50 lines someone else over here removed 75 you know and then we would clap um but it still it still didn't help

we still had this 10 000 line file so anyway bad code it's everywhere um i think the worst way to do it is just roll up your sleeves and say boy this code is bad and go like submit a giant pull request because for better for us people do identify often with the code that they've written and if you make a pull request titled clean up our crappy code and just submit that i mean people will be offended so if you really want to make systematic change you need to talk to the team about it and agree on things that we will do differently now and then when you do those changes you're just doing what you agreed on so like uh we talked about the giant list of dependencies earlier right you can say we want to keep our dependency list small and then when you

go clean that up you can say this is doing what we agreed and here's how it makes the code base better and hopefully you don't take that too far and then just do other horrible things to follow these arbitrary rules of good code that you set for yourselves but i think if you if you get dave talked about getting what was it quantitizing is that the word uh quantifying quantifying yeah quantitizing i think is a different thing quantifying the harm it causes so you get the team to agree this is causing us problems and then you agree on a solution and then you just do it and then people aren't offended they're just in my experience people are generally excited to clean things up because they're they're usually aware of it and don't love it right it's not like anyone

loves this horrible mess that they've made am i totally contradicting myself uh i don't think so yeah like it i think it depends like it depends on how entrenched the person is in that style that you're attacking yeah i guess that's true and that's where it gets into the fuzzy definition of bad code but if people have written very deadline driven code right like most people are aware of that and are like yeah we got to clean that up someday so if the team agrees on it and starts to clean it up people are happy about that it gets trickier when you're like this thing that you think is good that's actually bad and then that's where you need a little more careful consensus building yes also i think a good way uh an effective way sorry there's that word

good an effective way it's a good word it is literally a good word i think an effective technique for making claims about someone else's code that are like actionable and won't cause as much offense is rather than saying like this code is difficult you can say i found it difficult when i was trying to do x with this code and instead of just saying this code is objectively universally difficult to work with you can say i had this problem when i was trying to accomplish this particular thing with this code and like that's something that can't be argued right it's it's a fact it's not an opinion it's a struggle you had and then you can as a team you can work on that together whereas if you just swoop in and say this code makes it difficult to do x y and z

it's very difficult you could argue about that right because people could say well i don't think it would actually be difficult you know but if you actually tried something and had an experience and you can use that i think that would be much more helpful yeah yeah you know this sounds like a lot of work it's a lot easier to just say this code is garbage and then go rewrite it all i am the bad code midas i touch it and it turns to gold it turns to bad yeah no the other way around oh okay i'm the opposite bad code and i make it good just by looking at it every code base i touch turns into a dumpster fire i think that was a different greek myth

uh have we answered the question uh more or less no worse than we ever have recently started a new job yeah this is a good time to do it i think new people bring new blood is important new eyes on a code base is important and we talked about it last question right you can find stuff that people might be used to and and help them fix it so you've got a great opportunity absolutely you are the canary in the coal mine that has died you're a dead canary so you like flew in drop dead is that what you're saying yep and the final the final words out of his mouth with his final breaths were this code is really bad on that note we're sorry for your what can people what's that we're sorry for your loss

wait what do you say to the person that actually died oh this got morbid i'm sorry you died i'm sorry for your death yeah i don't know i haven't encountered that situation yet sorry i'm uncomfortable now i'm sorry you know what would make me super comfortable is if we told people how they can get their own questions answered i would like to share that with you go to softskills.audio and click on ask a question you can remain anonymous there or you can fill in all your contact information please don't enter your social security numbers I mean yeah we'll take them

we'll keep them safer than some people we'll put them on a blockchain somewhere yeah we'll put them on the blockchain alright thanks everyone thank you we'll catch you next week