Soft Skills Engineering - Episode 171: Unwilling mentorship and tortoise vs hare DevOps

Episode Date: August 19, 2019

In this episode, Dave and Jamison answer these questions: Hey guys, love the show. I’m starting to realize that our QA engineer lacks some skills required to do their job effectively. It’s now starting to affect my work and I can only see it getting worse. I’ve tried approaching them about their work and given them some pointers on how they can improve. I’ve done several pair programming sessions as well. They are a bit stubborn though and I don’t think they will change until things get a lot worse when they realize their mistakes first hand. We are a small team and I’m the only other member of the team with automated testing experience. Should I be having a discussion with my manager about this? The company is pushing for more automated testing and if the problems are addressed now it would be easier going forward. I’m hesitant to say anything in case I open up a can of hate worms though or get them fired as they are a nice person. P.S. I’ve only been here a couple of months so moving jobs won’t be an answer for me on this one ;D Greetings from Germany, I am coming from the Infrastructure side of things, and we are a team of engineers with 0-3 years of experience getting into DevOps (tm). Often we encounter new tech-stacks that involve a lot of concepts to learn (like AWS, Elastic, CI/CD, System Provisioning). The way we approach these topics leads to some conflicts. Most of my colleagues like to jump into the water and set up production systems based on a mix of trial & error and copy pasting examples form StackOverflow. I on the other hand try to do things a bit slower by learning the basic concepts and applying them together with examples to get a deeper understanding of the system. My approach is slower but often leads to more robust and thought out systems. However it leads to my boss and my colleagues often eyerolling me for seemingly “overthinking” it. But I also see the appeal of the other approach, since it allows for fast results and pleases the stakeholders. But I see a lot of issues and often time consuming restructuring projects coming from that. Should I just give in and swim with the stream while i suppress my inner nerd cracking down on things? Loving your Podcast btw and recommend it to all my fellow tech nerds. :)

it takes more than being able to decode jpeg with your mind to be a great software engineer this is episode 171 of the soft skills engineering podcast i'm your host jamison dance i'm your host dave smith soft skills engineering is a weekly advice show where we answer all of your non-technical questions about the technical field of software development who needs web browsers when you can just look at a bunch of bytes and then imagine the image you also need to be able to do base 64 decoding in your mind though really well yeah that's part of it i guess pretty common yeah i'll just so you don't even have to send me well no i was gonna make a joke but it doesn't work because of how jpeg works never mind i was gonna say you could only send me like the first half and i could

say oh it's a picture of beautiful sunset but it's all interleaved that's true oddly because of how jpeg compression works in the frequency domain there is no first half jameson yeah well just send me the first half of the frequencies i guess i don't know once you do it long enough you just start to see yeah this is not funny i'm gonna move on what an intro uh we're on spotify we got a question from a listener saying hey why don't you go and put your podcast on spotify and the answer is because we already did and we can't have two otherwise we'd be cannibalizing our own audience so um if you want to listen we're there yep that's the end dave you've got a thing yeah i just wanted to let everyone know jameson and i in a rare appearance will be in the same place at the

same time this september 20th at the utah js conference in public even in public yes yes this is a very rare thing i actually think i could count on one hand the number of times we've even seen each other in real life yeah i think so i think you're right which is interesting every time i see jameson in real life i'm like oh that's what you look like yeah i've changed a lot okay so we'll be there on september 20th go to if you want to join us you can get tickets at conf.utahjs.com come on down we'd love to see you all right i want to thank our wonderful patrons shout out to these fantastic people who are donating at the level where we thank them every single episode matthew voidovich the agile ventures charity ted nugent

who i talked to and is real ted nugent is in our slack and it's a different one that that is their name crash bandicoot zach grannon this engineer goes up to 11x louis santos nick cantar taras karuk sean sunny tie sonic the hedgehog i have a robot nick marie russo chris hogan chase norton and stanley tactical radio thank you to all those people thank you to everyone else who has donated if you donate you can join our slack and feel good about yourself and you can do that by going to softskills.audio and clicking support us on patreon all right shall i read our first question please this comes from an anonymous listener who says hey guys love the show i'm starting to realize that our qa engineer lacks some skills required to do their job effectively it's now starting to

affect my work and I can only see it getting worse. I've tried approaching them about their work and given them some pointers on how they can improve. I've done several pair programming sessions as well. They are a bit stubborn though and I don't think they will change until things get a lot worse when they realize their mistakes firsthand. We are a small team and I'm the only other member of the team with automated testing experience. Should I be having a discussion with my manager about this the company is pushing for more automated testing and if the problems are addressed now it would be easier going forward i'm hesitant to say anything in case i open up a can of hate worms i like that i like that metaphor i just imagine they're all hissing like

when you open up the can instead of just wriggling that's right a can of hate worms or get them fired as they are a very nice person. P.S. I've only been here for a couple of months, so moving jobs won't be an answer for me on this one. Winky face. Okay. Quit your job is mostly tongue-in-cheek. It's not a replacement for good advice.

So I want to clarify that. We mostly say it as a joke. True. I think if you write perfect code, then it doesn't matter if the QA engineer lacks some skills because you won't need them. yeah what's uh what is this like who cares if your test suite is slow if it's never going to find any bugs because there are no possible bugs to ever find that's right so just become perfect

stop writing bugs and this problem is solved no bugs driven development time to apply the time-honored principles of just write it correctly the first time and do not write it incorrectly perfect start with no bugs and then don't add any right yeah you need a baseline that's the key yeah huh so have you worked with dedicated qa engineers before i have i have a little bit but i don't have a ton of experience it was only one job for a brief moment how does that relationship work it feels like i hear a lot about how it can be kind of adversarial sometimes because it's like developers are trying to produce things and then QA is trying to break their things or QA feels like, oh, they just don't even take any care and we find the most obvious broken stuff and they

can kind of be at odds. Does that match your experience? I've seen that with manual QA. With automated QA, the source of hostility tends to be, oh, some careless engineer completely refactored the UI and broke all of our tests. Ah, sounds like you have a selenium problem. yep i'll tell you it is hard to find good automation engineers really really hard my previous company we went through about four different teams over the course of five years before we landed on a team that really did an excellent job and i think after the second team i was like you know what as engineers we need to do more here so we started making it a requirement that every feature you shipped had to have special test markup so that the tests could have a

reliable way to locate elements on screen and and manipulate the ui and do their testing and that helped that helped a lot because then you could do crazy refactors and not break the automation tests sure it wasn't counting on like implicit structure or anything yeah exactly but yeah it can be hostile you said you went through it was hard to find the right people can you talk more about that or can you not talk more about that well yeah i think what it boiled down to for us was we needed people who thought that like flakiness was unacceptable and slowness was unacceptable and it was hard to find people who had that mindset where it was like yeah you know if your test fails 20 of the time that's okay right we found people like that for a few iterations

and it was very rare we found people that would step up and actually talk to the engineers and say, I'm going to give you requirements, you know, and in order for these tests to be successful, we have to partner. It was hard to find people who would do that. And I tried to bridge that gap, but you know, without reciprocation, it was hard. And I think what actually was happening here is that really skilled automation engineers tend to find higher paying jobs becoming product engineers instead of test engineers. And so the market, like the economy is against you. That's my impression, too, where there's there's cultural and market forces that kind of push very talented people to get into QA engineering out of it eventually. I think many of them see it as a stepping stone.

Yeah, exactly. That's what I was going to say. It's a way to get into software, but it's not lots of people's end goal to be a QA engineer. And there are certainly some people and there are talented people who want to do that. If you find a person who wants to make a career out of QA engineering, they are a gem. And just hold on to them. Oh, love it. I've heard of this at Google where they have software. I mean, I guess it's not just at Google, but they have software engineers in test. And that's a career track.

It's not like a stepping stone. It's a thing that is emphasized just as much as product engineers. So maybe there's some cultural stuff, but none of that will help you. That's right. the problem is you have this person that you feel like could be doing a better job and you've tried a couple different ways and it has not worked right and speaking broadly i don't think this is a qa specific problem yep i think that does color the advice a little bit because there's a like a dynamic between these two roles but i don't think it's strictly qa yeah and you're

not in a managing relationship with them it's so you you have to influence without having explicit authority over them and they have not been receptive to your influence what do you do influence harder maybe pair even more yeah approach them and give them even more pointers maybe stare more deeply into their soul yeah okay so you have to try the three approaches which are passive aggressive aggressive and passive to cover the full spectrum of influence what is what is just passive i'm trying to think so okay passive aggressive would be like leaving sarcastic comments on their pull request okay passive would be leaving sarcastic white

space comments on the pull request where you just put a bunch of tabs in with sarcasm as you type them okay i believe or yeah maybe it's just maybe it's just passive aggressive but the aggressive part is shrunken down so much where it's like encoded in microfilm dots in the periods of the notes you write them or something the aggressive part is invisible to the naked eye yeah it's like it's like calculus like as the yeah as as the aggressive shrinks to negative infinity then it just turns into passive even though it's still it's still kind of there it's just an infinitesimal amount yeah all right those are obviously the first things i would try um huh yeah this is hard because someone who does not want to be taught is going to not want to be taught even

more if they feel like you're butting in and like sticking your nose in if you're being like a busy body or know-it-all or something that's i know i just shut down and roll my eyes and i'm like i'm gonna get dumber on purpose just to show you if someone tries to if someone's like listen let me tell you how the world works jameson young jameson who doesn't know anything screw you and then i eat a bunch of tide pods or something you're like problem solved yeah so what what does work i feel like i'm very receptive to being taught by people who i feel like we have a relationship built on respect with where it's not just that they know everything and i don't in in every case they know more than i do it's that i've built up some trust with them and that i trust that if they have some

observation it's worth listening to wouldn't it be great if humanity could get to a point where good ideas are just accepted by everyone regardless of where they come from or whether we trust a person yeah we got this spaghetti bowl of intertangled things where it's like well you've only been at the company for two months so yeah so you don't know yeah you haven't you haven't earned your earned your cred yeah paid your dues but i don't know how i don't know how that helps question asker it might be a harsh reality that you have to come to accept that these things take time and maybe the answer is there's actually nothing you should be doing right now until you've built a relationship of trust first and these things just take months yeah i mean the

question asker mentions talking to their manager and i feel like you you've correctly identified the quandary there which is you can spend a bunch of time building a relationship of trust and kind of demonstrating you know what you're talking about and you have helpful advice if they're receptive to and they might they might just not be they might just be really insecure and not want any criticism at all but if they really are causing that much of a problem then you have to weigh like what's the opportunity cost of doing this long thing versus me just complaining to the manager and then the manager saying hey you have to change this or you're not going to work here anymore you know like there's there's clearly some cultural and morale costs to that but it's

kind of a shortcut i guess the other thing you could try to do here is appeal to something that this engineer wants and at some companies there are explicit career track rungs and you know i don't know if it's true at your company i hope it is because it's really nice to have something that you're reaching for in your career where you say i'm going to grow to the next level and here are these clearly spelled out requirements that i need to meet and if the qa engineering ladder has these things spelled out you can appeal to these and say are you interested in growing to the next level because i can help you do that now that could also backfire because you're not actually on the same ladder right and so it's like you have no business telling a qa engineer

how to move up to the next level for them when you're working on a totally different track yeah and then you've just betrayed them the bottom line here is basically what you're saying is i want to mentor this person but they are not taking the initiative to request the mentorship and that's pretty that's pretty unusual for a person to reach out and when i see that happen which is rare but when i see a mentorship relationship happen where a mentor reaches out to someone to be mentored usually it's like hey i see a lot of potential in this person and i want to offer to help them but this this situation is a little different from that. It's like, hey, you're failing and it's impacting

my work and I want to help fill that gap, right? It just doesn't feel like the same kind of pure motive. Yeah. And maybe they sense a little bit of that is what you're saying. It might be coming through. I mean, there's also the other person's attitude too of you can't make people understand something they don't want to understand. And if they're just so closed off to feedback, I don't know how you get through to someone like that without letting them suffer and see the value of doing things differently i don't know i don't feel like i have any good advice so we can hearken back to our last episode about conspiracy theories and here's what you do aha you bombard them with conspiracy theory topics all the time then just when they think you're going to hit them up with

another conspiracy theory you give them some solid engineering advice and they're just so relieved that it's not a conspiracy theory that they accept it what if they think it's a conspiracy theory though they're like yeah dave was talking to me about the mole men as he does and then he brought up something called the liskov substitution principle like i know a shadowy conspiracy when i see one clearly this barbara liskov never existed just a tool of the illuminati they just don't want you to use global variables because they know it will make you more productive they're holding you down yeah big illuminati holding you down oh boy yeah i i think what you hit on is that it if they haven't responded well then the answers all either take time or involve

pain so i think you have to decide if you want to invest a bunch of time in this and if you do there's a chance and if you don't i could see it would be frustrating but if you talk to your manager about it the danger is that you are hurting their reputation yeah with the manager so i don't know i feel like you should be able to talk about concerns and problems you have but there's always the flip side of how it affects how other people see the person yeah and i think if you just couch it in terms of i i want this to get better and i want to help and instead of this person is really bad at their job and lacks critical skills yes that's always an easier conversation to have and feels less like you're just like you're just complaining you know um or or frustrated yeah

like if you could paint a picture for your manager where you say hey i think our team could get to a point where qa engineering adds all this value and this in these specific ways right now we're a little short of that and i would like to help get our team to that point and to do that i want to coach this person this way can you support me in that and then maybe the manager could have a much more supportive conversation with that person which would incentivize them to come to you and now you've reversed the relationship the way it should be where they're actually seeking out your advice that would be like best case scenario yep well i have no more words about this one and that means the question has been answered all right good luck i will read our next question

this is from another anonymous listener greetings from germany i am coming from the infrastructure side of things and we are a team of engineers with zero to three experience getting into devops trademark often we encounter new tech stacks that involve a lot of concepts to learn like aws elastics cicd systems provisioning the way we approach these topics leads to some conflicts most of my colleagues like to jump into the water and set up production systems based on a mix of trial and error and copy pasting examples from stack overflow i on the other hand like to do things a bit slower by trying to learn the basic concepts and applying them together with examples to get a deeper understanding of the system.

My approach is slower, but often leads to more robust and thought-out systems. However, it leads to my boss and my colleagues often eye-rolling me for seemingly overthinking it. But I also see the appeal of the other approach since it allows for fast results and pleases the stakeholders. But I see a lot of issues

and often time-consuming restructuring projects coming from that. Should I just give in and swim with the stream while I suppress my inner nerd cracking down on things? Loving your podcast, by the way, and recommend it all to my fellow tech nerds. Smiley face. all right thank you yeah so infrastructure side of thing we are a team does that mean that the

question asker also has that same amount of experience i think so okay so young team new to devops trademarked devops concepts yep and a bit of a conflict of styles maybe more deliberate and thoughtful versus kind of hands-on and trial and error and and experience driven this actually was me a few years ago on the other side of this i was the quick and dirty get it get it shipped immediately uh and i had a co-worker who was the more thoughtful and deliberate what happened uh we had we had a lot of conflict you're victorious uh no no i i don't i don't think so because in the end i think i came to see it his way actually and i i think what happened was over the years i would observe

where questions would come up like how does this work and he would just know the answer and he could he could refer to like governing principles and say well the you know the philosophy of this team that built this thing is x and therefore i can say that it works this way and he would be right and and the reason is he had read all the documentation he had built prototypes running on his laptop or whatever you know and experimented with it and learned and poked and prodded meanwhile I was like, well, Stack Overflow says this config file should work. Paste it in, ship it, launch it. You know, we're going to production. Ship it, launch it, shrink wrap it. Yeah, exactly. Seal it. And then, you know, three months later it fails and we're like, I don't even know how this

works. But boy, I've really changed my tune on that. Like now I'm a studier. I'm like, let's understand this technology. And I think what's happened is I've been burned so much by the quick and dirty, get it out the door mentality. And I've also had more long-term exposure to these technologies that I thought were like, you know, God's gift to technology when they came out. And then I realized, no, you know what? These are all a basket of trade-offs. And I really want to understand those trade-offs. I really like that phrase, basket of trade-offs. I don't know. I think I'm still a little bit more on the ship it side because I'm a little bit more skeptical of expertise without experience, maybe. True. Good point.

And if everyone is new to these concepts, you have to get hands-on experience at some point. It also depends on your context, too, where if your company might not exist in six months, then it doesn't matter if you find out the right way to set up your continuous integration pipeline in three months, and then it pays dividends for years. It won't. yeah but i i guess i feel like this this conflict is healthy in general that it is healthy to have a mix of these approaches when i interview people for my team i ask them where they fall on this kind of a cowboy coder to architecture astronaut spectrum to insult both ends equally and i don't think it necessarily means one is better than the other it's just that people have certain opinions and they they fall on that spectrum somewhere and i i found it helpful to have a mix on the team

because they kind of help balance each other out a little bit yeah if if you only have people that really want to kind of go slow and deliberate and and robust there's still some things you'll never learn that you will learn by just trying like five different things and leaving behind four horrifying messes i feel like everyone knows that the downside of the other approach which is you leave horrifying messes all over the place yeah so you you called this tension healthy yeah how do you manage it without having a side effect be that these people just can't get along anymore i think that's where you need safety on your team and you need the ability to productively have disagreements and and that's that's a much bigger question than how do we resolve this conflict it's

like how do we resolve all conflicts if your team is a place where people can productively express different opinions then you get the value of negotiating those opinions and that comes from people respecting each other and from people trusting each other not necessarily agreeing but trusting that people are arguing in good faith and no one's trying to be sneaky and backstab people or i don't know and then the end result is probably like some of the time they roll their eyes a little bit and say oh whatever you have to read the docs before you deploy something but then you save the day sometimes and then you're a little nervous a lot of times about not understanding things but you end up kind of learning more from the fires of production I guess

than the calm study of development I do think it's it's worth trying to think through how you would have known if you see things go wrong so it's one thing to say I don't have a ton of experience but I'm uncomfortable deploying this without knowing more about it versus saying I have experience and i believe that the thing we will do that we are doing is going to go wrong because of these reasons like one is just kind of a vague discomfort and the other one is is something born of seeing other systems before and i think that's probably a signal that you need to talk through it if you can say here's why i think this is bad instead of just like whoa we're moving a little fast here and and we maybe don't understand everything we're doing if you can

point out more specific things that feels like a better way to frame the discussion than just say whoa whoa we don't understand everything yet right and it might even help you to come to terms with your own concerns because sometimes these concerns feel bigger than they actually are and then we get them down on paper and go oh it's actually just three items and if we resolve all three of these then I'm fine this has happened to me many times where I get very worked up over things that seem like a big deal in my head. And when I talk through them with someone else, I've constructed this whole web of related concepts and concerns that really are just one thing. And we can summarize that and focus on that. The other thing I've noticed about myself is that

this tendency to be on the cowboy side versus the astronaut side is very much contextually driven for me. So like when I was at a startup and the question was, are we going to exist next year you know i was like let's do it let's ship it let's just do it we got to get something out there to sell right but now that i'm at a large established company with a product that's been launched for almost five years and you know and money and yes and funding yeah now i'm like you know what let's take our time and design this right before we put it out in front of 50 million customers yeah that's a good point there's also some elements of how easy it is to change your mind where if it's a startup and you don't have any users yeah you can just like throw it away

and do a different thing and that's fine the cost of getting it wrong is the cost it takes to build it not the cost of maintaining it forever right and that that might be an argument for going a little bit slower because generally infrastructure is a little bit more painful to migrate away from than than product decisions yes for sure but i think that could be a way to evaluate how big of a stink do i make about this how how hard is this going to be to change if it turns into a giant disaster right yeah and if it's like i don't know we'll swap out jenkins for some other cicd thing which is kind of different but like you can squint and they do similar things right maybe that's not the biggest deal but if it's like i don't know we have to move from from oracle databases to some

open source no sql database that's gonna be hard yes expensive exactly even if you are moving away from oracle it'll still be expensive that's right even if you're not paying oracle anymore yeah I think a good metaphor for what you're describing is a one-way door versus two-way door and a one-way door is one that once you go through it it's impossible or very expensive to go back but a two-way door is one where you can step through and step back and it's just not that big of a deal and I think the amount of effort you invest up front of the decision before you walk through the door depends on what kind of door it is yeah isn't that a Jeff Bezos thing maybe i feel like i've heard him talk about he has i know he did it yes okay we can acknowledge

it a lot of what i say these days should i give in and swim with the stream while i suppress my inner nerd cracking down on things i don't think so i think you should you should choose your battles though i think the danger is if you are the voice saying go slower go slower go slower if there's ever a problem caused by going too slow you are an easy scapegoat for that problem now true it's harder to see problems that you didn't have that you avoided by going slower yeah so you might have to invest a little bit more in communicating and saying like look we saved this much money or we avoided this giant problem because of of this deliberate thing we did it's easy to see the value from just cranking stuff out you know it's easy to see the short-term

value. So you might have to invest more in communicating that. I think what you're saying is you might have to dig up all the dirt that come from going fast. And you know, there's plenty of it. I mean, I guess if you want to be really negative, if you want to be like a company muckraker, but just insulting people's work is hard and likely to cause problems. I think it's easier to say, look at the good things that happened because I was deliberate. Or look at the bad things that didn't happen like we have five nines of uptime and you know we've never had a customer outage or whatever yeah i think it's okay to bring up issues caused by other people's decisions if they're kind of acknowledged already well no that's not true i'm i'm waffling

too much because if they're really causing a problem you should be able to say hey this is causing a problem without worrying about hurting someone's feelings right and the real question there is could these problems have been prevented or or reduced in impact if you had done some research up front and gone a little slower and that's a hard question to answer but if you can confidently answer that question then you might have a case yeah i think that gets down to the approach versus experience thing i was talking about earlier where there might not be an amount of time you could invest in reading first that would solve or uncover problems right there might be things you'll only get by just trying it. Yeah. And I believe that, by the way. I think

nothing teaches you about how a service or piece of technology operates than operating it. Yep. I've actually found it really funny because a lot of times you'll put something into production and all you've read beforehand is the documentation from the provider of the service. Yeah. Who is a little biased to say their thing is good? Yeah. Then when you start experiencing problems, you start Googling for specific error messages or specific situations and you realize oh my gosh there's this whole community that's been talking about these major problems with this technology that i just didn't ever see you know and so it's like yeah that community lives in the forms and the hype only lives in blog posts and documentation

that's right you gotta read those forms after before i know you just never know what to search for you know and then you'll you'll stumble upon one error code that just like unlocks this whole world that you didn't know existed one other thing you could do is try to limit the or narrow the scope in which you just try a bunch of wild stuff where you could say this one part of our stack is going to be the experimental part we're going to try a bunch of different stuff for our like in memory i don't know database like we're going to try redis and memcached and those are the only two i can think of but there are probably more and that way you don't have every layer being kind of thrashed all at once you just isolate the cowboyness to a single part you just set up a

little dude ranch in your code base and say everyone who wants to play cowboy go here stay on this side of the fence and these areas we actually really need to be stable we probably don't want to thrash on our database all the time because that has huge costs and right there's a lot of hard one knowledge there or or like the core programming language we use for everything or stuff like that so you're saying give the junkies a place where they can get their fix yeah i think so i believe that's what i'm arguing for perfect set out a little salt lick for the deer they're cowboys they're drug users they're wild animals what other metaphors could we throw in here what other terrible metaphor yeah deer are great they're cute yes right that's true

have we answered the question? I think so. I think in summary, I think every team needs a healthy balance of this, but they also need a forum for communicating this stuff safely, like Jameson was saying. And I think as you are providing the counterpoint, the opposing voice to some of these ideas, you might want to make sure you're always building on common ground and saying, hey, I want this to be successful. I want our customers to have a great experience. I want our platform to be awesome. I want us to use the latest technologies. And in order to achieve that, I think we need to go slower in these ways so that you have this common foundation from which you can both build instead of just saying, you're going too fast. Let's slow down. Yeah. You're

breaking everything. Stop breaking everything. Yeah. Yeah. I like it. Well, have we answered the question now? I think so. Good luck. Good luck. Let us know how it goes. All right. Where can people go if they want their own questions answered? Go to softskills.audio and click ask a question. You can fill out a form there with as much information or as little information as you like and we will put it on our list and we look forward to hearing from you all right catch you next week