Soft Skills Engineering - Episode 180: Inspiring attention to detail and moving

Episode Date: October 21, 2019

In this episode, Dave and Jamison answer these questions: How do I inspire attention to detail in my co-workers? I’ve been frustrated with another developer on my team who pays a lot less attention to detail and it results in many bugs that I end up fixing, and sloppy commit history which makes debugging issues more difficult. I received a suggestion from a mentor to reframe my thinking from: I failed to enforce good practices, to, I failed to inspire good practices. Having approached the zen master, I’m hopeful for your additional advice / humour, what are some actions that I can take to help me on this path of inspiring vs enforcing? I am planning to move to a new city for my significant other to get another job, and will likely need to leave my current job to do so. Should I tell my manager up front when we start looking for new jobs or wait until we are actually moving?

it takes more than changing stuff and seeing what happens to be a great engineer this is soft skills engineering episode 180 i'm your host dave smith i'm your host jameson dance soft skills engineering is a weekly advice show for software developers where you write in with questions and we give answers you know at the very beginning the tagline was it takes more than great code to be a great engineer and for years it's just been like demeaning stupid stuff that we actually do at our job when did that happen we're like the frogs that slowly boiled ourselves we're boiling now yeah but yeah i do change stuff and see what happens a lot yeah it's a lot slower to change stuff in management and see what happens the feedback cycles can get pretty

long i want to give a shout out to our wonderful patrons thank you so much to the folks who are supporting us at the level where we shout them out every week thank you to matthew voidovich the agile ventures charity bartek tetkowski ted nugent crash bandicoot zach rannan maple syrup louis santos piska jobka i don't know if that's real or not nick cantar bin lock taras haruk sean sunny tie britney ellick sonic the hedgehog ivo robotnik florian tatzel marie rousseau chris hogan dimitri yanson stanley tactical radio and thank you to new donor sergey smirnov if you want to join this wonderful crew then you can click on support us on patreon from our website soft skills.audio and you will get an invite to our slack channel which will teach you nice things

about how to be a better soft skiller yes not from us the other listeners are very smart that's right we crowdsourced it yeah it's great i i check it pretty regularly and i like the conversations we have there. Me too. Do you want to read our first question? Sure. This one comes from Fred Flintstone. Probably not their real name. We'll go with it though. He has a lot to learn though, if it's the real one. We can help you. True. I was trying to think of the name of Fred Flintstone's boss that he's always getting in trouble with. Yeah, I don't know. I haven't watched that show in decades. All right. That one's going to go unanswered. All right. Okay. That's information we could never learn the answer to all right the question is how do i inspire attention to detail

in my co-workers i've been frustrated with another developer on my team who pays a lot less attention to detail and it results in many bugs that i end up fixing and sloppy commit history which makes debugging issues more difficult i received a suggestion from a mentor to reframe my thinking from i failed to enforce good practices to i failed to inspire good practices having approached the zen master that's you dave okay that's funny maybe zen with an x you know virtualization having approached the zen master i'm hopeful for your additional advice slash humor what are some actions that i can take to help me on this path of inspiring versus enforcing hmm i'm just looking at the list of symptoms sloppy commit history i am the sloppiest committer

i i just like head on the keyboard mash comments to put in yeah i know some people are very into every commit should be a logical grouping of functionality that leaves the program in a working state yes and i just cackle as i break my commits down by character one letter at a time it's like needle in the haystack to find the commit that compiles you're like i use git bisect every day sometimes i leave little like choose your own adventure puzzles for me for myself in the git history branches that loop back and refer back to themselves wait a minute you figured out how to make the directed acyclic graph of git

be cyclic no but that would be cool you could build a like a text adventure in it i mean i'm sure you could build a text adventure in it already just no cycles which is actually great yeah it would be a friendlier text adventure right okay that'd be cool actually now pivot time anyways i would be a sloppy person on this team i usually do rebase my stuff locally before i push it up and leave a giant mess though but i i guess the point behind that ramble is that shared practices usually come from shared values and it's possible that the other person on this team is like commit history like i've never used git bisect ever in my life and maybe we should say what that is just to give context i guess it's a tool that you hope you

don't have to use yeah yeah usually yeah yeah it's it's a tool for doing a binary search through git commits usually you start at a known good commit and a known bad commit and are trying to find the commit that moved you from good to bad. And so it'll kind of check out commits and search through them to help you identify where it went wrong. I'm just imagining someone bisecting on your commit history and they're like, aha, it was the letter H. It was the 14th semicolon. I knew it. So I will continue to rabbit hole on this issue. I feel like clean git history, where I've seen it, has felt like just as much of a philosophical argument as a technical one. And philosophical arguments are hard to make convincing cases for in practice, usually

in software. It's easy to have disagreeing philosophies, but it's harder to have disagreeing data about what actually works. So I feel like the more kind of esoteric and prone to opinion a subject is, the harder it is to get consensus on it. But I mean, just breaking stuff, that's bad. Bugs, nobody likes bugs. Right.

And I think what's going on here, if I read that symptom properly, it says that the co-worker writes a lot of bugs that i end up fixing yeah and i wonder if the sloppy commit history actually results from that it's like oh you know bob you changed this line it's like well actually i was just fixing a bug that so and so you know created this feature it wasn't me you know that's a good point if you're trying to dig through what someone else did a clean commit history would make that easier yeah like in a perfect world you would look at a line of code you would load up a single commit and it would tell you everything you need to know about why that code exists but in reality you end up having to go down this rabbit hole of twists and turns and where did this come into

being oh and oh someone refactored the whole world and that's why you know or actually more like re-indented yeah that makes sense someone like jameson introduced a linter and changed 5 000 lines yep i just gotta bump those numbers up yep pad the stats so i failed to enforce good practices too i failed to inspire good practices yeah so how do you inspire someone to do everything the way you want them to do it sorry i'll try that with my three-year-old child yes honey i've taken away your dragon to inspire you yes to new heights of not hitting your mother i just have this preference that you don't hit people you know we just have a shared culture of finishing our grilled cheese when we put it

on our plates for dinner shared practices come from shared values they do and the value is no cheese left behind so yeah so like let's let's say i mean let's say that it's not so much about personal preferences and let's say it's not so much about like you know do you squash your commits or not because i i think those are you know those are preferences and i think the whole world tends to get really wrapped up around these things that don't actually matter but when you have a teammate who is literally creating bugs that slows down the rest of the team because they didn't pay attention to certain details that really matter to your domain which ultimately manifest as issues that a customer or user won't you know will block them from using your software you know how

do you inspire that attention to detail it's really tough on a team when you're i mean one approach you could take is to try and come up with some shared agreement with the rest of the team and it's like very clearly in your mind targeted at this one person like hey everybody we all agree to have clean get commit histories right right and you all look around and nod at each other and then just nothing changes like yeah i guess it's hard to hold people accountable especially as as peers yeah i think you have to raise the the output or the effect it's having on output which is that you're creating a bunch more bugs and if you could trace it back to that that's a stronger case of like we need we need to make sure we have unit test coverage or commit in this in

this i don't know follow this git commit flow or because it will help us reduce bug count but that's still hard to say as a peer to another person that hey you are you're introducing a lot of bugs when you do this is it i don't know it feels like that feels like the core of the problem it's not like they're not there's this good book that i like called performance appraisal and it's about how you give feedback about performance and it gets into the distinction between talking about people's characteristics and their behavior and you could start talking about how they don't pay attention to detail and that's pretty vague and you're kind of hypothesizing about them as a person and changing people is really hard but the more you keep it focused on specific outcomes the

more direct and actionable the feedback is so if instead maybe they are sloppy and don't pay attention to detail but that will not give them a thing to change if you just say hey you have a poor eye for detail so i do think you have to focus on the specific behavior that needs to change which is you just need to have fewer bugs in your code do you just love bugs you need to write fewer bugs instead of more bugs that's when you hand them a copy of jameson and dave's international bestseller no bugs driven development exactly and we will consult with them for a reasonable fee totally reasonable we'll find every bug and say oh shouldn't have done that that thing you did you shouldn't have done that thing that is not part of this process yeah yeah

it's it's hard i'm so okay so you're saying focus on the on the outcome you want and don't focus so much on making judgments about their character per se yeah dave we should replace me with you because you say the stuff i'm trying to say no but better that's what i'm saying that is not true that is not true yeah focus on the outcome not their character and and it will it's easy to get defensive if someone attacks you if they say hey you're really sloppy no no i'm not yeah exactly like have you have you seen the part in my hair it is very neat watch how cleanly my fist will impact against your face as i defend myself how's that for sloppy you're drooling on the floor can deliver a neat open-handed slap i will say this one of the big challenges about software

development is that there are so many details and you know like 90 of them don't matter you know what i mean there's just so many different ways you could do things that just don't matter and so maybe the problem here is that your co-workers having a hard time zeroing in on the details that are actually important they're just being onslaughted by all the others what do you do about that, though? I'm just here to point out problems, Jameson. I don't know how to solve them. I mean, it feels like one of the ways this could go wrong is if it devolves into you nagging this person and saying, hey, you missed this thing. You missed this thing. Hey, you missed that thing. And ideally, you want them to do it themselves somehow. Yeah, because, you know,

we have a situation here where a detail eluded some person and and I'm resisting the urge to say, well, they're just not a detail oriented person. So let's just say a detail eluded them for somehow what is a scalable mechanism by which you can ensure that other people are not eluded by the same details if it's a bug and there's a some assumption which by the way most bugs i would say are caused by invalid assumptions made by developers not weird language features unless you're in c++ not you know other quirky things about tooling it's usually about assumptions like i assume that this user object is always going to have a id field you know like things like that and then it's like well turns out there's this one important business case where it doesn't and you

your code has to handle it and any code that interacts with the user object has to handle it how can you build like scalable mechanisms so that we detect those those kinds of misses earlier on and i think that is a totally different focus from i need to fix this person and make them more detail oriented i'm actually pretty sloppy i make a lot of mistakes and i tend to gravitate towards systems that help protect me from myself so oftentimes that will include statically typed languages the fancier the type system the more i feel like i can surround myself in a cocoon of type checking the more you surround yourself instead in like sophisticated type systems the more you feel like you can just be yourself you know if i just wrap one more monad around me

then the world can't get inside i don't have to show who i truly am i wish i was just yoloing all this in javascript so yeah so those are mechanisms right i mean type systems yeah i mean the the problem is those are all mechanisms that carry some amount of overhead and they're not pure productivity they all have cases where they'll be false positives or you'll spend a bunch of time wrestling with them to get them working or there's higher upkeep just in in general if you're moving fast in a chunk of the code base like they'll have trade-offs and i would feel weird if the whole structure of this engineering team changed just because

this one person couldn't like run their code before they committed it or something like that you know well they're sloppy and then there's just totally irresponsible yeah maybe there's a spectrum though maybe you need to have better standards around around test coverage or something but now i'm going to play the contrarian again and say why did they not run their code and i've worked on systems where it's actually really hard to execute your software in such a way that you can reach a point in the code where you're making a change and so maybe that needs to be addressed Every time you try to take it back to the people and judging the people, I'm going to bring it right back out to the infrastructure.

All we need is another startup. We'll just reach for another SaaS tool. At what point does it become the manager's responsibility to step in? So it sounds like this is a peer, concerns about their peer. When do you bring it up to the manager to say, hey, I have these concerns about how this is affecting my work? Yeah, that is a very important question, and I'm sure it has a very good answer. I've heard two schools of thought.

One is that you have to bring it up to the person first so that you're not tattling on them. Okay. And the other one is you don't have to do that, that you can just... So that you are tattling on them? Yeah, exactly. It's the tattle versus no tattle school of thought. Right. Famous debate in philosophy.

Right. Okay. I mean, this is something your manager should be aware of. if it's affecting productivity right but you also i don't know do you want to just get them in trouble yeah i mean in an ideal situation which every time i say that i just laugh because it's like wait there are none of those but you know i've been in situations where there was a developer who just for the life of him could not produce a piece of code without pretty significant bugs and after just months of sending back the code or finding the bugs and and fixing them later or

whatever you know finally we i don't know why the manager wasn't aware and maybe that's a deficiency on this team but we went to the manager and said look this developer just needs to not be writing code in our code base anymore we are spending so much of our time covering for these mistakes and i remember one of the other engineers was so frustrated by it that he actually went to our manager and said can you just pay him to not write code anymore oh boy and i was like whoa whoa now to be fair this was a contract situation so it was kind of like this is why we have contracts right so that we have more flexibility and the people we can move in and out but the manager really reacted strongly to that and moved quickly to change the situation but i realized that

the manager should have had their eyes on this situation more like it's your manager's job to know if one team member is causing productivity friction for others yeah it is their job it feels like a cop-out though because it feels like you're just handing the baton to the manager and then washing your hands well washing your hands but also saying like hey maybe you need to get fired for this good luck like yeah and what i was actually thinking when i said in an ideal world your manager would actually be prepared to coach people in this situation yeah but we haven't i mean how do you coach them in this situation we haven't given any answers i guess it is easier as the manager to say hey you need to get better where that's that's kind of hard to do as a peer

yeah it's like what what makes you so sure why do you think i should be better yeah who are you lowly peer all my peers are beneath me that's right so did we really just come around to talk to your manager is that the answer no no okay so there's actually something that's been bumping around in my head that i've done in the past that i should probably mention which is how did i become a detail-oriented engineer how did i figure out how to filter out the unimportant details and focus on those that really matter and the answer is actually just a lot of years of messing it up and learning through trial and error which things matter and which things don't and i think that one good way to inspire someone to pay attention to details is to let them bear the cost of the times

when they fail to pay attention to important details, which means don't fix their code for them. They have to fix it. And if they've already moved on to another task, then that task has to suffer as a result. Let there be no externalities where people are covering for this developer who's producing problems.

Instead, let them bear the full weight and then they'll pretty quickly figure out what things matter or what details they need to pay attention to. That'd be so hard for me. Every time I see something broken, I have to just grab onto my chair to restrain myself from dropping everything I'm doing

and trying to fix it right then. Yeah, me too. And it's probably burned you a few times, hasn't it? Yeah, often I'm wrong too. It's not broken, but now it is. Now that you got your fingers in it. Wait a minute. There's too many databases here.

I should drop one. Yeah. There we go. I'm going home. Look at all this extra data sitting around that nobody needs. That's really interesting. Have you done that successfully?

Yeah, I think managers are better positioned to do that because they're already in a situation where they're not supposed to be jumping in and doing the work for their team. They're supposed to be delegating and assigning tasks, prioritizing and whatnot. And so it makes perfect sense when an issue comes in to route it right back to the person who owns it.

But to do that accurately, you have to be a pretty in-touch manager to know who built this, who caused it. Or you need really good Git commit history. And we've come full circle. I was just thinking, now we know why your commits are the way they are, Jameson. Yep. It's not about performance art.

It's about hiding your tracks. So anyway, I think that, and when I look back over my past and I realize, oh, all the mistakes that I've made have made me a better engineer because I can pay attention to the junk I did and fix it and not do it again in the future. But I can only do that if I know that I did it wrong in the first place. Yeah. So it feels like the worst way, one of the worst ways this could go is nobody says anything until it gets bad enough that something explodes and then this person gets fired.

Yeah. I feel like earlier feedback is generally better, even though it's hard to give. It's probably not going to get easier to give. Oh, it never does, right? And I've certainly been around places where it was impolite to say, hey, you did a bad job, but it turned into more impoliteness, which is, hey, you don't have a job anymore. Yeah. From you did a bad job to you don't have a job.

Yeah, enough avoiding conflict turns into more conflict eventually. Right, right. And magnitude grows. Yep. Well, I think Dave gave you good advice, and you should do what Dave said. I think you should do what Jameson said and cover your tracks. Oh, all right. Well, we've answered the question then, clearly.

Yep. You want to read our next one? Yes. This is from an anonymous listener. I am planning to move to a new city from my significant other to get another job and will likely need to leave my current job to do so. should i tell my manager up front when we start looking for new jobs or wait until we are actually moving good question i sense a false dichotomy here okay where you've only you've only listed two options but there's a third option what is it tell your manager after you've already moved

is that the millennial resignation just stop showing up you ghost your employer developers are so cushioned a lot of the times i wonder how long you could get away with just not showing up huh well off to try there's only one way to find out yeah i just imagine you calling your boss after you moved to the new city and got your new job and you're like hey uh i moved so i'm gonna be to the office never hmm i have not done this neither have i you mean moved and then told your boss later yeah i haven't done that you know you work remotely so you could just uproot and move wherever whenever and not even have to tell your boss yeah that's true it would be weird if i did tell him yeah you'd be

like i don't care where you i didn't actually know where you were i don't want that i don't want to know as long i mean as long as you stay in the same time zone it's very little impact yeah yeah it's not too bad so you can move north and south all you want that's why i'll be heading straight up to the arctic circle that's right should i tell my manager up front so the downsides of telling your manager up front are if they know that you're going to leave soon you're an easy scapegoat if there are layoffs coming or if there are interesting projects you you might not get on those like like i don't know i'm trying to think of the the bad things that happen if you just tell them up front hey we're going to be leaving in a few months well yeah you're certainly not going

to get any high profile high responsibility projects yeah but i mean if you're leaving in a few months who cares that's fine that would be bad for everyone yeah it would be but the layoff thing is a little tricky so like if layoffs happen you're probably the first to go but you're going anyway and wouldn't it be nice to go with a severance package exactly yeah then you get it just not work for a while instead of work until you move i'm trying to think of the ways in which you you you know for sure you're gonna move and this goes really really wrong and all of them seem like you'd have to work at a pretty toxic place for that to happen yeah i don't know i think you should just tell them do you really okay that's interesting so i went through a situation

kind of like this but i did not want to leave my job so i wanted to try to make it possible to arrange for a remote working arrangement were you moving no matter what though well not exactly so i was kind of feeling out my options at this point and moving was one of the options on the table but it was going to depend on several factors, not the least of which was how would my company react when I said, I want to move and continue working for you. And so I gave them about four months of heads up time and said, I'm considering moving for family and personal reasons. Could we make a remote work arrangement work? And they took a few weeks on that and came back and said, yes. So that actually worked out great for me. Now, if they had said no, now I'm in a bit of a pickle

because I basically told them I want to move. And so if I wanted to hold onto my job as long as possible until i actually did move now they would be skeptical you know yeah it would feel awkward but i'm not sure there would actually be any super negative consequences i think if you're for sure gonna move though i don't know as long as things are pretty okay i don't think it would be that bad yeah the other thing you have to do is is consider the other side which is you wait to tell your manager until the traditional two weeks notice time and then you tell your manager hey i'm moving my significant other got into some school or some other job somewhere and now your manager is like wow you've been having these huge life changes and you didn't tell me for the last

three or four months, that's a little awkward too. It would have been nice to know to plan around this. Yeah. You certainly don't owe it to them to be clear. I think it's not this imperative that you tell them, but I feel like telling them is going to preserve the relationship better and allow you to transition better. If you don't know for sure that you're going to move, I could see it being a little bit fuzzier. And especially, I mean, maybe you don't know when you're going to get this new job either. Maybe that's a little bit tricky too, but at least giving them the heads up. I would also appreciate it as a manager to know, I mean, maybe I could make it work to have them work remotely if we're not a remote team. Maybe it would give me a chance to try and keep them

around in a way that works for both of us. And if you have a really trusting, positive relationship with your current work, they might even be able to flex with you while you go out and do house hunting trips or interview at other companies in the other city, because that takes a lot of time. Yeah. The thing about the reason for leaving is it's so non-threatening to the company or the boss oftentimes people leaving feels like you're rejecting this company or this boss or whatever people sometimes take that poorly but this is this is literally just a totally non-connected life event of like hey my significant other has this really important thing and i'm going to support them and it's nothing to do with you it's the easiest way to leave yeah exactly like hey

things are great i'm going off into the sunset we're moving to the arctic circle yeah the arctic circle yeah we're moving to the arctic circle to man an icebreaker as my significant other has always dreamed we're doing it for the wacky time zone and weird daylight changes throughout the year yep we just want to sail in a little mile long circle and go through all kinds of time zone changes just like rotate around that's probably not how the north pole works i actually was just wondering like if you live on the north pole could you just step out your door and you just spin around and you've gone back in time i am the master of time what time is it it's any time you want it to be here yeah i i don't know maybe i'm being naive but i don't see how this will blow

up in your face i think you've had really good work relationships work environments yeah that's true maybe i can't i can't imagine all the negative things out there i mean so say you tell them and you don't get the fun projects and i don't know it's fine you're leaving so it's not like you have to it's not like you have to to burn the midnight oil to crank stuff out or anything like okay i just thought of one bad thing that could happen okay tell me like let's say you're three or four months out and you're really counting on that three or four months of income to make the transition work and you do work for a crappy company and yes i have heard of this happening before where you go in and say hey i'm planning to leave in in a couple of months and they say

you're fired just right there no severance you're out yeah grab your things yeah security will walk you to the front door. That has happened. I've heard of it happening. And I think that's probably the worst case scenario here is that you lose that few months of income if you're counting on it. Yeah. So that's like the one reason I would hold it in my back pocket and might feel more inclined to delay. That feels like a thing you could know ahead of time, though. I feel like there would be signals that your company is actually like a bad guy from a Disney movie, you know? Yeah, right. So I guess if you have that context, then yeah, maybe play it a little a little bit sneakier maybe that's the two ends of the spectrum so on the one end you have jameson

is your boss he loves you and cares for you and he would never do anything to hurt you unless hr told him to and then on the on the other side of the spectrum you have disney bad guy and so you it's three months until go time and on disney bad guy you're doing two weeks notice and on jameson you're doing three months but you know you might be somewhere in the middle that will give me time to arrange the care package to arrive at your new destination the home the housewarming gift yep so you know maybe you're in the middle maybe you're a six weeks maybe you're halfway between evil disney character and jameson is your boss okay that's you just average them yeah yeah should i tell my manager up front i mean i i think i would tell them as soon as you know for sure that

you're leaving that's that's what i would do because that can change right yeah if you're not sure then it can get weird because if you might be leaving then you might not it might plant the seed of like maybe they'll leave again someday i mean i don't know it's tech tenures are relatively short so no one's going to stick around forever but still there's this weird thing in managers brains where they sometimes pretend like people will stick around forever yeah like it's only been five years yeah how could you betray me or we've been together for five years like our relationship is going to stand the test of all the rest of time at work forever that's right until we get sold but i think if you know you just i i don't know i would i would just trust

that's what i would do trust that nothing bad would happen to me perfect nothing could ever go wrong if you believe everything is great yep exactly have we answered the question i think so good luck what should people do if they want their own questions answered go to softskills.audio click ask a question fill out the form thank you so much to everyone who's done that we will get them eventually what can people do if they want to support the podcast click support us on patreon from our website softskills.audio and then another thing you can do is share the show with people tell people about it tell them to listen tell them that i'm six foot five that would support the show i want people to be real disappointed if we ever meet in person they'll be like oh you're so much

shorter i get that a lot that's because we're using we're using space feet yes they're different it's yeah space imperial metric system all right we'll catch you next week We'll be right back.