Soft Skills Engineering - Episode 111: Dogma Rehab and Getting a Co-worker Fired

Episode Date: June 12, 2018

In this episode, Dave and Jamison answer these questions: Hello Jamison and Dave. 💕 your show! 👏 I have been a C# dev for 7 years. Last year, I learn Erlang. I fell in love with functional programming. After that I learned Elm and oh boy… I had never dreamed a compiler/computer could do so much work for me, preventing so many mistakes that would otherwise require an unholy number of “unit tests”. The thing is I can no longer find satisfaction with any job. I love to write software, but at some point I became almost dogmatic. I abhor more and more the discipline it takes, in certain languages, to make my code be as pure and testable as in an FP language. I had to do so much un-learning, that now I feel that I am refusing to un-un-learn all these different ideas and paradigms and just go back to making the tests happy. I seek your humorous words of wisdom on how to find contentment with my job again, without looking at a language and dreading it. I have a co-worker, who is pretty incompetent technically. Over the past few years that I’ve been here, he has proved time and again that he is incapable of learning and really grasping how things work. He is able to accomplish basic feature work, but not capable of making good architecture decisions, or why a given framework should be chosen, or how to solve harder problems (I’m not sure how to describe this. But for example, how to build a resilient API client). However this person is great at creating slides, and presentations, and JIRAs, so I think management thinks they are ok at their job. He’s also a nice guy. I’m not sure how to say, hey you suck at your job. Which is pretty harsh. Or to suggest to someone that he should be replaced.

It takes more than a fancy editor color scheme and a coding font with ligatures to be a great software engineer. This is episode 111 of the Soft Skills Engineering Podcast. I'm your host, Jameson Dance. I'm your host, Dave Smith. Are you laughing because you are one of those peons that don't use a coding font with ligatures? I don't even remember what ligatures are. Oh, ligatures are little like, I don't know what the technical description of them is, But I know when I type, like, double equals, it'll connect the two equals and replace them with a different glyph or, like, greater than or equals to or there's lots of, like, maybe it'll replace the anonymous function thing with a lambda. Like an actual lambda symbol, a Greek lambda. To make it prettier.

Yeah. And makes you a better developer. That's right. I bet you use Times New Roman as your font. i think yeah i just draw the line at variable width it's got to be a fixed width font and that's it yeah i've heard of people that use variable width fonts and i believe that they're trolling everyone doesn't don't ligatures make it harder to align your code like you effectively have introduced a variable width font right uh i think all right time for the traditional talk

about stuff that we don't know anything about but i'm pretty sure they combine it into fixed width symbols that are as long as the original input symbol yeah yeah so like triple equals is the same length it's just three lines all completely connected together okay stuff like that i don't know how i program without that i mean frankly it just your eye doesn't have to stop to scan and each individual symbol, you just read right through them. It's like this smooth track from left to right, and instead of stopping at every character like I normally do. I mean, I'll never get those microseconds back that I've wasted

scanning equal sign by equal sign. Yep. How many equals? One, two, three, four. Nope, just three instead of just like, zoop. Oh, man. what a waste okay oh what what is this show this is a show where we take your non-technical questions about the technical field of software development and we answer them yeah we'd like to

thank our supporters of the show who are contributing on patreon at the level where they get a call out every single week this week they are nick cantar dimitro and neonilla david jackson chris fitkin ken howard sean clayton and dustin coats thank you very much yeah thank you so much your support helps go to pay for lots of expenses we're actually looking at uh doing some more design work so we're going to use some of the money that we've raised through patreon to do that and it will result in more beautiful graphics which will eventually turn into more beautiful stickers and all kinds of neat stuff so thank you for supporting that we are stimulating the economy with your patreon contributions yep should we read our first question sure would you like me to

Yeah, I would. Okay, this comes from a listener named Fabio, who says, Hello, Jameson and Dave. Heart emoji, your show, clap emoji. All right. That was good. So it's clear to me you don't use a font with ligatures because you're reading the individual characters

instead of abstracting over the meaning of those symbols, Dave. It's true. It's supposed to be love your show. like that okay god it's not clapped between every word which should be if they were if if fabio was calling us out for something stupid we said but right that would be like slow clap between each word okay which we also welcome by the way uh okay moving on here he writes i have been a c-sharp developer for seven years last year i learned airline i fell in love with functional programming After that, I learned Elm, and oh boy, I had never dreamed a compiler or computer could do

so much work for me, preventing so many mistakes that it would otherwise require an unholy number of, air quotes, unit tests. The thing is, I can no longer find satisfaction with any job. I love to write software, but at some point, I became almost dogmatic. I abhor more and more the discipline it takes in certain languages to make my code be as pure and testable as in an FP, which stands for functional programming language i had to do so much unlearning that now i feel that i am refusing to un unlearn all these different ideas and paradigms and just go back to making the tests happy i seek your humorous words of wisdom on how to find contentment with my job again without looking at a language and dreading it okay a couple points to address first

what is the unholy number of unit tests i'm assuming that's 666 unit tests maybe in different cultures there are different unholy numbers i guess it could be 13 that would be unholy for a few reasons unless your code is very small how many unit tests do we have we like to keep it at 13 another thing is i i like this model of learning and then unlearning and then un-unlearning it's Fabio has been swept up in this vision of the glorious functional programming heaven-like state, and then he has to descend back down to the mud and typing equals all the time for mutation and pointers

and all this common stuff that brings you down. it says here that he became almost dogmatic based on what you wrote here fabio i think you should scratch the word almost you're straight up you you got dogma i mean you got it um there are religious connotations with the word dogmatic as well so i think that metaphor is still fitting so i love functional programming i think it's fantastic and if i could choose i would write all my code in functional languages and styles i also in the past several months took a job writing uh golang and angular and javascript and that's so far from functional programming go is all about um imperative code and mutation and and it's not quite object oriented but it's

definitely not functional javascript and angular one is is well it can be a rat's nest of side effects and mutation and things like that you can write it in different styles too but it turns out it's all it's only a rat's nest of side effects and mutations if you're doing it right yeah or or if like you've written code that shipped instead of was in a blog post i guess yeah so i i feel you man i feel this tension between like here's the kind of style i really like i like this feeling of like thinking through the problem and modeling it with types and and thinking about functions that don't have side effects and just passing your data through this pipeline that transforms it and and uh modeling io in a way that doesn't involve side effects all

these things are super cool to me and then i just don't do it at work and i guess for me i also think lots of other things are cool so it's not as big of a deal that like i i love the engineering side of functional programming and i also really like these like scaling problems and team and people problems and and um so it's kind of like a trade-off where i'm okay doing technical work in non-fp languages i think jameson you've taken great solace in curating an eclectic collection of clicky keyboards too yeah that's that's true i believe that is related to functional programming it helps you take your mind off the fact that at this moment i'm not typing l yeah but at least the click is so satisfying every character yeah all my pain is washed away by the ecstasy of the

clicky clack i mean it does affect how i write code in other languages but there's also we'll probably talk more about this later but you you can talk about how you can borrow from different languages and paradigms but there's a downside to that where you there's a there's a common idiom in your language of choice and there's a common style and if you bring in element haskell into c-sharp the people that just write like air quotes normal c-sharp are not going to understand it they're not going to be familiar with it or comfortable with it you're you're going to be fighting against the the current of the language in the community and so i think a lot of times the advice is like well you can just you can just try and bring that stuff back and to some extent

you can but it's hard to do it completely it's always this unsatisfying Frankenstein monster of like yeah I'll do some stuff maybe I'll make sure more of my functions are stateless and but there's all this other stuff I can't do because of the language or if I do it I have to do it in this weird workaround way like I don't I don't know I don't get good pattern matching like Erlang has or I don't have algebraic data types like Elm has and so I have to like have giant switch statements to look at strings or whatever your weird workarounds are so i don't think you can ever just get there by copying things over for me at least that just it made me sad trying to copy it too explicitly or trying to trying to model different programming language paradigms in in

cultures that i feel like didn't support it it's like just it just kind of feels like rubbing salt in the wound you know a little bit and and also at some point you know how to do this you're trying like you can't all of the tooling and community and libraries and stuff in in that language are geared around that paradigm and it it becomes valuable not just because the paradigm is great but because you have all these things to support it and when you move away from that it the value drops a little bit and the effort to implement it certainly rises so you might run into this situation where like yeah it'd be cool if you used monads everywhere but like it's also going to cause a lot of pain and a lot of problems in your c-sharp code so it might not be worth it in

the long run or the short run honestly well uh one thing you could do to fill your time and and maybe make you feel better about things is uh at work you could try to defeat all of their your co-workers unit tests and linters and stuff in really subtle ways that point out flaws in your language so then they will come to the conclusion on their own we gotta rewrite all this in scala you're like no that's not what i wanted i've made a huge mistake i'm sure scala is great you just have to be waiting in the wings at all times and be like you know this never would have happened in haskell yeah i've worked with people like that i've also been that person too and it didn't go great we sure didn't use haskell

but it's good it's good to have a a judicious person around who says things like that right to just make sure your mind is open and your team is aware of yeah alternative approaches yeah it's also nice sometimes to have this green verdant pasture that like all our problems would be solved if only we were in this other language and i can tell you i've spent some time with haskell folks and maybe all of your problems would be solved but you would have plenty of new problems there's no silver bullet for sure but it can be nice to think like oh wouldn't life be great if if all the problems we know about were solved and we didn't know about any of the new problems that this would cause i'd like to exchange all of my current problems for ignorance

yeah that feels better yeah but i don't know it can feel nice i think it is great to work on teams where people bring varied technical experiences and varied ideas and stuff that's that's super motivating to me and i love it when somebody brings up like a framework or paradigm or tool that i don't know about and teaches me about it even if we don't end up using it it's energizing so that's cool you know i i really think you struck an important vein jameson with your comment about these green pastures and how you don't really see all the problems one of the things that this listener said in his comment that we trimmed down a little was that he had actually picked up these languages on his own time which means he was probably working on pet projects

probably alone and didn't really have the burden of like production maintenance and operational stuff and frankly when I do little things on my own pet projects I just don't really get a full sense for what it's like to operate a product with that technology with actual customers with a team with business requirements and pressures you know that really changes everything and boy does it really bring it really exposes some of the cracks in your language so the fact that you're not completely in love with c-sharp which is your production language of choice today for your team anyway isn't really surprising i think most people use their language or technology until the cracks appear and the pressures of operating their business force you to see all the issues and

you know you can take solace in the fact that if you brought elm in you know things wouldn't just be magically better and i think that's really important for you to internalize i love elm and definitely some things would be magically better but some things would be worse and one of those things that would be worse is trying to bring a team of c-sharp developers over to your side with elm if they if you airdropped it in on them man it's really easy to torpedo a technology choice if you hate it and think it's stupid especially when it requires pretty dramatically changing the way that you think and that you work and elm certainly did that for me maybe maybe everyone there will be a natural but uh there are plenty of human problems to go with this if people have

invested a lot of work in a certain in a certain model and paradigm i i guess we could talk about i don't know we've kind of poo-pooed the idea but we've told you it's dumb and wrong i don't think it's dumb and wrong we could talk about what you could do if you want to do this if you want to use these languages professionally right i mean an easy well not easy one immediate solution is to just go find a job that uses those i know people sometimes do that when technology is very important to them they'll they'll just go find a job that uses that technology that feels relatively common to me um another option is to try and introduce it in your current workplace i think this one for Erlang at least might be a little bit trickier.

My impression is C Sharp is kind of a monolith that lots of people use only C Sharp and it's not like this microservices environment where you run some stuff in C Sharp and some stuff in Java and some stuff in Ruby and then adding one more thing isn't as huge of a deal. So that feels a little bit trickier. Elm technically might be a little easier to drop in

because you can just put it on some UI chunk somewhere. and and replace a little piece that was javascript with elm but again the i think the harder thing is going to be bringing your team along i've had an experience where i tried to convince a team to use elm and i i like i don't know i guess i just wore them down but they didn't actually want to and and it turned out to not work because they weren't on board and and there are certainly a lot of new problems that come with it and if you don't don't believe that it's worth it then all those problems just hurt so much more to you and you're not willing to work through them so it's just like this burden that you hate that's not a good spot

to be in yeah so i guess if you can get the team excited about it and willing to try it maybe you do little demos maybe you you pair with them you do little spikes of demonstrating concepts and benefits if if they're sold on it then i think it's a it's a possibility of introducing it and if they're not you're gonna be dealing with grumpy people that will that will have trouble succeeding in this new world i guess i i mean i i would say in this situation i would probably not encourage fabio to try to get his team to invest in erlang or elm or any big change like that unless there's a real clear business case yeah i mean so he's just kind of sampled in it first of all just pet projects um it's definitely too early to recommend it for the team and i don't really think that's

what he wants to do anyway i think he just wants to not dread going to work every day you know and i think trying to convince a team to change it could actually amplify that dread why how would that amplify it well because now not only are you dealing with this dreadful language that you've decided you don't like but you also have all these dreadful co-workers who are telling you that your other language is no good and your job is to try to convince them to change their mind yeah i mean you really got to be up for that if you're going to go in based on what i've read here i don't think fabio's up to that i mean yeah i don't know maybe baby steps i think if you like you said if you have a compelling business case beyond it's

i like this paradigm better it's a little bit of an easier sell to introduce it at least um i don't know what that is because i don't know your situation but if if you have a reason beyond i think i would be happier programming this way because i think it's better programmers love opinions like this about like this is the right way to build software and everybody has one so just saying like no this is the right way to build software i think is unlikely to to win people over if they're not already kind of in your camp yeah totally agree you could use f sharp just replace one of the letters c to f that's like a tiny change easy yeah i mean i'll tell you exactly what's going to happen if you do that you'll have one or two developers who are interested in f sharp

they'll start writing their new code in f sharp occasionally or maybe only this one module and then everyone else will just dread going into that module because they'll be like oh geez i don't know how to change that i don't know how to test it i don't know how to make changes to it without breaking stuff i've seen that kind of thing happen in a code base where this one part was written by this one developer who was super into scheme you know and it's like no one else will touch it right it's just really hard to voice this kind of a change on someone even if you have a pretty proactive learning focused developer team it's pretty tough yep i has i had a similar experience one of my co-workers at an early job got really into haskell rewrote a significant

chunk and an important chunk of our application in their translation of haskell into the language we were using there and i was just completely and utterly baffled i didn't know what currying was i didn't know what higher functions were were it was it all looked like magical nonsense and i could not touch anything and i was so mad at them because uh they rewrote they rewrote it but also we still had to maintain it like there were still bugs in it and there were still features we needed to add to it so it felt like they just like came in and made my life horrible and created this chip on my shoulder that i have against haskell to this day still really you still carry that no i don't i actually really like it um but boy was i upset for a couple months so don't be that person yeah

definitely not all right have we answered the question well i mean you mentioned maybe you'll get a job in it but the challenge there is that you don't quite have enough experience for a team of seasoned elmers is that the word they used to describe themselves by the way elmos oh really i don't remember anyway boy elm can just go in a lot of weird directions so you know you probably don't quite have enough experience to really go land a job as an experienced elm developer so you're in this catch-22 right where you you want to work in these technologies you can't get a new job doing it your current job won't change to do it uh what do you do and i think the answer is you try to find ways in which you can contribute if this is your goal to find a job doing this

full-time find ways to contribute to elm projects and make a little bit of a reputation for yourself such that you can cite that as experience when you go to your new job now of course this will take time out of work but it sounds like you're already doing that anyway and if you put it to use for both learning these languages and concepts as well as getting some experience under your belt that can be referenced in an interview then i think it'll really set you up for success if you want to go jump and do this stuff full-time yeah sounds great good advice dave good luck good luck with your rehab yep or alternatively you could get a frontal lobotomy and just forget everything you've learned and say no screw it oh actually that reminds me yes there is one thing that i

think would be really beneficial in this case and that is that instead of focusing on the tools you're using to do the job try to focus your attention on your customers who are benefiting from what you're building focus on their experience focus on the good that comes from what you've done and not how much work necessarily that you think is unnecessary that it took to to get that product out in the first place so i think if you can focus on that you'll probably become a better developer regardless of the technology you use because you'll be looking at the bigger picture yeah i think that when you said that i feel like i recognize that in in my approach to work too that i really like making things better and solving problems and i also care a lot about

the technology but if i can make things better and solve problems that's that's the higher motivator for me yep so i've been writing a lot of make files and bash and awesome tools like that but it makes life better so it's not too bad and you thought your c-sharp was bad try writing some make files um all right should we talk about the next question yep go for it i will read it how do I suggest firing or replacing an incompetent coworker. I have a coworker who is pretty incompetent technically. Over the past few years that I've been here, he has proved time and time again that he's incapable of learning and really grasping how things work. He is able to accomplish basic feature work, but not capable of making good architecture decisions or explaining why a

given framework should be chosen or solving harder problems. I'm not sure how to describe this, but maybe for example how to build a resilient api client however this person is great at creating slides and presentations and jiras so i think management thinks that they are okay at their job he's also a nice guy so i'm not sure how to say hey you suck at your job that's pretty harsh how do i suggest to someone that he should be replaced oh tough situation hmm what do you think i was just about to ask you the same thing well let's let's look at let's look at the facts here so this engineer is capable of doing basic feature work uh good at presentations creating slides and does good with jira i'm gonna assume jira means that he's a good communicator keeps his

tickets up to date and stays on top of things but is not good at architectural decisions or building things like resilient api clients that's a quote yeah you know let me just be perfectly frank here i don't see a case for firing this person based on what you've described and if you came to me as your manager and shared this story with these facts i would listen respectfully and then i would have to ignore you because these examples are weak and to me you've described an employee who has a mix of basic competency and some skills that are very hard to come by which are you know staying on top of jira and ability to present to management so i mean that those are valuable skills and i i don't know i just i don't see the case here

jameson what do you think yeah i mean it's possible we don't have all the details but from the description it seems like i could see how this could be a frustrating person to work with for a certain kind of personality and people that value certain things like people that really love um kind of cleanliness and and what they believe is good architecture and technical craft and and things like that and maybe this person just doesn't care about that and they just kind of like YOLO out their code and fix their bugs and copy paste things into submission and whatever. You know, I think we could stand to use the word YOLO more.

I really like that word. This is a pretty good generic verb. Oh, yeah. So I can see the frustration, but I agree with you that I don't see anything here that merits firing. I feel like if someone caused pretty consistent damage to the team or to the company and didn't respond to feedback about that then that might be a case for it but just saying like well they just don't write clean enough code like tell me how that affects you did that cause production to go

down did that like quadruple the time it took to implement this feature what what was the cost of that because if the cost is just like there's this part of the code that is a little bit crappier um again it's not ideal but there's always going to be parts of the code that are crappier and And they might just need to have certain kinds of tasks given to them, right? Maybe they need to focus on smaller features and bug fixes and kind of like doing work that has a smaller scope technically, and then also focusing on the communication and Jira stuff. That's fine too, right?

I've worked with people like that, that there's certain skills they have and certain skills they don't. And we just figure out how to work together as a team. There are tasks they don't do because they wouldn't do well at it, just like there are tasks I don't do because I wouldn't do well at them. not everyone has to be the rockstar 10x code crushing sorcerer wizard engineer and you can still build good products without those people there is a cost to writing bad code and there's definitely technical debt and it'll slow things down but i don't know it's it's

hard to say that's enough to fire someone yeah definitely like what's what's the harm it's causing the team and if that harm is great enough and they don't work to correct that then maybe you could you could use that as a reason to fire them but just saying like their functions are too long you go okay now i mean you know in this question it does use the adjective incompetent now if that i mean in and of itself being incompetent at your assigned job is probably grounds for termination right i mean if you cannot complete your tasks it's pretty reasonable that you would be let go but what i'm hearing here is you use the term you use the adjective incompetent but then you also say he is able to accomplish basic feature work maybe it's

like a level of their position like maybe maybe they have a more senior role on the team or something like that it could be i could see that causing a lot of problems the other thing i could see here is once in a while i've encountered people who have they occupy a special place in management's eye like management just seems to really like these people and yet the engineers know that they're not that great right but somehow management has this rosy opinion of them but then on the ground they write code that's not great or they're just barely competent or whatever and it creates this like sense of i'm gonna use the word jealousy in me when i see situations like this because i'm like no this isn't right management must know that you're not the best you know yeah

and i wonder if there's some of that going on and i've personally experienced that where i'm like oh man i don't wonder why management likes this engineer so much they barely can get the job done you know meanwhile i'm over here destroying it you know yeah just tells you a little bit about my inflated ego or your ability to destroy it in a good way i mean say that is the case like what does that mean is it your job to to tell management the truth uh i don't think so i mean if you're you're saying this is just a thing that happens so maybe it's okay that this is happening to you yeah like i i think that in my younger years i felt like that was an error that needed to be corrected um you know but really at the end of the day does it really matter you know if if

management knows the exact truth of just where they are on the pecking order you know yeah yeah it's also i feel like i've seen this situation play out where someone was a total cowboy coder and they management would tap them on the shoulder they would they would ship something really fast that would cause lots of problems down the line but management was happy because they displayed this ability to respond quickly and to ship quickly and then we were kind of left cleaning up after them and dealing with the negative repercussions so maybe that's the situation too where they're kind of they're taking the credit for it and not being their role in the pain that it causes is not being acknowledged i could see that being very frustrating but either

way i think i think you need to quantify the harm this person is causing i mean quantify is probably the wrong word you're not going to like assign a number to it but you want to you want to make clear the harm that they're causing if you actually want to get them fired you should be able to present a case saying here's how the team is worse off with them on it and also here's how it's bad enough that it's worth the pain of firing someone which might be horrible at your organization or it might just be like it causes the team lots of pain to fire someone it's not just like sometimes they write bad code that doesn't feel like enough to me yeah agreed and i think that's maybe the big takeaway is uh first you need to figure out is this person really do they really need to be

terminated for the good of the team sometimes it's easy to be convinced of that until you have to go present the case to someone else and then suddenly the words are coming out and you're like oh this doesn't quite feel right so i would probably write a case with specific examples that someone else could read without all the context that you have and come to the same conclusion and if you can't produce that and then i would say drop it and learn how to work with this person try to figure out their strengths and how they really benefit the team and figure out how to make those strengths work for you in your dynamic and there will be things that you're better at than them and there will be things that they're better at than you and see what you can do with it maybe they can

update your jira tickets for you that would be so cool oh that'd be the dream you just like send a slack message hey i finished this thing okay i'll get that updated for you yeah i don't know what about the ethics of this approach where you you are basically making this secret campaign to get someone fired is that okay should you talk to this person should you talk to your manager should you talk to your manager's manager is that is that an acceptable course of action i guess um this is the kind of thing where you open the box and you can't close it again you know once you go to your manager with a case like this you know they won't ever forget that so you do have to tread cautiously i think and you have to be really really confident that you're

right and so rather than i think just dumping this all on the floor for your manager to look at i would probably start with asking questions like how is so-and-so are they you know a strong performer is you know do they need coaching what can i you know and just try to kind of figure out if management is already clued into this without i think just jumping right in and saying here are 10 reasons why so and so should be fired yeah so that's how i would go into it very very cautiously and lightly before i just jump right into my court case yeah you wouldn't just kick down the door and drop your easel with the foldy paper thing on it and flip through your chart that demonstrates why this person needs to be fired exactly and then what would i go to that person

individually and talk to them this is a hard conversation to have with someone what you're really trying to say is you're pretty good at producing features but you're really not good at these other things unless you have suggestions for them to actually improve i think it would be unproductive to take that kind of a message to someone yeah i think you can present information to your manager and there might be things they don't know there might also be things that you don't know but i feel like if someone came to me and said this person needs to be fired and it wasn't a thing that was already on my mind i would i would i would definitely listen to them but i would also wonder like what is it about this person that means that their opinion of their

teammate is so different from mine maybe i'm aware of some struggles or weaknesses or problems but if I don't already think like is it worth it to have them on the team or not I could see what you mean by treading carefully that saying they need to be fired is a pretty that's that's a pretty heavy thing to say and it's also a pretty painful thing to go through so yeah absolutely I've worked with a handful of people that I felt needed to be fired and in those cases pretty much everyone kind of knew there was something so egregious about their behavior or situation or whatever that that everyone knew like this is real bad and maybe no one wanted to pull the trigger or go through the pain but but it wasn't i haven't ever seen a situation where i felt like someone needed to

be fired and no one knew right people knew so i think if you take dave's advice and kind of explore what is going on already that might be a pretty good signal of how big of a problem the organization sees it as and you can add more data to that but coming in too strong might might undermine your case if you really want them gone yeah let your you present the facts let your manager come to the right conclusion for that person using everything that they know in addition to the facts that you are sharing um it's not really your job to make the judgment call that they need to be terminated or not and uh thankfully because you know that's above your pay grade presumably and it sucks yeah it's a sucky job all right are we done answering the question i think so i think

good luck to you and and try to make this as beneficial of a circumstance as you can for this person and yourself and your manager um i would be very very cautious about just running in here and making a strong case for them to be terminated sure all right dave where can people go if they want advice to their tricky soft skills problems go to softskills.audio and click on ask a question where you can put in your name or not leave it blank if you want and enter a question also there if you've had your question answered you can fill in that same form to let us know how things went if you took our advice or if you did the right thing and rejected our advice we would love to hear about either case if you did the opposite of our advice and it helped you a lot we're

especially interested in that yes yeah all right thank you for listening we'll catch you next week