Soft Skills Engineering - Episode 28: How Long Should I Stay At My Job and How Do I Help Junior Developers Improve

Episode Date: September 26, 2016

In episode 28, Jamison and Dave answer these questions: How long should I stay before I quit my job? Two to three years seems fairly normal. Dave sees people with less than 12 months regularly. Staying at a job means you experience things you wouldn’t if you hopped around a lot. It is much easier to see the hype cycle play out if you stick around. You get to see the outcome of your own decisions. Quitting usually == raise. Chronic job hopping might result in a reputation of not sticking with things. Dave thinks you should quit your first job after 18 months because of the Monty Hall problem How do you encourage junior developers to improve? We assume that these junior developers really want to improve. Make it clear that people get stuck and struggle, and that is normal. Make it clear that you don’t want them to get too stuck. Make it OK to ask questions. People generally live up or down to your expectations, so help them feel trusted and that you expect they will be great. Make the outcome of their work clear.

It takes more than great code to be a great engineer. This is Soft Skills Engineering. Today is episode 28. I'm your host, Dave Smith. I am your other host, Jameson Dance. How are you doing, Dave? Pretty much terrific. How are you? Except for like your Achilles heel, which is your weak point. That's the only part that's not... Why is it not completely terrific? The Achilles heel. You see, when I was a young lad, I was dipped in the river Styx.

which as you know grants immortality but i was being held by my ankle sure hence weren't we all an experience we can all relate to uh no actually i have had orthotics inserted into my shoes this week so i do actually have weak ankles and they're both weak not just one okay now you know a little bit about dave's physiology i'm so sorry that's that's great now we're we're all improved from that uh should we start off with our first question oh no we shouldn't uh you should tell a joke that was the best setup ever that's called the the pump fake is that a sports metaphor yeah it is i actually know that one that's basketball right sure you can do it in football too i don't play any sports and i still

know these things so i hope our listeners do too you're such a renaissance man well i i am widely read i know things about football the most popular televised thing to ever exist so you know this is a question and answer show and i just wanted to say you can't say question without quest and i think that's a great reminder for all of us and it's not even a joke it's real oh let your quest be guided by questions so we're on a quest for knowledge. Let's proceed. Okay. Can you read our first question, Jameson? Yes. From an anonymous listener, how long should I stay before I quit my job? When is it okay to leave your company and go to a new job? Is there a socially accepted amount of time where if you leave earlier, people will

think you're a jerk? Or what are other things to look at to tell if people will feel like you've put in your dues and aren't being unusually rude or out of the ordinary? So a lot of people don't know this but i actually have 30 stopwatches taped to the underside of my desk which i started for each team member when they arrived on the job and i am watching them all is this the jerk stopwatch yeah because when someone leaves i'm like that was less than four million seconds so there's your answer how long is four million seconds i don't know four million seconds to years yeah that's uh not very long okay yeah so they are a jerk then if they leave before four million seconds there's a lot to this question and like everything

there's a balance and you could be too far on one end or too far on the other i think i will say every time i have quit a job i have ended up being so glad not that it was some horrible experience or anything but there's always been a reason why i've quit and leaving made it much easier to realize that i the risk and the cost was pretty low really and and the benefits outweighed the cost so you can definitely stay too long at a job i think where you you stagnate and you're just passing up a lot of great opportunities yeah how so you you said that the risk wasn't as great as you thought it was but you only discovered that after quitting right i mean so when i've quit i've always been very comfortable where i was i felt like i had good relationships and

good friendships with people i felt like i knew the code base really well and the product really well and i was like known as someone who could do a great job and then leaving you kind of lose all that and and you get to be the new person again and it's kind of scary you have to like prove yourself again and kind of figure things out and jump into a new code base and there's just a lot of unknowns yeah uh and and like classic imposter syndrome i just assume it's all been a fluke so far and that this time yeah your luck's gonna this time they'll find out yeah exactly and yet they never have the streak continues except that last job where they were like hey everyone we just found out jameson's an imposter well that only happened after i quit so it's fine

so that's that's an argument for uh for quitting but after how long just you gotta you have a bad day you're gone you're like you wake up one morning and you start hearing rumors that people might know you're an imposter your first bad day and you quit i so i think uh that like two or three years is kind of the normal amount of time to stay at a place and and uh and then quit and and not have anything bad happen yeah assuming it's like a place that you like and there's not any i mean if there are horrible things going on you shouldn't just stay two two years or three years so it doesn't look bad in your resume right right but like to stay had a good job that that you enjoy uh i feel like that's kind of a normal amount of time i'd say

that's a good minimum yeah it also well it also just so happens to be the amount of time i've stayed at every job how convenient that i would recommend that as the right answer i'm sure that's just a coincidence yeah just a coincidence i think you've you've had a little bit of a longer tenure at a few jobs than i have why don't i run down my experience so that people can know the bias that i'm bringing to the show today sure i know your bias so my first job out of college i was there for a year and a half my next job i was at for seven years with that that's not counting a six-month stint where i left the job and went to a startup and then came back to that same job but it was seven years total and then um i'm at my next job now and i'm about to i'm about

i'm about to my five-year mark so that's my bias i i used to think that there was like this stigma that followed people around um if they quit a job too frequently and i have done so much hiring over the last five to seven years and i have seen that tons of people have left jobs one to two years to three years like there is there is no problem it seems in the industry for developers who have left after just a year or two have you personally hired those people um i mean no i only hire people who have a 10 year a 10 year tenure at their last job yeah i don't know do you feel like it affected you or just it you just saw it a lot but you personally wouldn't want to hire or you would be you'd see it as a negative thing or you just

ended up not caring that much my internal like little neural network that processes resumes when i see like four or five jobs in a row that are right around the 12 month mark i start to get tingles like oh that's a problem right like that's when i think there's a red flag that needs to be explained but um beyond that like if you've had four or five jobs in a row where you're there for two years to three years i don't even i don't even blink sure and i have hired those people and i actually can't remember if i've hired anyone with with a more frequent job hopping on their resume i don't i don't think i don't think i've even remembered so i probably have so we've kind of given arguments for why this isn't that bad uh kind of within within what we

have defined to be a reasonable amount of time what are some arguments against hopping jobs this frequently i think that by staying at a job for a long time you will experience things that you otherwise won't experience like for example some decisions that engineers make the full repercussions of those decisions don't manifest for a year or two or three you know and it's like hey i made a technology choice and you may not fully appreciate the repercussions of that choice for two years you know it may take that long sure have you ever had that experience well no you haven't 100 no 100 yes i have and it's eye-opening yeah uh it's it's kind of where like the the scales fall from your eyes about the hype around every new technology and you realize like wait a

minute nothing can save me from crappy code no matter what the technology is i can still screw it up you know the you know the you know the gartner hype cycle thing uh where it's like the trough of disillusionment and all that yeah i think every single technology i've used for sufficiently long ends with just i hate this technology you know what i'm saying like well Well, but there's something after the trough, right? The plateau of productivity. Do you want to describe this thing for people that don't know about it? Google the Gartner hype cycle.

But basically, it's a curve that starts really low. It shoots straight up really tall. So that's when everyone gets excited about the tech, right? That's the hype. And I can't remember what that's called. But basically, everyone's super excited. No one even cares whether it's really good because it's new, right? That's called the peak of inflated expectations.

and then that immediately falls down to the trough of disillusionment and then that grows about halfway back up along the slope of enlightenment and then levels out of the plateau of productivity it's such a good metaphor i feel like i could name several technologies at every point in that cycle right now i yeah and you could put them on the graph right like yeah yeah me too but i think that there's more beyond that graph where you've been using this technology now for years and you're like i think the plateau of productivity like i'm not i'm not even really sure what the y-axis is on this graph but but i like at some point you're like okay i am completely neutral about this technology i understand all of its weaknesses i understand

all of its positive characteristics and i just don't freaking care you know like after you've used the technology for like four or five years you know that's when you start seeing the matrix so so your point is if you hop around jobs all the time you get the opportunity to try new hype things and you never get to see what the actual trade-offs are long term yeah and and more importantly your own decisions like i chose to architect this system this way and now i'm seeing the problems with that the problems that were not apparent on day one or month one but are painfully obvious on year one and year two so it's kind of like i mean there will be different code bases and different problems different products if you hop around say you go to four different jobs in four

years but to some extent you're getting similar experience four times whereas if you stay at one job for four years theoretically there could be a depth of experience you wouldn't get yeah i think that could apply to team issues as well working with the same group of people and seeing how it evolves and changes as people leave and join um that's stuff that you really only see if you if you stick around for a while yeah like let's say you have a real personality conflict with someone and if you stick around for a few years you may learn how to resolve it and you may go from being conflicted with this person to being like a good friend of this person but you can't do that if you bail out in a year yeah so that's kind of cool on the other hand

100 the easiest way to get a raise is by quitting and getting a different job right now anyways kind of the default is you quit you get a different job you usually get some kind of raise yeah i i feel like we've kind of arrived at what we think to be a happy answer to this where in our minds there's this idea of like two to three years that might not actually be present in the industry, but for sure there, so there might be a reputation cost if you hop around too much and it might make it harder to get hired. But for sure there is an effect on the kind of experience and how you develop as a software developer. Yeah. And I want to go back to the question here because one of the things the

listener asks is, is there a socially accepted amount of time where if you leave earlier, people will think you're a jerk? And I think the listener is referring to your former co-workers. you know and and i just want to say that i don't think there's any amount of time where if you leave your former co-workers will think you're a jerk i just don't think they will care that much right like especially yeah like the shorter amount of time you're there it's like hey well in other words let me put this another way i think the company you're going to go to will care a lot more about why you were there for such a short amount of time compared to the company that you're leaving like if you show up at a team and you only work there

for three months and then you leave how much impact could you really have had anyway you know you take off and it's like you can't leave your team with that big of a bag you know well it's not just leaving them with a bag it's it's leaving them with the idea that you might not stick around for for hard things yeah but you already left oh you're me yeah i know right about your reputation that you leave yeah you're gonna you're gonna see those people again um at some point probably some through some combination of jobs or community things or whatever like yeah good point so i i think that can affect you a little bit um i feel like i i know people uh that are that are talented and competent and have just hopped around so much that i would be wary of working with them because

um i they might leave me in a lurch yeah that is a good point although i think yeah you're You're probably right. It may impact your future employability with those same people. Yeah. I mean, it's not like you're not going to be able to get a job. Yeah. This person would be fine. I also think it depends a lot on the circumstances under which you're leaving.

Let's say you had a big traumatic life experience, maybe a death in the family, or maybe a parent is sick and you just need to go. I think people are really understanding when that happens. Like, I've only been on this job for four or five months. I've got to go. or or if it's just horrible or like the company is tanking or there's some kind of like abusive behavior i mean there are for sure reasons why you should absolutely leave right away but but those reasons generally it's like the saying uh if if you encounter a jerk in the day that person might be a jerk if you if everyone you encounter is a jerk then you might be a jerk yeah like if

if you have four or five experiences in a row where they're like emergency dire reasons why you need to quit after a couple months there might be some kind of behavior that you are engaging in that has an effect on that there might not too i mean you can flip a coin a hundred times and get a hundred heads in a row but that happens i've never done that neither have i i would suspect i would suspect the coin at that point so i think the magic number is about two years where people just won't really raise an eyebrow you know after two years you take off there's just no there's really no magic or sorry that is like the magic number um and then also on the other hand if you stay for 10 years people might wonder why did you stay in that job for so long you know um

have you ever seen have you ever met anyone like that uh yeah i mean it's usually just people get really comfortable and they're they're fine doing doing what they're doing which is great i mean if you've achieved a spot where you're happy and comfortable that seems valuable i do think that that level of comfort can hurt your chances for your next job though sometimes yeah i have talked to one person in part of an interview process who stayed for 10 years and it was because they got to do different things pretty regularly it wasn't it wasn't they found their comfortable niche and just cranked out their like yeah like 10 year old code it was that every couple years they got to experiment and try new things. And the business really trusted them to kind of evolve and still

stay there. That sounds pretty solid. So another piece of advice I have for people who are just starting out, I think everyone should quit their first job before two years. For your first job, your first air quotes, real programming job. Why is that? Well, it's basically the Monty Hall problem. Have you ever heard the Monty Hall problem, Jameson? I have, and it makes me feel stupid every time i hear it because i have a hard time comprehending it yeah it is a weird one but think about it in terms of choosing i mean basically lots of things in the world make me feel stupid i live i live a life full of fear and and just like i don't know awe at all the shiny things all around me so that's not a it's not an uncommon experience you can often find jameson

standing outside just looking up into the sky it's it's not just cowering cowering as a car drives by like magic how how does magic car work so yeah the money the reason i compare your first job to the monty hall problem is let's say there's a hundred jobs out there that are available to you as a developer just starting out and you choose one of them what are the chances that you chose the best one like one in a hundred right so in other words there's a 99 chance that you did not choose the best job available to you so you should change and you should find a different one and now there's only a 98 chance that you are gonna find or rather that you've got the worst one so your odds get a little bit better every time you change the job change jobs and you take with you all the

stuff you learned from your first job when you're weeding down or narrowing down the field for your second job and um every time you do it you uh you you learn a lot and so i think i think your first job you just there's just such a low chance that you chose that perfect job that you should you should probably quit even if it's not that bad um and if it's bad you should definitely quit that's a great point it's kind of like uh you hear this with software estimates right when you're estimating how long something's going to take that's the least you'll ever know about it and when you're finding your first job that's the least you'll ever know about the software industry and also like what you enjoy yeah exactly that's a cool idea so here's the thing

though quitting your first job is really hard and i stayed at my first job for a year and a half and i actually really didn't like it that much and so i started looking for a second job and i felt so guilty leaving that first job um i felt like i had stabbed my team in the back and like they all were going to hate me for the rest of their life and would you like to know how long that guilt lasted after i started my new job i would love to know about a day my new job was so great um that i just completely forgot and guess what those guys that i left that team they were fine no problem they didn't feel like they were stabbed in the back and that company and that product and everything was just fine without me

sure all right i believe we have answered this question question answered you're welcome anonymous listener quit your job okay all right do you want to read our second question dave yeah sure this comes from listener eric woolley he says how do you encourage junior developers to leave their comfort zone how fast or how far do you push them you push them until they crack to the breaking point and beyond 100 feet if if the wheels on your office chair are just Really well-lubricated. To me, this gets at kind of the care and feeding of junior developers and how you create an environment where they can succeed.

Maybe we should start off by making some assumptions about the kinds of developers that these people are. I think the best characteristic of a junior developer is um wanting to improve and sometimes people call it passion but it's it's like just kind of this uh voracious appetite for knowledge and the right way to do things and and how to accomplish harder tasks so i'm assuming that you have hired to some degree for that characteristic yeah if if your junior developers are kind of not very engaged or interested then i think that's a really hard problem and i don't really know the solution besides the cop-out answer of like don't get in

that situation the core it's the corollary to our go-to answer of quit your job is you fire the junior developer no you don't fire them because that's hard you go back in time and avoid hiring them in the first place much that's much easier yes with some employment laws that actually might be easier. That's true. So I think one thing you can do is help them understand and normalize the idea of getting stuck. Um, I think junior developers can look at senior developers and assume they know everything and they see a problem and then immediately in their minds blooms this complete solution that all they do is just like think and then type out the thing that they thought and that's not how programming works look the only the only limit to a senior

developer is their typing speed that's the only thing slowing them down that's why they spend so much time tweaking their editor because that directly correlates to more productivity we've unlocked the secrets yeah so so if you can help them understand like hey i get stuck too i might get stuck on different problems but this this um experience of tackling a problem and not knowing the next step and kind of banging your head against it to try and figure it out that's normal and that's expected and that happens at every level um just the kinds of problems you you encounter it and react to in this way will change but i think normalizing that and trying to eliminate the shame that they might they might feel about not being able to immediately solve

something is uh one helpful approach yeah and i and i love the comment of normalizing that because i have seen some of the smartest people i know who are pretty junior but really really really smart like just blow me away smart get stuck sometimes for days on a programming problem and it's not that they don't know their programming language it's not that they are struggling with the syntax it's that they just don't know how to proceed with this problem you know and that's totally normal and so helping them understand that that's normal and to not and to recognize it when it happens and then ask for help is really important yeah that's that's the second part there's some expectation that you should be able to get stuck and sometimes you

unstuck unstick sometimes you unstick yourself but there's also some kind of uh i don't know what the threshold is some time limit where if you've been stuck for longer than this period of time. You don't want to just disappear into a cave of shame. And this still happens to me sometimes where I'm like, they're going to know that I don't know how to do this. I better just disappear and try harder to figure it out by myself. And at some point, the cost of interrupting people to ask questions becomes so much lower than the cost of you just churning your wheels without really knowing where to go. So you could maybe explicitly establish a time limit,

say like if you're stuck for longer than a day, just tap somebody on the shoulder. I don't know what the time limit is, but so that's the other half. You normalize the idea of getting stuck, but you also make sure they're not just gonna disappear and feel awful about themselves. Yeah.

All right, what else can we do? I think that making sure junior developers know that asking questions is both allowed and encouraged is a good thing to help them get out of their comfort zone and to make progress. Because sometimes people think, well, if I ask a question, I'm going to look stupid.

Yeah, because I clearly don't know the thing I'm asking about. And to be quite frank, sometimes you will ask a question that has an obvious answer. And sometimes developers will think like, gosh, why did they ask this question? But that will be, generally speaking, much more rare.

And you know what? The worst case scenario is that your team members will figure out that you actually are junior you know yeah yeah that's that's a great point i think asking good questions is a skill and we don't talk about it explicitly as a skill but you develop that skill by doing it and after a while you kind of get a feel for the kinds of questions that um are easily googleable and you also get a feel for what the expectation of like the effort you put in beforehand before asking is uh but you you never get that feel if you just don't ask questions if you're scared of looking stupid

so as someone who's like responsible for mentoring people who are more junior or as a leader of a team with with developers that are junior i think it's important to say out loud hey on this team we welcome questions and i personally welcome your questions so please bring them and i promise not to make you feel stupid if you ask a question that you think might be, you know, beneath you or might appear to be beneath you. Yeah. Yeah. That, that seems like a pretty big key is when you make someone feel stupid, they'll just totally shut down and then they're much more likely to get stuck. You, you might encounter a problem where you encourage too many questions and then it's, it's interruption and you have a hard time getting stuff done. And there are approaches you can take

to solve that, but I would much rather have that problem than someone who just, uh, is silently struggling. And then like six months later they get fired cause they didn't get anything done, you know? So maybe you can talk about that. What can you do if you feel like you've created an environment where people are comfortable asking questions, but you want to make sure it's balanced by your own productivity? You could maybe set aside dedicated time blocks on your schedule where it's like, this is office hours question time. Um, I've actually heard of companies who have like senior engineers who are required to set aside office hours each week. And it's like, this is a time when anyone in the company or anyone on the team can come in and just sit down

and have my attention and ask me whatever they want. And I think Brad green talked about that. Didn't you mention that at Google or something? I don't know if Google does it or not, but I remember he said something about office hours. Yeah. That sounds, that sounds familiar. And I know for a fact that amazon does that as well with like their principal engineers sure google is probably big enough that you could say anything and then be like yeah google does yeah they do that they have like 40 000 engineers or something exactly yeah i like that and and encouraging that encourages people to batch up their questions so you don't get tapped on the shoulder as much which i mean there there is a cost to answering questions right the cost is it interrupts you

and it kind of throws you off your game. But you really have to invest time in junior developers. If you just hire them, throw them in the fire, some of them will not succeed that could have succeeded if you gave them more support. And that costs you time and money. And as someone who's a little more senior on your team, I think you have to make sure that people know

you want to answer their questions. One time I got a piece of feedback from one of my team members that said, you know, like Dave has a lot of good answers to questions, but sometimes I feel like I'm bothering him. Like he kind of gives off the air of being a little bit annoyed when I ask him a question because he's busy, right?

And I realized I was like, oh crap, I'm gonna have to like, I never wanted to give off that impression, but I did. And it made me realize that I'm going to have to put in like an actual acute effort to tell people, thank you for asking me this question. I'm glad you asked if I want them to keep asking. I guess I just got to change my habit

of calling them jerk faces every time somebody interrupts me to ask a question. Another question, jerk face? Listen here, you little punk. I'll give you the answer. Yeah. So another thing...

If you pass this test. Another thing that I like to do is keep an eye out for projects that developers, more junior developers can do to level up their skills. So for example, I've had some people on my team

and i see a need and i'm like gosh it would be great if our like if our dashboard our internal engineering dashboard did x and i'll see a developer and i'll be like hey in your spare time would you mind like seeing if you could add this feature to our dashboard that would be awesome and i knew it was going to be a stretch because it was something it was using a technology they weren't familiar with and it was a uh you know it was all new for them but um i also knew it's not on the critical path there wasn't like a customer demand and it wasn't something that had to ship like next week so they could take as long as they wanted on it and they did a great job and um i'm always on the lookout for stuff like that for my junior people because it gives them

a chance to basically level up in an in a very low pressure environment where they can explore things and take their time yeah that makes a lot of sense what do you think about the idea of you can sometimes uh i feel like you can baby junior engineers too much where you you put them on things that aren't really that important yeah difficult yeah that's true and it seems like you you kind of want to bounce that by actually giving them solid stuff to to yeah yeah no i think it's a work on you're absolutely right and the thing i was talking about would be in addition to like their regular work right you'd be like hey i want you to branch out and try this new technology in the meantime you can't slouch on your main commitments to deliver stuff for

for our customers you know yeah i just feel like someone said this who is smart and i can't remember their name but people generally live up or down to your expectations and again it has to be reasonable you you can't say to every junior like write me a compiler that turns this javascript into x86 some of them you probably could um but if you just give them a project and you say like i think this is within your capabilities it's going to stretch you and it's important to the company but i think you can totally do it uh people can figure out a lot of stuff when they feel um the right combination of like empowered and and uh trusted but also not yeah and challenged but not overwhelmed yeah yeah it's a delicate balance i think one thing you can do to help

with that is to describe the benefit or the outcomes of their work. Like, hey, when you do this, our company is going to benefit in this great way, or your teammates are going to benefit in this great way, or our customers are going to have it so much easier when X event arrives, you know, tell them the outcomes, because sometimes it's not obvious, especially when you're junior, you're new on the team, you're looking around, there's just this mountain of product around you. And you're just exploring this small, you know, edge of the surface. And, And so it's often not clear exactly what the benefits of your work are. Yeah.

I mean, that's great advice for everybody, but more senior developers, I think, have more skill at figuring out where their work fits in the context of a larger engineering organization. And juniors might feel like you just shut them in the corner when maybe the thing that you gave them really is important and people are going to see it, but just for whatever reason, they don't know that. So, yeah, that's a great answer. well question answered question period answered period why wasn't there a period after question no there was question period answered period that was dramatic punctuation i think i'm doing it right gosh yeah i think you are doing it right i think my brain just shut right down not an english major once again demonstrate i'm not what you call a good worder well dave where can people hear more about us go visit our website softskills.audio

there's only one reason to do that and that's so that our little google analytics chart will go up and that's all we want right jameson that's all we're looking for right that that also contributes to my desktop background getting more beautiful for those of you that don't know what jameson is talking about that never made it to the last episode oh it didn't oh that was the secret that was the secret deep side yeah that sometimes we record uh and and for whatever reason some of us decide not to actually hit record just just like for fun it's just a fun little trick we like to do sometimes like you play it on yourself yeah yeah i got i got you so good last time dave hey remember that

half hour where we talked and didn't record anything it's gone gotcha ha ha anyways that is a great place to find out more about us what else can people do follow us on twitter at soft skills eng and that is where you can send us a direct message or a tweet to ask us a question which you can add to our ever-growing backlog but don't worry we will get to all these questions eventually before we die i think i think that is a dave smith guarantee this is the only thing keeping me alive actually is this backlog so please contribute yeah does that mean when the questions run out then you die it's like the last petal of the rose on beauty and the beast yeah it kind of is please save dave add questions save dave oh i love it um if you are interested

in sponsoring this podcast we would love to talk to you as well uh we think that we do a pretty okay job despite sometimes not recording and i think people really enjoy um the the questions and and the witty banter that we have so we would love to talk to you if you're interested in reaching an audience of many smart software developers and and related people and we will talk to you next week farewell thank you