Soft Skills Engineering - Episode 109: Critical Junior Dev and Introducing New Tools

Episode Date: May 29, 2018

In this episode, Dave and Jamison answer these questions: I run a small dev team. One junior developer constantly openly challenges things that don’t meet this their preference. As a manager I don’t want to stifle innovation, but need to find a balance on being able to meet business goals on schedule. I want to add an automatic formatting tool to our code, but my co-worker is resistant to the idea. He started this project and I’m brand new to it. I don’t want to push it too much, but I would really love to use it. I’ve shared with him all the reasons that it would be good, and addressed most of his concerns. I’ve also submitted a PR to show him what it would look like. Also, he is in another timezone 9 hours away, so communication is all on GitHub, Slack, and the occasional video call (if I wake up early). He finally said if it really helps me, then I can go for it, but I don’t think he would like it if I did. Should I go for it? Try to convince him more? Or just drop it?

It takes more than great refactoring skills to be a great software engineer. This is episode 109 of the Soft Skills Engineering podcast. I'm your host, Jameson Dance. I'm your host, Dave Smith. Soft Skills Engineering is a podcast where we answer all of your non-technical questions about the technical field of software development. Sometimes we make jokes about what it's not about, and today we did not because I couldn't think of one.

So you're welcome, depending on how much you dislike my jokes. we've got some patrons to thank yes we'd like to thank nick cantar dimitro and neonilla david jackson chris fitkin ken howard sean clayton and dustin coats all these wonderful people are contributing to our patreon at the level where we thank them every single week thank you so much for your contributions if you'd like to contribute go to patreon.com soft skills eng your money goes to pay for hosting costs editing costs and to jameson's general well-being i have expensive tastes in thermostats i don't i don't know all right well would you like to read our first question i would love to dave this is from an anonymous listener uh and it goes a little

something like this thanks for the awesome operatically thanks for the awesome podcast your topics have been timely and well argued and i can't thank you enough for your insights I run a small dev team. One junior developer constantly, openly challenges things that don't meet their preference. As a manager, I don't want to stifle innovation, but need to find a balance on being able to meet business goals on schedule. Some examples are, they routinely call our current process stupid and make snarky comments about leadership, myself included, and up the chain. While I often agree we have limited resources and have to keep the business running, we can't always afford big changes to our source control, adopting new frameworks and major infrastructure

changes. Very often, this developer isn't privy to the information that has gone into the system we currently work in i've tried to empower the team but this particular dev is taking that concept way too far way too far and becoming disruptive really wondering what your thoughts are on these cowboy types any suggestions on how to rein them in a bit without dropping a hammer or being autocratic would be really helpful is it possible to have it both ways empowered and under control cowboys yeehaw i grew up in cowboys love our new frameworks new cattle rustling frameworks yeah what if we let's see how would you have a new cattle rustling framework maybe you made a pyramid out of cows and so only the bottom cows would run there is a python web

framework called pyramid if i recall correctly okay so that's already been done uh shoot well i can do it again i mean it's a framework pyramid to reinvent stuff um all right junior developer who clearly is strongly opinionated missing some context and also doesn't have a filter this is a trope i've heard a lot and i found it true in my own experience of um the the earlier i was in my career the stronger my opinions were in general and the more experience i have the more relaxed my opinions have become in general there are some things i have stronger opinions about but overall i am way less opinionated than i was at the beginning of my career yeah me too especially when it comes to technology choice or tool choice i've really i've really set those

opinions aside but the other thing that has attenuated in my career is how vocal i am especially in like a team setting where everyone is there i would never call something well okay hold on literally as i was saying i would never call something stupid in a team setting i was just having like my life flashed before my eyes thinking of all the times i've in recent memory called something stupid but you did it with a twinkle in your eye yeah and a smile on your face okay and gladness in your heart those that that smile and twinkle excuses all kinds of evils it does yeah you could get away with a lot with a twinkle in your eye maybe that's the coaching this developer needs just smile a little bit more when you call stuff stupid when you're

Then you might look like a serial killer. I really think your ideas are just the worst. Ding. Try not to be alone in a cubicle with me. I think you have too much blood inside. It's stupid to have all this extra blood. Let's get that out. That went morbid really fast.

Hey, it's not me. It's the serial killer. It's their fault. Yeah, clearly this wasn't your ridiculously disgusting idea. Yeah. Yeah. So this is clearly, I agree that this is a problem. It's a problem because a lot of reasons.

One reason is it might make people flip the bozo bit on this person. Have you heard of that term? have we discussed that in the podcast i don't think we i don't think we have and i don't think i've heard it but it instantly i instantly got what you're talking about i think oh explain okay i'll try and explain it the bozo bit is basically just it just means is this person credible or not and when when when you flip the bozo bit it means you just think okay they've like ranted enough times and said enough dumb things that i just know the stuff they say is not correct or worth listening to and the risk is that you do that prematurely and then you discard valuable input

from someone that you've just written off basically and as a defense mechanism the team might write this person off right if they hear their the way they do stuff is stupid enough times they might just think well they just hate everything we do and they don't express it constructively and so we just don't have to listen to them anymore because it hurts to listen to them yeah not only is it not constructive but it actually hurts a little yeah but also the the flip side is new people have a superpower of fresh perspective we've talked about this before i think julia evans probably is this i remember her saying something about this when you join a new company you have this superpower of not being used to the way things work and so a lot of people get used to

the way things work and then um don't recognize how much pain they're causing so you just assume I'll have to make five tickets through three different departments to get this thing done instead of have an API for it or whatever the specific example is. And when you're new to a company, you don't have that scar tissue built up. You don't have the calluses, the organizational calluses, I guess. So that's a valuable input. But if the way they express that input is this is all stupid, it's hard input to take. Yes. That's a very good way to describe it, I think. Why, thank you. So if I were this person's manager,

I would sit down with them and provide a little bit of coaching. And I think the coaching I would provide is I would say, your opinions are great. Your passion is great. But the way that you're expressing it is a lossy medium. When you say something is stupid,

that is actually not accurate and not specific enough to fix. Instead, if you can quantify what made you conclude that this is stupid in such a way that someone else can also conclude that it's stupid then we can maybe make traction on a fix so in other words instead of saying our source control which we're using subversion is stupid you could say if we switch to mercurial we would get all these advantages and we would set we would leave behind all these different problems that we have with subversion right by the way i

chose two mostly out of favor revision control systems to avoid saying the obvious let's just use github yeah but anyway now i'm gonna get a bunch of hate mail about from mercurial fans i think my i haven't used it very much but i i feel like i've heard mercurial is pretty great it's just not used as much as kit yeah anyway this person need this person is like a raging wildfire they certainly produce a lot of heat and that's great but they also destroy everything in its path we need to turn this person into a laser that can apply precision heat precision focus right on something that matters and actually get it done instead of just torching everything and i think if you do that with a little coaching session you could probably redirect this energy to something

constructive yeah there's a hierarchy here right and saying this is stupid is the lowest level of discourse about solving technical problems and the next level is this is stupid if we did this thing it would solve these problems and then the level above that is this is stupid if we change to this thing it'll solve these problems here is the cost of changing to this thing and the plan for doing it and so that lets you evaluate can we actually do it because if you just say in a vacuum right like subversion is better than files on a floppy disk that we hand back to each other that's probably true but there's all these processes and and experience built around the existing tooling and and way that they work and just you can't just snap your fingers and switch to it there's a cost

so if if you just come in and say this is stupid without the context that's that's another thing that could get you written off right is like yeah it's stupid but we have 80 million lines of cobalt so we can't we we can't just switch to write it all in rust like that's not that's not a possibility given the resources we have yeah um so i think you're right that this developer needs some coaching and maybe coaching them on looking to understand the context more and looking to figure out the costs and and the trade-offs is helpful you could also sell it as a benefit for them right If they, if they hate this thing so much and they want it changed, they're probably less likely to get it changed if they just kind of stamp their foot and are grumpy about it, especially as a new person on the team, they don't have a built up reputation with the team of getting stuff done and credibility. So just coming in from the outside and saying, this is stupid and, and, and knocking stuff down, that's unlikely to get people onto your side.

So it's not going to help them. if you say yeah you could catch it as if you actually want to fix this you need to persuade instead of just complain and that will help solve the problem if the problem you're trying to solve is like you don't complain enough then sure saying this is stupid will help solve that problem but it won't really it's not the most effective way to change things yeah yeah totally agree i i i kind of equate this person's actions to backseat driver actions you know this is the person that sits in the back of the car and calls out mistakes that the driver is making but but really they only call out the mistakes that they see and they certainly don't see everything that the driver sees and

most importantly they do not feel the pressure of delivering the vehicle and its occupant safely to its destination that the driver feels and i think a little bit of extra responsibility might actually help this person to to better formulate their thoughts in a way that takes into account all the constraints on the decisions that are being made and not just the inner fire that burns in their heart because they want to use this new framework so badly. If they understood like the business constraints or the people constraints, kind of like what you were just describing, Jameson, that there are zero, there are non-zero costs with changing a business or an organization, but also understanding that in the past there were constraints that

went into these things. And you can't expect this person to just know what those constraints were without telling them. And so I think that it might make sense to you for you as a manager to have some kind of documentation describing, here's where we are, here's why we have what we have. And these are the constraints that informed these decisions, such that if you want to change the way we do things in one of these areas, make sure that it also meets these constraints, and is respectful to the history that brought us here and make it to you know, to make sure that you don't actually like throw a baby out with the bathwater yeah that's a cool idea i've heard of places that

have rsc processes for making technical decisions and as part of that you create kind of a spec and a design document and describe the trade-offs and describe the reasoning and then once you once those get accepted they're kind of that record that you mentioned of here's why this decision was made here's what was going on at the time maybe they had three developers in two months to do it and that affected their approach and so if you hand this person the 80 million lines of cobalt and say it's great that you want to change this you've got three quarters and two people and here's your here's your shot yep should be fine right yeah that sounds like a really bad idea after i say because 80 million lines of cobalt is probably a very important project but the the principle of

like trying to help them understand the constraints i think is valuable and and maybe they'll only understand it if you put give them the opportunity to fix stuff by the way just to give you a little bit of hope or maybe to fill you with dread this person you're describing was me not really not that long ago frankly uh i've i've often been very passionate and heated in the way i describe problems and i've not often had the greatest tact and diplomacy when when sharing my opinions of others, including my own manager in front of others. And I have been called out for this behavior in the past for basically undermining my manager. And he very subtly gave me this feedback one time a few years ago and said, you know, Dave, and he basically told me a story about his past

where he had done this to his manager and how it came to his attention. And it took a couple of days for me to realize that that was not just a fun story from his past. He was telling me that he was telling me because yes indeed it was me so you might have to go a little bit past subtle with this person because clearly subtlety is not their strong suit but don't be afraid to do it and if this person clearly has talent and passion let's not let's not put that to waste i would recommend coaching that let's focus this thing yeah i think if you if you really want to help them improve this has to change and so that makes it easier to have a conversation about why the approach they're taking isn't working.

Yep, really for their benefit. It's not just for the team. Yeah, exactly. It's not you calling them out on their bad behavior. It's you saying, hey, to be more effective, you need to do these things. Absolutely. All right, have we answered the question?

I think so, I think so. And I would love to hear how this goes. So if you have this conversation or choose to coach them in some way, we would love to hear back about how that went. Yeah, please let us know. all right dave do you want to read our next question sure this comes from a listener named adam and adam writes i want to add an automatic formatting tool to our code but my co-worker is

resistant to the idea he started the project and i'm brand new to it i don't want to push it too much but i would really love to use it i've shared with him all the reasons that it could be good and addressed most of his concerns i've also submitted a pull request to show him what it would look like also he is in another time zone nine hours away so communication is all on github slack and the occasional video call if i wake up early he finally said if it really helps me then i can go for it but i don't think we i don't think he would like it if i did should i go for it try to convince him more or just drop it i like this question because it's kind of in some ways the inverse of the last question the last question was a new team member coming in trying to say

all the existing things were dumb and needed to change and this is a new team member coming in and trying to change something and the specifics of i don't know maybe adam's leaving out the part where he calls the existing formatting stupid that part sounds different but it's still kind of related yeah it is um although i'd say in this case adam has taken a very healthy track because he has talked about the idea he's extolled its virtues he's prepared a pull request to show the rest of the team what it would look like he's being very diplomatic and cautious and he's not forcing it on anyone maybe even to a fault what do you think yeah this is it's just so fascinating the interaction because the thing that they're working on is code and it runs on computers and

it's very objective and it's a sequence of instructions that get executed but the act of writing code on a team is a very social thing it's very fuzzy how you interact with other people and this is one of those fuzzy boundaries where it seems like they they don't really want you to do it and you might have kind of worn them down by being persistent and helpful and friendly and and showing all the benefits and from the brief description of the question it sounds like they're still not convinced but they are ready to give up and so the question is i thought you were gonna say ready to give it a try nope oh no it's i read it as they're like oh they're just gonna keep bugging me if i don't say yes so yep whatever if you want if you think it's a good idea go for

it and then you hear them going like this and if you can't tell that is the sound of me washing my hands so there's there's this very social human fuzzy interaction happening and the one of the things you could do is just say well they said yes in the pull request merge too late you could try and convince them more you could drop it i am all in favor personally of automatic code formatting tools so i think this specific thing i personally would be in favor of i actually did this to my team, but they were much easier to sell on it. So it wasn't that big of a deal to convince them. What you're really talking about is code ownership, right? Who owns the code? Who has the ability to impose new standards on the code? And Adam is a new team member, a new person

on this team. This other person wrote the project. And so I think a lot of the friction might be coming from the team member feeling like they own the code and Adam coming in and trying to change their code or trying to change their standards yeah and that's the thing you could address explicitly maybe and say like how do we decide on standards is it just whoever's been there the longest kind of sets the standard or you could just recognize that there's probably going to be some resistance to me as a new person setting standards and i'm willing to put up with that in order to get this particular standard set yeah or not right like you might decide you know i'll just table this for six months and i'll come back to it later after i've had a chance to establish

myself as a contributing member on this team yeah i think it's worth it because i think the benefits of this particular technical decision are great i think it makes it automatic code formatting eliminates a lot of useless decisions and it just makes it easier for other people to jump into the code base style is just a really personal thing that people get very very involved in and hung up on so maybe the hang-up is particularly about style not about standards but it could be you know i one of the things that i think a lot of people fail to take into account with decisions like this is the passage of time time has an effect on all of these decisions you can either wait to implement it you know to let the idea percolate in people's minds and in that case

time takes an effect or you can uh you can implement it with a with a time limit where you say look we're going to assess this for two months and after two months we'll reassess and decide if we're going to pull it out and you can let that time have an effect and in that case you'll the effect time will have will be that it will actually give people first-hand experience with the tool so they can speak from a much stronger position of authority when they comment on it rather than just saying that sounds like crap i don't want to use that i would say that putting in place a time limit either for yourself to reintroduce this problem or for your team members to have a chance to pull the escape hatch button and get out uh will really have a dampening

effect i think on the on how controversial this is at this moment in time here's the secret it's really not that easy to pull out because even if you pull the formatting tool out the code's already all been reformatted and then there's probably been changes since then so you're not going to just revert and lose two months of progress on the code that's true you can also use time as an evil weapon where you could say oh no this is just an experiment don't worry you know it's really easy to go back as long as no one does any work between now and then meanwhile its tentacles get all wrapped around your keyboard yes excellent perfect have you ever heard the concept of a two-way door versus a one-way door i have not this is a cultural

concept that i hear a lot in my company and i only go if i go through a door that's it i can't Once I'm in my office right now, I buy a new house every time I leave. I believe they're all one-way doors, so you might be about to blow my mind. I'm about to save you a lot of money, Jameson. Okay. There are decisions that are one-way and irreversible, and we call those one-way doors. And there are decisions which are easy to back out of and say, never mind, and we call those two-way doors. For decisions that are two-way doors, you should not spend so much time debating them.

you should try to get to resolution quickly. And if you can't just say, hey, we're going to take a chance on this and see if it works out. And if it doesn't, we'll bail, right? And then let the evidence speak for itself. But with a one-way door, and I think, by the way, this is a two-way door situation. With a one-way door, you really need to deliberate and analyze and discuss before you really make that decision and get locked into that thing. I would put this in the category of one-way door, even though it's going to apply some formatting to your code, maybe. And maybe you could set it up so that it's less of a one-way door where you could just say look we're going to only apply formatting to the files that we change um between here and the end of our experiment

yeah so you're saying the the burden of consensus is higher on a one-way door decision versus a two-way door one yeah exactly yeah that makes sense i i think you should go for it but i am having trouble articulating why because the downside is you might just piss off the the co-worker on your on the code base right who's been there a long time but i don't know that waiting it's like you want to establish the culture like i said earlier of who who owns this code who is allowed to do what on the code and if the answer is only the person that has been there and written it all is allowed to do stuff on the code then you're kind of just they're lackey and you don't you don't get to contribute as much right this this idea of applying automated

automated formatting is one of your contributions to the code base beyond the features that you write and and it feels like when you join a team the assumption is you get to contribute in lots of ways instead of just crank out features that fit the narrow confines of the existing standards yeah i'm on board with the two by the way for what it's worth okay well we both agree sounds like it's a done deal we haven't talked about the communication thing though right nine hours away they all communicate asynchronously it's hard to do in-person face-to-face communication yeah in my experience decisions where people disagree or have hard feelings are are trickier in distributed communication like that it's a lot easier to disagree and work through problems and

feelings in person than in github comments and things can come across a little bit more abrupt or a little bit snarkier than they would in real life especially if you don't have the in-person context of, of knowing just how the person communicates normally. So I think that doesn't make this easier. I saw someone the other day say several days of back and forth in a pull request can save minutes of pair programming time. And I think that's true. There's the benefit of synchronous communication is it's very high bandwidth. So it, uh, it, it might be worth just like one final in person or, or video call communication just to talk through it. And you wouldn't necessarily have to change your mind but just to make sure that their feelings are

understood and and you have addressed them as much as you can and you still feel good instead of leaving it all in just this back and forth asynchronous communication i agree i think that's a great idea all right have we helped adam i think so ship it ship that formatter yep sounds great dave what can people do if they would like to be helped as much as our Question askers have been helped today, which is to say maybe not that much. Well, you did a great job Well, I thought you did good. So maybe they maybe they did maybe they did get some help today Anyway, what they can do is go to our website at softskills.audio and click on ask a question where you can enter your question And from there we will take it away and eventually get to it

Thank you so much to everyone who has given us questions. There are so many we cannot get to them all but we really appreciate it Yeah, thank you. And thank you for people who are listening We've had a couple of weeks of sickness that have made us put out some reruns and we're glad to be back We're glad that you're back listening to new episodes, too. Please come back please If you had any idea how much of jameson self-esteem relies on you coming back each week You would feel awfully self-esteem is a unit and the numbers that measure it are numbers of listeners to my podcast All right, catch you next week