Soft Skills Engineering - Episode 42: Bootcamp Job Hopping and Cultural Reliability

Episode Date: January 2, 2017

In this episode, Dave and Jamison answer these questions: Should I switch jobs to my fourth job within two years of graduating from a bootcamp? What non-technical practices and cultural attributes improve software reliability?

Hello everyone and welcome to episode 42 of the soft skills engineering podcast. I am your host and your Caught you dramatic pause enthusiast Oh, that was so beautiful Thanks, I I am your other host and favorite number Dave Smith. Oh, you're right 42. That's that's a thing. That's right I don't know. Do you know the thing? I do know the thing. I have read the book.

I have not seen the movie. I'm like, yeah, that's a number. But it doesn't speak to me in a deep, personal, nerd way like it does to you, Dave. I don't know. It does. I think it's because I read this book, which, by the way, we're talking about Hitchhiker's Guide to the Galaxy. Probably my most favorite sci-fi novel. And I think it's because I read it when I was an impressionable teenager.

and so it left a mark sure well it made you who you are today which means it can't be it can't be bad douglas adams is great um 42 yeah that's we've we've made it this is probably more momentous than the 100 episode oh yeah oh yeah this is a podcast where we answer your non-technical questions about technical fields like software development and we have some of those questions today. Do you want to read the first question, Dave? Yeah, sure. This is from listener Brian. Brian writes, I graduated from a coding boot camp and have been developing for about two years. I'm seven months into my third job. Each job has been better than the last with more responsibility and newer technology. And now I have a chance to go to an even better job.

I feel bad leaving another company after such a short amount of time, but a lot of the things I've and promise haven't come to fruition i enjoy some of the challenges from this company but i worry i may become stale since i'm the only front-end developer should i stay or should i go i don't want to gain a reputation as a job hopper should i stay or should i go now i didn't notice this when reading it before but it's there well if you go there will be trouble but if you stay there will be double oh that's true that was basically our our conclusion too so how did they know the clash i think your concern about being uh known as a job hopper is uh valid the fact that someone is kind of recruiting you if you were just like i'm gonna quit and go try and find another job

i think that might be more worrisome in the short term but at least in the short term the consequences don't seem that severe as far as getting a reputation i mean you already have a job lined up so it's not like you're not going to be able to find a job i was once advising someone in a very similar situation to you and i think he was on his third job as well out of college in a cut in like less than two years and he's like hey i've got this new opportunity to go somewhere and i said to him okay but you better stay there for a good long time because at this point you're going to start to get a reputation and he's okay well he did and then within like 12 months he was gone from that job too so but how did it turn out for him he's working at a

well-known um bay area company and doing great stuff and so like it seems like it worked great everything that was true 10 years ago when i advised people about avoiding being a job hopper it just doesn't seem to be true anymore i think that comes from i i would call it yeah i think there's an older idea of the employer employee relationship where it's it's a longer term commitment where you say company i will work for you and the company is like i will take care of you and you're committed to each other and you get your gold watch yeah and i don't think that exists in software at all i think the tenures are short yeah um this is making me feel like an old foggy though because i to dave i'm a job hopper to to this person i am like an ancient wizened

wizard at each of my jobs having stayed for like 20 months yeah yeah multiple years at a single job um but maybe this is just the brave new world that we live in where i really wonder well i feel like it's bad but everyone literally everyone i know who has done this has benefited from salary increases and uh just like increase i don't know they just end up somewhere they want to go it's kind of like do you know simulated annealing that machine learning thing no um too bad because i won't be able to explain it coherently on a podcast basically you're trying to optimize something and the idea is every once in a while you just kind of like fling it in a random direction to see if you can end up at a better

spot through through some kind of hill climbing or optimization so it's kind of like if you jump around a lot and then optimize from there you might end up at a place you wouldn't have arrived if you just stayed somewhere for a long time okay so maybe maybe the ending to this story is like with the person you mentioned earlier they job hop a lot until they end up at the promised land and that's a good place for them so maybe this caller i mean this question asker is actually part of an elaborate machine learning training algorithm yes that was basically what i was trying to say i i guess i'm trying to reconcile the reality i see with the feeling i have which is like i would not want to hire this person but someone is going to hire this person they've

already made the offer yeah exactly um because i want to work with people that are gonna build stuff and you can't you just can't build stuff after seven months the one thing that i noticed in the question here that i are in the details that i didn't read out loud is that this is a front-end web position and the front-end web world for those who are not aware uh i guess you could say it's a little tumultuous in in the technology like i'm not talking about the jobs i'm talking about the technology turnover you know the tools you use to build a front-end web app today um like if you're using the modern currently de facto modern standard tool set is completely different from the tool set maybe even two years ago right so maybe maybe you can afford to turn

over at your job every six months if you're a front-end web developer because all your technology is turning over anyway yeah that's true it's i think you also mentioned that maybe this is just a thing that will become more commonplace in boot camp grads where they just have a different a different path there the idea of boot camps is still pretty new in the industry and we're still figuring out how to work with people that come out of boot camps effectively and maybe this is just a more common path for them to take where they jump around a little bit more than than people that uh got into the industry earlier or through other paths at least at the beginning of their career and i i kind of have this prediction where in maybe five years or

10 years we'll look back at resumes of people who came out of a boot camp and say oh yeah you dropped you jumped around between jobs you know four times in the first two or three years but i see that you went to a boot camp and that's what everyone does out of a boot camp you know and it's like no big deal whereas if you maybe came out of a more traditional like computer science track maybe jumping around every six months would be looked down on differently i don't know that's just kind of a prediction that i have and we will revisit that on episode 327 of the soft skills engineering podcast with more data i also think i i can see how this is a rational action given the market people are so scared to hire junior developers no one wants to be the first company

to hire someone because they perceive the risk to be so great but the second person the second job everyone wants to be the second job so you you can get an enormous salary bump um going from your first job to your second job given the conditions of the market right now and i don't think that's uh necessarily right or healthy but it's there it is yeah it is anyway there are strong incentives to do this right now i think also i think that along those same lines that the people coming out of a boot camp are like i think i've said this before they're not going to google necessarily um and although all the blog posts about people coming out of the boot camp are written by the ones that go to google yes but um they are sometimes the jobs that i've seen they

are going to are like sometimes a little bit short-term jobs anyway like for example an agency position where you're building like greenfield product in a rapid like rapid iteration fashion for lots of different customers over the course of a few months and maybe in six months you've built two complete websites for you know different customers and so maybe it's completely natural that you would move on to a new job because it's not like you're walking out on a team that you've helped establish this big platform no you've been like cranking out these fresh products that are not like the most sophisticated gigantic systems that power google you know the difficulty in that is all around deadlines and timing and speed not necessarily depth of a feature set is what you're

saying yeah exactly so i mean it's not to belittle no accomplishments of those people at all no it's just that's a very hard problem to solve well how do you stay sane while building stuff rapidly for lots of different clients yeah so anyway i guess the tldr of what i'm saying is maybe it's just normal for the this particular person maybe it's perfectly normal to come out of you know a job after six months and maybe the company they're at turns over people like that anyway and that's probably a good question to start asking yourself if you're fresh out of a boot camp is as you meet other people ask them how long have you been at this job you know maybe you're interviewing how long have you been here uh who was the last person to quit and how long were they here you

know get a feel yeah it's also possible that uh the reason you hop jobs so much is that um the thing that you're looking for doesn't really exist in a in a job where you work as an employee and you might be angling for a more entrepreneurial future i guess um if you're really interested in building your own ideas or having more control or say over technical decisions or I don't know that good point. That might be another possible outcome. Yeah. So as far as should you stay or should you go?

It sounds like in the short term you should go and you've kind of already decided that from, from reading. I mean, that seems like an okay thing. yeah i think at that point on your fourth job in two years that you you would have a reputation as a job hopper yeah uh so i agree with dave that you either need to stick around for a long time or like figure out what's going on and and try and fix that but now that i just said that i feel

stupid no i think i think that's reasonable um i would say take a look at this next job and see if it's a place where you can really get some depth and learn one of the things he mentioned in the question was that he doesn't have other people uh that he can look up to as a mentor or can help guide him and that's a big deal for someone who's new to the industry to be working on a team where you're the only one working on, say, web front end, you know, you just don't have someone to guide you along. And if you can find a position where you do, that'd be great. That's a great point. I was lucky enough to have jobs early on in my career where there were people that were smarter than I was who I could learn from. And so maybe all the stuff I'm saying is just coming from

a place of privilege that this person doesn't have. Maybe they worked at not so great jobs that didn't teach them things that much and so i'm just like why don't you do what i did and just get a good job at first i would caution you to be aware of grass is greener syndrome every we've talked about this before but every company every job is just horribly broken in its own unique little way and there's not going to be a perfect job out there and guaranteed if you go to this next position there's going to be something there that you don't like that you wish was different and it's always like that yep so learning to learning how to work within a system to improve it is an important skill that i think uh i would suggest you try and develop that and as a next

thing to work on is okay i don't like this thing what am i going to do to change it besides quitting and getting a different job sounds great they've applied the soft skills engineering advice too much that's what i just said oh no it's too much of a good thing stop quitting your job so much oh i mean it sounds like it's worked out and it sounds like it it might work out again uh this time yep and i don't think there's some magic number where if you hit number five then suddenly you have this black mark on your resume forever i mean if people are still offering to hire you then you're doing something right so yep i think it's much more important that you have a easy to understand story for why you left each job and if you got fired from each job that's a very different

story than when than you saying i wasn't challenged and i was looking for something better you know sure totally different story sure well question answered question answered um i want to take one brief second to talk about our sponsor dev mountain we love them in a commercial transactional way um they they uh do dev boot camps in utah they do ios they do web development they do ux and ui um they have full-time courses and part-time courses and in the full-time courses they offer free housing actually which is pretty cool yeah if you're interested you can go to softskills.audio slash devmountain and it'll take you over to their website and you can find out more about that so thank you devmountain thank you all right you want to read our next question

i do this one this is one of the first questions we ever got on the show and it's just sat in our backlog so we're getting to it yep what non-technical practices or cultural attributes improve software reliability or delivery that's a great question i was just trying to think of the most dogmatic answer i could think of is it 42 no it's pretty much split between agile methodologies and test-driven development this is right on the edge of like technical things that we don't talk about but the question is explicitly about non-technical things that affect these very technical things so good point this is an interesting question so tdd and agile those are like right out right they're not on the table for discussion sure i mean yeah because they're

bad that's what you're saying right no they're technical yeah yeah instead we should rely on solid anecdotal evidence from our own lives i think i have more negative experience with this than positive experience i think i could tell you things that make it harder oh yeah okay to have reliability. Let's do that. I would say either no QA process or developers who feel a disdain for the idea of QA. Facebook is super cool, right? They're one of the cool tech companies and they famously don't have a QA department and they do a lot of stuff to make sure their software works. But if you just read blog posts, you're like, Facebook doesn't have QA. QA sucks. We're too smart for QA. And then you just like go write a bunch of code and it breaks all the time.

um yeah i have i have lived that reality before you need some kind of qa and qa is a very different skill from testing like writing unit tests or integration tests or whatever and either your developers need to have that skill or you need someone else that has that skill but that's i don't know qa gets a bad rap sometime but i i think it's it's really important i think you're Right. And to add to that, I think that you really need to bake QA into every part of the process, not just, you know, some checklist at the end of the whole development process where you're like, okay, and here we do all the QA, right? Like, I think that the highest quality, highest reliability teams that I've seen, they have some kind of QA baked into the entire pipeline, if you will, of their development process. you know from from the first line of code that's written all the way to the final verification by the person who came up with the feature idea sure i've also seen teams that

that don't really use their product that much they don't really have a great understand a great feel for what the whole product does or is and they build their features and kind of test them out as they build them but there's just a lot of there can be a lot of complexity in how the rest of the product works that isn't the feature you're working on and that can make it harder to build reliable software than if you're deeply familiar with how things work and you you kind of click around in it a lot if it's a product that you can click around in or you just use it in some way beyond just clicking on the most recent thing that you wrote does that make sense i think so have you seen it done that way before like and what the outcomes are uh of of using the software

more intimately of not of it just being like well only i've done it yeah the outcomes are i broke stuff that i didn't know existed all the time sometimes it's hard to become an expert in your own software especially if it's for a domain that you don't care about that's why i personally find it important to care about the the product i'm building either i need to like make myself care about it or it needs to be in a thing i i find intrinsically interesting because if i don't care about it then this is that's what i do i just like write the feature in a vacuum and don't consider in the context of the whole product because i don't i i don't develop enough empathy for what it's like as a customer to use it yeah maybe that's the underlying principle is you need empathy with

the customers instead of just like seeing them as obstacles from you being as productive as you want to be like they keep giving you crap to do those dang customers um one of the things that i love like to do at every company i've been at is something that i'll call broadly continuous improvement and specifically one way to do continuous improvement is through retrospectives and i think the word retrospective actually came from the agile movement but the idea is that as a team you get together periodically and review something that uh has happened recently and you talk about what went well you talk about what could go better and pick something that needs to change and one of the things that i did on my teams was i would have the team pick only one

thing to change between now and the next next retrospective and focus on just that one thing because it's really easy to be like well here's here's a list of 10 things we all need to do better and when you have a list of 10 things it's really hard to focus and so you end up doing none of them right yeah but if you pick one thing i found that you can usually make a material impact on that one thing because the whole team focuses on it sure and you have to repeat this like i think one of the one of the reasons that this sort of thing can work but also fail is that it's super repetitive it can feel super repetitive to just constantly be doing retrospectives you know like how often do you do like every seven or eight minutes would be best like if you want

to be really high quality the most feedback right the fastest it's all feedback it's just all about iterating i think that in an ideal world you do them on some schedule but i always tended to do them after something really bad happened you know it's like sure oh we need to do a retrospective you know sure which by the way it's basically a nicer way of saying post-mortem yeah at that point yeah if it's an if you're doing an air quotes retrospective about the database going down another thing that works for me personally is not feeling rushed i feel like quality is hard to rush and the default state of building software commercially is is pressure and pressure to rush you always want to get stuff done faster someone's always waiting for your

thing there's always another five things to do after it and depending on the product organization you work with that that pressure can come through and affect the developer team yeah and i don't think most developer teams are like high performance we rise to the pressure type of things like people talk about that yeah like that's like a macho thing that people love to kind of pound their chests and say like i can sling code with the best of them i'll crank it out under pressure but i don't think that's true for most teams oh and i think people i think they can crank it out exactly but will will what they've cranked out work in two weeks that's the Yeah. Or, or will they be able to make the switch in their brains from having developed a thing to having to QA it and figure out, okay, as if I use this as a customer, what are all the crazy ways they can break it? Like there's just all these little steps that get skipped when there's a lot of pressure.

so there will always be pressure you can't not have it but if you can set up your engineering organization to to shield people from it to allow them to do good work i don't think you need to like just like put developers on this mountaintop and like airdrop them sweeties and i don't know ball pits and stuff and be like we'll just let them do good work like they need to be exposed to the realities of the business but you also i think way back in episode single digit land we did an episode about deadlines right remember that and our conclusion our conclusion was basically that in the absence of a deadline engineers will generally just not deliver anything yeah it's like some amount of pressure is good too much pressure is bad yeah but but quality is a thing that

suffers under a lot of pressure that's my my takeaway one way that you can measure pressure because this is hard to measure but one way you can measure it is by asking your developers to create stories or feature requests or whatever you track in your system that identify technical debt that has accrued as a result of these kinds of schedule pressure and you can put numbers on them like you know to weight them and say well this is like an extra large technical debt item this is a small technical debt item and then you can use that to say how much technical debt have accrued and that is an indicator of how much pressure you're putting on your developer team if you're putting too much or too little sure i mean that sounds a way to like a way to come up

with fake numbers to put on stuff is a small like a two and a big is it like story points where then you add them up and yeah exactly and it's it's not like they're an it's they're not an absolute measure of anything but you can say you know hey a month ago we had x number of story points worth of technical debt and now we have twice that you know what happened do we need to stop and pay some of this off yeah i think for me it hasn't been technical debt i've been i've generally worked at places that that say explicitly hey we need to work on technical debt and we know that's an important thing to fix it's it's just a feeling where it's like yeah i need to go fix this database thing and product is fine if i do that but also holy crap we have so much stuff to get done and

we better get it all done so i think so it sounds like you're saying that it actually messes with your mindset more than necessarily producing technical debt that's obvious yeah i mean it it the tech debt is a side effect of the overall feeling of going of needing to go faster and cutting corners but that's the the feeling of needing to cut corners is the issue i feel like not the tech debt or it has been for me okay so one other thing that i think is important is for engineers to have a sense of curiosity and what i mean by that is i think can be best explained by a story from nasa shall i tell the story please i love stories and nasa sounds cool so i read about this story excited in a book called apollo i think and it was basically the 10-year history of the

apollo program um in the u.s you know from 1960 something to 1969 something like that and um there was this one particular engineer named john aaron and one day john was doing a simulation on some equipment and he noticed some weird behavior and he decided to dig into it and investigate to figure out what had happened like it was some strange behavior they'd never seen it before wasn't documented anywhere and um he basically did a root cause analysis figured out what was going on i think he stayed late to do it um but he was just so curious he couldn't let it go he's like what happened well anyway later on one of the apollo missions the spaceship is flying up through the atmosphere and it gets struck by lightning and a few seconds later the

flight director is about ready to call an abort and john the same guy john aaron looks down at his instruments and says hey it's that same situation that i dug into a few months ago and he knew exactly how to fix it and what the root cause was. And he just said, hey, I recommend we switch this particular piece of equipment into this auxiliary mode. And boom, suddenly everything was back on track and they were able to complete the mission to the moon. But I thought that's just an awesome example for all of us

to remember to stay curious about how everything works because you never know when that knowledge will come in handy and it can, I think, improve the reliability and quality of your stuff, your systems. yeah i've seen a lot of debugging stories that start with i noticed this weird thing and i just kind of kept poking at it until and then they they discover it's like the tip of the iceberg and they discover the all the insane underlying stuff that's caused by this little weird blip another thing i thought of when you were telling that is to me that that says that

there should be a little bit of slack time if you have your team scheduled out to 100 capacity there's no time to explore those little curiosities and and that's often how bugs are are found right it's little weird things yeah in other words cut your team some slack and anecdotally your productivity might go up yes we're all about the science here you will get to the moon that's right cool there you go this is one i think we would love to hear from listeners about what things have you seen work or not work at your company's non-technical cultural things that that help you build better software yeah totally there's like so it's like a thousand things here you know Mm hmm. And I want you to list them all listeners. Just send them all in. That's right.

Well, have we answered this question, Dave? Sort of. Okay. Question sort of answer. This is a great one. I feel like answering this question is like the path of an engineering manager. Oh, yeah. Your whole job is to answer this question or a large part of your job is to answer this question. How do you build a team and a culture and organization so that you build good stuff? Yeah. Yeah. Yep. Super challenging.

Yep. All right. Where can people go to find out more about soft skills engineering and ask us a question? They can go to softskills.audio, which is our website, our internet site. They can also go to at SoftSkillsING on Twitter. So you can send us a direct message on Twitter or through a form on our website. You can send us a lot more information. All right.

I think we're done. Excellent. Thanks again. We'll see you next week. See ya.