Soft Skills Engineering - Episode 21: Giving work to interns and dealing with "dead weight" developers

Episode Date: August 8, 2016

In episode 21, Jamison and Dave answer these questions: What kind of work should interns be given? How do you handle developers who are dead weight?

It's another great day on the Soft Skills Engineering podcast because it takes more than writing great code to be a great engineer. I'm your host, Dave Smith. I am your host, Jameson Dance. How are things, Jameson? Things are great. You know, Dave, I actually, we haven't had intro music this whole time. It's been so long. And, oh, actually, we had it that one time. We had the Diane Reams trumpet noises I made with my mouth.

Yeah, the lip trumpet. Yeah, yeah. I think that was way back in episode two. Yep. I wrote us a song. What? Yeah, I wrote us a little song, a soft skills engineering theme song, and I want to play it for you and for the listeners. Oh, my gosh.

Okay. I'm ready. I've got to move my mic closer to the guitar. All right. You can write amazing code. You can learn patterns and frameworks. But that won't help, you know. how to deal with a boss who's a huge jerk for that you need soft skills

soft skills engineering oh yes i love it so much oh thank you the audience just went wild i'm sure they did you know i i quit my job a while ago and i think i found my calling which is a rock star so is playing podcast intro music a soft skill um i think so i mean yeah it's probably a niche that i could specialize in maybe that was so good thank you uh tell us if you hate it it's not gonna be our intro for real probably because what i love it this is the first time i picked up guitar in like a year and a half as you can tell from from my expert playing so yeah you definitely have cordy finger on that c string i can my guitar is strung in colmac actually

so it's it's a little more comfortable on the hands that was so good that i just know there's like 10 000 software engineers driving down the freeway right now and they're all getting in accidents because they took their hands off the wheel to clap and none of them were in teslas they were pumping their fist to the beat oh my gosh that was so good thank you well thank you dave thank james and thank you for sharing your talents with us you're welcome happy to do so uh i want you to share your talents with us though with this question all right i will read our first question uh let's see um so the question is what kind of work should interns be given and a little more detail internships are starting about now uh well that's not really true where i

live anyway it's august this question's a little we we sat on it for a while yeah should new feet should they work on new features should they work on bugs uh what if they're difficult and they might get slow when you might slow down hitting a release date um should it be small and useful throwaway projects or manual testing documentation updating or just let them figure it out on their own what should interns do it's a great question it's a really good question and um they asked about manual testing or documentation updating which to me is like should we give them just the worst like horrible thing that will make them not learn anything and and feel like slaves and the answer is no to that i feel anyways i i think interns are like plants you don't want to leave

them in the dark just like stash them in a corner somewhere because they won't grow you gotta care for them and feed them and water them and then they will bloom into beautiful flowers interns are like plants you should put them in the dirt and pour water on them Yeah. Well, think about why you have interns. I mean, part of it is like you want work done and they're usually cheaper, although some Google interns probably make more than I do. But another part of the reason for internships is to hire people. You get them a chance to experience your company. And if they like it, then you'll be able to hire them on full time. And you already have this relationship with them. So that hopefully makes it easier to sell them on the idea. and if they have spent six months manually testing your crap and then writing documentation like heck no they're not gonna want to work there yeah probably true it sounds horrible so i remember a long time ago i was on a discussion group online and someone was asking this question hey on this version of linux how do i prevent the screensaver from coming on because

we have this display up in our like common area and we have some like product statistics on it and stuff and the screensaver keeps coming on and someone says don't you have interns just make them wiggle the mouse every five minutes yeah that's kind of the joke like oh they'll go fetch your coffee ho ho and like i don't know the the low man on the totem pole but i think that that does both you and them a disservice i think it it doesn't use the the opportunity quite well or quite so well um maybe to talk about this we can talk about i mean what do interns hope to get out of it why why are they interning somewhere resume fodder they want to put google on their resume right yeah i mean who doesn't i just put it on there anyway i've heard that works actually i

just read a blog post about some company that well works in the short term some company was was torpedoed by this guy who just said he worked at google so they trusted him uh and then he like ruined everything but he didn't actually work at google but but the first part of that story it was like a huge success yeah i got this great job yeah yeah it got his foot in the door perfect so i've seen companies do this a couple of different ways uh i think you have too jameson but the one the most famous company is probably joel spolsky's company fog creek software in new york city where they advertise for their internship positions and they specifically call out

that they will be able to work on new product and they take their interns, at least in some occasions, they'll take their interns and put them on a project that's like a brand new product and say, hey, you have one summer, build it and we want to ship it

and sell it when you're done. They did that with the Copilot product which was like a screen sharing service so that you could hop on your friend's computer and help them solve a problem even though you're in different parts of the country which sounds really basic but was pretty revolutionary at the time.

um yeah i think to some extent i think you'll get out of interns what you put into them and if you just throw them on crappy boring tasks that you don't want your air quotes real employees to do then they'll definitely feel it um i know that that's kind of the way things work in some industries like marketing or film or or these there are lots of industries where people are expected to kind of just go through horrible experiences to pay their dues and then they earn their way up to like a real position that actually gets paid yeah yeah yeah exactly first of all pay your interns oh yes that's i think it's pretty standard in software but it might not be everywhere it's not especially outside of software it's very very common which man that opens a whole

can of worms then let's not go there yeah yeah but anyways pay them and and then um hopefully you accepted them as interns because they're smart and capable and they just maybe don't have the experience of like a full-time hire but but they can do stuff they can figure things out and and i think if you ask a lot of them they can step up to it um one company around here in utah called mx they did this apprenticeship program it's basically basically an internship um and and they ended up accepting i think like five or six interns on on a team which is not gigantic and they put them all together on a project um a fairly important project too and and the idea was that they would grow and learn more if they had each other to rely on instead of just being like

stuck as the the person who gets all the crappy work on some team off by themselves and and it also avoids that problem where the work is divided among them instead of um the hard stuff is left for the senior developers and the interns get both the easy and horrible stuff yeah so they're saying that they give them one project they're all together and there's no other developers on the project i think i might be misremembering the details i believe that there's kind of a senior engineer that rotates through the project as an advisor and then i think all of the interns individually get an advisor um i don't think that person rotates so there is some oversight um but it's definitely their responsibility so the way we do it at higher view is we take

interns and we just put them on regular teams with the rest of the engineers and the only thing that's different between the work that we give an intern versus the work we would give another engineer depends on their work hours like sometimes we have interns who say well i can only work three days a week and so we wouldn't give them work that would require them to be like really responsive uh for you know monday through friday like if for example they need to respond to production issues we wouldn't assign a piece of work to that intern if they're going to be out of the office for a couple days every week uh likewise if they're going to be in there every day but they're going to go home at noon you know work like four hours a day or something

but other than that we give them any job uh any task we would give almost any developer we would give to an intern really yeah pretty much including things that touch production more ops and things oh well ops um i would accept that also kind of breaks the rule i said about being available you know our ops people all are uh on the on-call rotation so they interns really can't do that generally i mean i'm sure some could but not these sure the ones we've had that's that's the one place where maybe um if you're touching things that could affect production not not in a way that you're just deploying features but you're you're like if you're doing more of a devops culture so your developers do a lot more provisioning and and and mess with prod that's the

one case where i think a lack of experience could uh that's not a comfortable environment to make mistakes definitely not um yeah so i would be a little more worried about i would have want a little more oversight on interns if they're doing things like that but besides that i think the more responsibility you give them the more that they can grow yeah definitely and we only hire interns that we think have the potential to become full-time engineers with us so that means by extension that they pretty much are trustworthy with our code base and they can make changes and we have process in place to prevent any engineer intern or otherwise from completely tanking production you know yeah another thing i like about um just the idea of interns in general

is i've heard this said about junior developers too but i think that they can be canaries in the coal mine they can kind of reveal bad processes or bad code or things that are hard to understand that senior developers are experienced enough to work around so if it takes like 30 steps to ssh into some server and then set some config flag and then like if your deploy process is a pain experienced senior developers can figure it out and and still deploy and it might not bother them that much right yeah they might they might have some stockholm syndrome going on there but they can still do it and the intern will just be like i i can't even yeah i what is ssh how how to computer and you might say like oh those darn interns they don't know how to do all this stuff

but the fact that it's so complicated to do it should be a warning sign to you yeah or if some chunk of code is just so arcanely complex that only only dave smith the the greatest engineer in all the land can touch it the greatest ssh oh wait no you're talking code yeah this is more this is more along the lines of my code is art yeah a few episodes ago dave has created just this fantastic piece of art oh yeah that as part of the art work uh it's impossible to change and fragile look you need to understand the third time you call this function it's going to seg fault and that's this by design yeah that represents how in life sometimes we go through the same experience and react differently um because we ourselves have changed because your mood is

like a global variable yeah exactly yeah that can be changed by the other thread yeah and the intern's gonna be like how how to computer so i think if you create an environment where interns can be productive it probably means you have a good test coverage some some decent documentation you have a way to um uh spin people up on the dev team quickly and easily and i think those are all things that will pay dividends for the rest of your team too not just the interns i really like that concept of treating interns like a canary in the coal mine not every team gets to have new people join all the time and so they're not often accustomed to new perspectives but if you have a well-designed organization and process and good code base interns will thrive and

if you don't they will fail and that's just awesome visibility yeah i know that some projects have the readme that gets updated once every time a new developer joins like read the readme follow it and your job is to find out where it's wrong and then fix it so that the next time it's only six months out of date instead of a year out of date uh so we actually do that yeah no we we do that too and it's gotten a lot better it's it's been less out of date every time one other thing to take into consideration is that interns are often time limited, both, like I mentioned earlier, in terms of how many hours they can put in during the week, and maybe what times during the week, but also in terms of just total amount of time they're going to spend with your team.

You know, some interns come in at the beginning of the summer, and they leave before the next school year begins, like if, say, if they're in college. And so it's really important to pick work that they can either A, finish in that time frame, or B, hand off successfully. And sometimes that means that maybe some of your deeper design problems that need a lot of input and have long repercussions probably shouldn't belong to the intern and we have actually done that on my team even though we pride ourselves on letting the interns be a full participant we certainly do limit the amount of work or the nature of the work that they can get based on their time constraints yeah that makes sense to me but we actually take it so seriously that one of our interns

was uh one of our team leads for a while and he just rotated in did the job for several months did fine it was great oh that's amazing what does that say about management even a college kid can do it i love that story we actually had to see uh one of our interns was the ceo for a while it was great it was great met with the board he uh raised some money he got his golden parachute when the semester started he went back to school with a million bucks in his pocket even though the company sunk classic ceo move oh those interns and he still got us all coffee we gave him a hard time oh my gosh the the weirdest part was when he had to fire some guy

but but had to get him coffee first because he was the intern can i bring you some coffee you're fired well that's all i have on this one question answered answered all right uh i will read the next one okay how do you handle developers who are dead weight from an anonymous listener i have a question about how you handle developers who are dead weight my ex-manager recently turned developer, was a very cool manager, but is a not so great developer. We are both on the same team in a new project. What started as me helping him to ramp back up into the JavaScript ES 2016 world has turned into me doing two people's work because he just doesn't ever seem to grasp the concepts and needs constant handholding. I feel this is a particularly sticky situation because he has

always had my back from his managerial position. Any advice from the soft skills engineering crew? if he's literally dead you should call a coroner that's number one just a soft skill yeah just stab him right in the back just betray him it's a cutthroat world out there you can't get to the top without you can't you can't make omelets without stabbing someone in the back yeah isn't that how the metaphor yep and you stab them in the soft parts hence soft skills oh this is a really tough situation actually yeah here we have a pair of people who have worked successfully but the nature of the relationship changed and now they're not working successfully that's basically what happened here right yeah it seems like it

the people didn't change but their responsibilities changed yeah while we were talking about this we had a couple questions and one is um is this his first time as a developer or is he uh like returning to development because i think that would make a difference yeah like did he write some mean cobalt back in the day and yeah yeah versus i'm brand new to this whole development scene yeah is he rolling up his sleeves to show you young whippersnappers some some of his tricks that he learned back in the day i'm guessing not based on how it's wording let's assume that he is this is his first foray into development really that seems like an unlikely situation to me though i feel like it would most manager to developer for the first time like because how

would how would he become a manager that's an interesting question okay let's not make that assumption okay i mean you can make it i made it and unmade it okay that was easy that was good assumptions are easy to break here uh so jameson have you ever been in a situation actually i know you have um where you have someone who is not pulling their weight and you need to talk to them like a peer who's not pulling their weight and you feel like you should go talk to them about it um yeah i i have uh this was a quite a while ago um and it was horribly awkward yeah it was horrible and it ended up with them not working there anymore so i don't i don't know that there's much like advice to impart from that it was it was

more like they weren't a great fit and they kept not being a great fit um go ahead yeah i just i I've only had, I think, one experience in the last 15 years where I worked with someone who I felt so strongly wasn't carrying their weight that I actually wanted to directly solve the problem. And even then, I felt it was just too awkward for me to go and tell them. Yeah. I just didn't do it. I didn't talk to them about it. It's hard. And in this case, the situation that our listener is describing here, it seems even harder.

Because of their relationship. Yeah, like they had a good thing going. And as a manager, he totally took care of him. yeah and now he's like hey i need to tell you you suck at your job yeah but on the other hand james and i were talking about this before the show started it's like this guy had his back they have a good relationship so that should be a leg up especially since they had management uh a manager relationship right so this manager probably knows a lot of things about you that a lot of people don't has some secrets and you've trusted him so i wonder if that would actually help you to have

this kind of a hard conversation it also seems like if you have management experience part part of what i imagined you would have done is try and help people improve and get better at their job yep and so you might have some empathy for someone in the in that role saying like hey you need you need to get better things aren't going great because i imagine that's something you've done before yeah the manager and in fact he's probably keenly aware if he's been a manager there's a really good chance he knows what performance problems look like because he's had he's been responsible for them in the past and so he probably already knows and he's wondering probably wondering how you're responding to this whole thing this sounds like a situation where you need

to have a conversation yeah i i wonder if he's in the the the situation where he kind of knows something's going on and getting it out in the open would make things better because it feels pretty terrible to to kind of feel like you're failing and and either everyone's talking about it behind your back or they're just kind of silently resenting you but getting it out in the open could be helpful i think um one way to broach that subject is to have just to sit down one-on-one maybe you already have times when you can sit down and be alone and just ask how do you feel about being a developer so far you know super non non like directional that you're not leading the person to answer the question that way and just see if it comes up it just it very

well might yeah in my experience uh that question always means i think there's a problem are you aware of it what if what if it's just a casual lunch conversation and you're like hey you've been you're a couple months into your new role how's it going like what do you like it yeah i Do you like it is a much better way to say it. Yeah, that's better than saying, tell me how you feel about your performance so far. Like, oh, it felt great until you asked me that question. So again, there's a lot of context we don't have here.

If he has been a developer in the past, I think some of those skills can atrophy. And especially if he doesn't know anything about the code base, there's just a warm-up period or a learning curve i mean if if he was a new hire you would have some patience about he needs to figure out what the code base is and and what's going on and what our patterns are um so if if he's new to the code base and also has been out of development for a while and so isn't uh kind of up to speed you mentioned with es 2016 um it seems like you should be looking for progress not just absolute velocity right now and if you're not seeing any

progress that's a different problem then um he's he's improving but just not as quickly as i would like it's a good point another thing to do uh is to make sure that you're characterizing this situation correctly is it possible that this person isn't just bad or slow but rather has a different style than you maybe they go about solving problems more deliberately and thinking through things in like a depth first way instead of maybe you're like a breadth first style and so um you know maybe they just need to work through things in a different order than you're used to and so you're then characterizing them as slow yeah that's true however the question specifically says that he's uh what does he say um helping ramp back up okay he doesn't seem to ever grasp

the concepts it needs constant hand-holding so it's like if you're repeatedly telling this person the same thing over and over like yes the semicolon does have to go at the end of the line you know like maybe maybe this isn't a mischaracterization maybe it really is just they're just not getting it yeah and there's also some amount of uh i i can detect some kind of stress or pressure on this person because he says or he or she says uh i'm doing two two people's worth of work. And I wonder if there's some kind of deadline pressure or just if they feel like they're being held responsible for the progress of the project when they don't have a team that can work as effectively as they would like to. Yep. And that probably means it's above your

pay grade to deal with the problem. If your company is expecting you to deliver at a velocity of two developers, but you really only have one capable ramp developer, there's an expectations problem that maybe needs to be managed at a level higher than what you're talking about here. Yeah. So this gets to, I have a philosophical dilemma to propose to you. I have talked to people who feel like if you are going to kind of, I don't know, not complain, but say something that could possibly negatively affect a person to a boss, you kind of owe it to them to talk to them in person first so how do you how do you feel about that does he does does he or she have the responsibility to say like hey you need to step up i'm feeling all stressed out to this person

no okay in my opinion no because what so i think i heard this great definition of gossip the other day that said gossip is when you're talking to a person about a problem that they cannot solve oh i like that and by talking to the person who is the problem they can solve it now if the situation was reversed and you had a bad boss and you were talking to your peer about the boss's problems that would be that that would fit the definition and that would not be productive um but in this case yeah i think i don't think there's any problem going to the person before you go to their boss now do you owe it to them i don't think so i think in the case of a performance problem it actually is your manager's job to work on that man i'm just thinking about that

definition it's great yeah i like that one that was compliments of dave ramsey in case you're curious ah there's your source a fellow dave yes of course he would be smart of course with a name like dave yeah i i think the question of how do i deal with people who are dead weight in in the like abstract is kind of a quite a bit different from this specific question because there are all these complicating factors about your relationship and how roles have changed and stuff this is like a this is like the the hard mode version of this question it really is um you want to talk about the easy mode yeah i mean the easy mode is uh well first of all um was this a hiring problem like should this person not have been hired did did you feel like they would have been great

and it turns out that they just aren't as good as you thought they were when they were hired um and and if that's the case then i mean no man i feel just soulless saying this but um but in my experience there are some training and mentoring can help people and you definitely want to make sure people are in an environment where they can succeed and when they where they feel supported but but if you don't see someone improving even with all the support and help that you're giving them uh it's it's not your responsibility to like rehabilitate people or or uh transform their lives you know yeah at some at some point it's their responsibility to at least initiate that process yeah so so the i

guess the doomsday like ultimate solution is just to to let them go um and that's a con oh go ahead well what if you're not in a position to do that yeah so so that's what i was going to say that's where talking to your manager and raising the problem and just saying i it's they're not keeping up and i don't imagine they ever will um there are all kinds of other things going on uh you might not be aware of some stuff yep big big big point yeah so but but raising that to your manager is like one thing that you could do with the knowledge that hey this might end up with this person getting laid off so that's like a pretty uh a pretty weighty step to take i think one time one thing i've done in the past is i i will go to my manager and i will say i do not want to name

any names here because i want to protect the innocent but i want to share with you some behaviors that i've observed and i want you to help me judge whether these are significant enough to bring to your attention and actually identify the person so that they can get help improving or be moved out of the organization um and then you can go through the situation and the manager can say no no you're actually overreacting or they can say these are real concerns i need to know who it is so i can help the situation or they'll say oh are you talking about fred you know yeah and it's like obvious to them and maybe they're already working with fred you know that's actually pretty common i now i've been in management now for coming on a couple years and what i have

discovered is that oftentimes management knows a lot more about people's individual circumstances than their peers realize especially when there's things going on in their personal lives that are struggle and um and you just can't share those things you just can't be like yeah so and so is going through a hard time at home like that's just not something i can share so um you know you you have to temper everything you know as a manager against uh what you're hearing from their peers and so yeah sharing information can't hurt but you do have to be delicate about it and that's one way to try sure that makes sense it i mean i i mentioned mentoring and and providing an environment where people can succeed and it it is worth it to examine your own behavior and say like

have i have i done enough to help this person yeah definitely i've definitely worked at places where i've been guilty of just throwing people in the deep end and expecting them to perform at the level of someone who is both a talented developer and who's experienced and comfortable in the code base and technology that we were using and that's kind of unfair i mean people take time to ramp up they take time to learn things and and people take time to improve so they're i mean it's hard to know without knowing the exact situation but there's a lot that you as an individual can do to help people out totally agree all right that was a hard one yeah it was questions sort of answered good luck tell us tell us what happens yeah we would like

if you are comfortable yeah um yeah this seems like it could have an interesting conclusion stay tuned for the exciting conclusion speaking of exciting conclusions we have an announcement to make and i forgot to tell dave about it beforehand so i'm just gonna spring it on him is it that we got music uh no i wrote another song it's an exit song not an intro song no it's our website our website is live it's at softskills.audio i think did i even say that right yeah you did softskills.audio yeah uh you can tell that um we are professional web developers by the way that there is words and two colors three colors that i can see actually there's black and white and also some blue and some gray yeah and some gray that's true never forget about

gray it's a quadro wait quadrochromatic website it's kind of the new design thing yeah it's it's the next iteration of flat design it's non-skeuomorphic quadrochromatic uh i think the term is brutalist actually you laugh that's a real thing oh no no it is yeah it's actually really interesting if you google brutalist design brutalist web design uh so check that out it has some show notes. It has links to the episodes. If you're listening, there's probably not a lot that you haven't seen already, but it's an easy way to share the podcast with people before we had to just share tweets, but now we can point people to URLs for episodes. So that's exciting for us. Yeah. Yeah. It's really cool. Um, it's a pretty revolutionary website. Uh, yeah, I think

you'll be seeing a lot of medium think pieces about the tech we've used here did you hear about HTML where can people go if they would like to ask us a question and have us answer it on the air yeah they can go to our

twitter we are soft skills eng and if you can just send us a direct message or a tweet we will put it in our queue and get to it and answer your question and we would love to many of you have done this and we're sorry that we can't get to all of your questions but

thank you for them alright I think we're done talk to you next week cue up our exit music I put my guitar down hang on oh no I forgot I play Stairway to Heaven it's been too long there it is i have not tried to play that song in like eight years uh you can tell how good i am

it's impressive you got a few of the notes out there several of those notes were correct that's a pretty good success rate i'd say all right see y'all later thanks bye