Soft Skills Engineering - Episode 8: Work life balance and on-boarding new engineers

Episode Date: April 25, 2016

In episode 8, Jamison and Dave answer these questions: How do you achieve work life balance? Do you have any strategies that work for you? Any bad examples from your own lives? How do you on-board new engineers?

Hello, everyone, and welcome to Episode 8 of the Soft Skills Engineering Podcast. I am Jameson Dance. And I'm Dave Smith. And together we formed the Voltron Podcasting Duo. It's only two parts, though, not five. Yeah, it's just two legs that walk around. It's a weak sauce, Voltron. So I don't think we really have any announcements.

We'll just dive right into the question. Do you want to read it, Dave? Yeah, sure. how do you achieve work life balance do you have any strategies that work for you any bad examples from your own lives of course my whole life is one bad example we could start at the beginning i was born an infant child i was immediately out of balance right at the beginning immediately yeah um so okay i have an observation about this and you tell me if it's true i think everyone on earth

that i've talked to has some bad example of work-life balance is is that just a part of life oh i was i was part of some big twitter thread where everyone was swapping stories about like when i was a youngster i worked 40 hours in one day and they'd kill me every night and like and and that's just a thing that everyone does at some point is there anyone out there that from the beginning of their career is just very measured and balanced and determined and and they never slave away or pull all-nighters or do crunch time ever i there must be someone statistically speaking i want to meet them because my experience is maybe you don't need to suffer but everyone kind of suffers to figure out oh that was a bad idea

and that makes me burn out sure sure i think if you've never had to deal with a work-life balance issue it probably means there's not a lot of demands on you um i think as a kid i didn't have a big problem with this you know it was like all i was i guess it was like school fun balance were my two big things and i think i just did a lot of fun yeah i think i did that same thing i remember i carefully set up my schedule senior year so that i would take three classes a day yep they would end at one and then i would go home and wakeboard all day oh wow i didn't take math for the last two years of high school like that oh my that's for nerds and then math is for nerds it turns out that it's important and and it kicked my

butt in college but not as important as wakeboarding uh not at the time no um uh i don't know i think um i think what when people say they want to achieve balance what they're really saying is that they want to achieve they want to have success in a bunch of competing outcomes and the the scarce resource that they're dealing with is their time or maybe just their energy like emotional energy um and so like you know there are examples of outcomes are like you know some some success at work maybe happy relationships uh community involvement of some kind and i think achieving balance generally means figuring out how to multiplex your time such that each of these competing outcomes get an appropriate portion of your attention that's commensurate

with the outcome you're hoping to get from each of them there were a lot of five dollar words in there yeah baby i wrote that one down um so it sounds like you're saying you can have all of the things well maybe i guess what i'm saying is i'm just trying to define what we mean by balance because to me it's not about having a perfectly level scale where you have work on one side and life on the other and the scale is flat to me it's more like focusing on outcomes how much energy will i put into outcome x versus outcome y what do i want to go for and sometimes that scale is slanted you know the the work side is high and the life side is low and vice versa depending on what outcome you want at this point in your life okay i like that idea because it acknowledges the

existence of trade-offs um exactly yeah we lots of times focus on the success of people i was listening to some interview with terry gross who's a famous um radio host on on npr and has been for decades and she said that uh she basically doesn't have any friends she doesn't do anything besides work for her whole life and she's super successful and really good at her job and and famous and everyone knows her but she's definitely um made trade-offs in order to achieve that success so for her work-life balance is work and that's her life and that's that's the conscious decision that she made yeah and i think when people say they want to achieve work-life balance i think usually what they're saying is they want to work less yeah um and i don't think that's in terry gross's

vocabulary like oh yeah i just i'm going for work-life balance she's like no i want a successful outcome in my work yeah this also seems like it's different for different people uh different stages of life maybe no i'm pretty sure everyone has the same exact goals in mind i mean if you are single or in a relationship that affects your your time allocation if you're a parent or not having kids changes that and and uh unfortunately if you're the mother or the father it's probably also very different just different societal expectations on how you allocate your time yeah definitely um and and some people get really frustrated because they see other people have success, but they don't

have the same demands on their time outside of work. Yeah. Like here's an example of that. One of my friends, right when we got out of college, he was married with a child and he went into the accounting industry, which if you're in software development, just count your lucky stars that you're not an accountant right now. Because when you get out of college and go into one of these like big five public accounting firms, they just work you to death. I mean, 80 hours a week is the norm. And he said he was surrounded by all these people who were not parents. Um, and he was a parent and he wanted to spend time with his daughter, but he was competing in the success race air quotes, uh, against people who had no outside work obligations. And so, you know,

to them, work-life balance looked very different than it did to him. And, uh, it was super hard for him sure um so how do you how do you solve that problem where you you want to spend time outside of work but you feel a lot of pressure either to succeed or just to keep up uh maybe maybe you're getting started in programming there's just so much to learn and you feel like you're really behind or or maybe you just want to i don't know want to advance your career somehow well i think the first step is acknowledging the fact that your time is not infinite and that you will have to make trade-offs and putting value on the things that are important to you, at least in a time limited way, uh, is a, is a good first step. So you say, okay,

I want this outcome in my programming career. What is that going to take? And then try to identify what that is. Maybe it's a certain amount of time each week, like maybe five hours of outside work study or something. Um, and then also acknowledge the fact that you have other demands on your time and what those are. Maybe it's a hobby and maybe it's a friend, maybe it's a spouse. Um, and then figure out what you think those should be. Now this can sound a little robotic i think you know where it's like well um to your significant other i will give you 30 minutes this week because that is what i value our relationship has right like that sounds pretty cold but at the end of the day you do i think need to realize and acknowledge that there is a trade

off to be made there yeah in the market value of your time is x and i will assign yeah um therefore the market value of our relationship is x that's a great way to get out of a relationship yeah yeah try that one instead of never texting back just use use that um one other thing that we've kind of touched on but i want to talk a little bit more explicitly about is the idea of efficiency i think sometimes we equate time spent with outcomes and i know i waste a lot of time and sometimes the more time I spend on a thing, the more time I waste on it. So I think it's possible to achieve more just by being more efficient. And I've had a hard time just doing this on my own, but in response to other life changes, it's kind of forced me to do it. So I would say I'm definitely more

efficient than I used to be because I have to, because I have less time to spend on learning new things or accomplishing things at work. So if you can figure out some magic secret to force yourself to use your time more efficiently i think you can get a lot of the same benefit that other people get by just applying more time especially in software where uh so much of it is is is mental work that isn't just kind of manual labor where you you lift more logs in more time uh yeah of course yeah so you're saying create some kind of forcing function that will yeah like maybe like put something in your schedule that will cause you to do things a baby is a great forcing function just have a baby uh that is a terrible reason to have a baby but it's not just

for tax benefits anymore if you want to have a child and you end up having one that's one positive outcome is like you gotta get home and help out so you you have some incentive i i've yeah i've just felt this really directly where it's like well i'm gonna be here for 12 hours so i don't feel bad about like playing video games for an hour during the middle of the day or something um or or that was before you had a baby yeah that wasn't just making sure i understand yeah or or even beyond the explicitly like i'm gonna goof off for a little bit just uh i think i'm a lot more deliberate about stepping back and saying is this the right approach and and taking more time to oh i'm gonna say stupid words look at the big picture and synergize the teamwork

asks. Well, it sounds like it's causing you, it's forcing you to be a little bit more introspective. Yes. Yes, it is. And that is a valuable thing overall for me. So I'm going to say something a little bit controversial, but I don't think work-life balance is all that important. I do not believe that it is the right focus, at least for me. To me, I would much rather focus on outcomes that I want to achieve and sustainability. so you know i'll just give a couple of examples like let's just start with something away from work let's say you're training for a marathon you know while you're training for a marathon your life is going to be out of balance and that's okay like you may decide i am willing to to make

that sacrifice and that is just fine if you only aspired for balance for your whole life i think achieving difficult things would become actually much more unlikely so i'll give you a couple of examples from work. So there was a project at work that had it was behind my job at the time actually paid overtime hours. So it was actually by hour got paid by the hour. And it was a programming job. And, you know, I talked to my family and said, Hey, I've got this opportunity to work a couple of extra months, a lot of extra overtime and make a bunch of extra money. Is this a trade off we're willing to make for a few months? We all agreed, yes, we need the money, we're going to do something cool with it. So we focused on that outcome, made sacrifices,

and got it done. Now, the sustainability part of that was it was time limited, like we knew this was only going to be a two-month deal and then at the end it would be back to normal so it was sustainable in the way in the sense that it wasn't a permanent state of affairs but we made a trade-off you know it's like less time with me around but more money coming in the bank account and it was an outcome that we all agreed we would like to do so if i had just said well sorry this is going to break my work-life balance then i wouldn't have done it and we wouldn't have had that outcome that makes sense i don't think that sounds that controversial it just sounds wise well i think a lot of times you say if someone says like how's the work-life balance at your

company like you have to say oh it's great yeah you know like otherwise like oh you're slave drivers yeah you know and and to me just striving for balance is just not not the greatest thing i mean you look at some of the greatest achievements of uh humanity in terms of whether it's technology or anywhere else artistic or otherwise these things all required out of balance lives to get done you know it doesn't mean you have to be out of balance your whole life but yeah you're gonna to have to do something different i think there's an important point to be made there which is often you hear this narrative around startups particularly where you you sacrifice and you kind of give up some hours of your of your life some years of your life uh working really hard

and sleeping under your desk and crunch time to hit deadlines and then you make it rich yep um and then you go retire on the beach sipping drinks yeah that's the balance or you become like a vc or your job is just writing medium think posts or something you you ascend to programmer valhalla um and and i think that is a narrative that's often used to to uh not abuse but to take advantage of people um i would say the vast majority of money that's made off of startups is not made off of by programmers it's made by executives and vcs good point so in other words the people that are making their lives go way out of balance are not the people making the majority of the money yeah and maybe they do maybe they do work really hard and work crazy hours um well i

can say for sure the founders and executives do generally yeah sometimes but sometimes they don't and and often they by encouraging other people to work crazy hours they benefit uh in i don't know in a way that doesn't seem commensurate with their effort there's also there's there's actually a famous guy named jwz he was a early early developer at netscape in the 90s and they did crazy insane crunch to develop the one of the first versions of the netscape browser like sleeping under the desk and and working 20 hours a day for months and weeks and and um he ended up making a ton of money like millions of dollars he he achieved the dream right he retired he owns a nightclub now and that's his life oh that's the dream yeah he bought a nightclub

with his his Netscape money basically um and so so he made it right and then there are some people that kind of point to him that are like be like JWZ work really hard for this company it'll win the VC lottery it'll go public it'll make tons of money your options will be worth a bunch and you can retire and he wrote this pretty scathing blog post attacking that notion uh and I'm actually going to quote from it because he says it better than i did uh follow the money when a vc tells you what's good for you check your wallet and then count your fingers he's telling you a story of if you work really hard and don't sleep you'll get rich because the only way that people in his line of work get richer is if young poorly socialized naive geniuses believe that story without those

coattails to ride on vcs might have to work for a living once that kid burns out they'll just slot in a new one i did make a bunch of money by winning the netscape startup lottery it's true so did most of the early engineers but the people who made 100 times as much as the engineers did i can tell you for a fact that none of them slept under their desk if you look at a list of financially successful people from the software industry i'll bet you'll get a very different view of what kinds of sleep habits and office hours are successful than the one presented here so to to me that's it's not saying don't ever work hard it's more saying work hard at something that you benefit from like i i would work that hard if it was my company right if i founded it

and owned it and ran it i would have a hard time sleeping under my desk as like engineer number 10 at some 100 person company or something like that because the chances of it being worth it in terms of like millions of dollars of payoff seem pretty low to me other people would benefit more from my effort than i would make sense so that's my long rant about uh avoiding being taken advantage of by this concept of sacrifice for the company well i am gonna stop sleeping under my desk right now tonight you're actually recording this from under your desk what's that you're actually recording this from under your desk where you have lived for the past four days my blankie and pillow yeah and and this this guy uh he clearly has kind of a chip on his shoulder about venture capitalism

yeah in general but i think the the underlying i think there's some truth to what he says that there's kind of this dream that's sold that doesn't benefit the people living that dream yeah yeah so if you're outcome oriented you need to be confident that the outcome will actually come from your efforts if you're gonna turn your life out of balance there are an infinite number of ways that a developer can be uh i don't know cheated out of what they view is is the rightful reward of options or money or bonuses or whatever just there's a whole industry around that so be careful that's that's my caveat be careful yep words of wisdom from jameson yeah on that shining brilliant happy note do you want to move on to the next question yeah sure can you read it for

yes uh this one's pretty short how do you onboard new engineers onboarding is that the answer or is that just like you do it it's like a callback like we're a call and response thing now i just felt like i needed to say some more words because the question was so short yeah so i can i tell a story please um i worked for what i would consider to be a really good company cared a lot about people had a lot of really smart people working for them um and we were terrible at onboarding it's probably one of the things we were the worst at uh there was kind of this core of engineers who'd been working there for a year or two that all got

along well and worked well together and we started hiring again and we brought people in and they we liked them they passed the interview they did well and uh so we so we hired them on and they just kept bouncing out after a month or two, not that long at all. They either were unhappy and left or their, their performance wasn't what we wanted it to be. And it went through several people. And what I realized afterwards was a lot of that came down to our onboarding. Our attitude was kind of like, if they're good enough, they'll survive. And then we just like throw them in, like they, they show up the first day, we tell them what to install and then like hand them a task to accomplish if you're a rock star you can onboard yeah exactly and if not we're gonna off

board yeah yeah sadly that was a little bit of the attitude like we don't have time to to devote to helping people like it's either sink or swim because we're an elite team and and just kind of some arrogance around that and i think uh that hurt us a lot because it's it's hard to start a new job and it's hard to find the context when you when you enter a new code base and a new team and everything yeah and i think we lost a lot of people who would have been really good engineers had we helped them pass that initial hump um so my yeah my my attitude used to be like suck it up they'll they'll work it out and now my attitude is you just pair program with them for a few weeks or months when they start and that avoids the just kind of throw them in the deep end and if

they're good enough they'll figure it out problem pair programming there it is yep there's your answer that's i mean there's some other there's some hr stuff that i think you wanted to talk about but that's the main technical onboarding thing we do we just pair program that's cool that's really cool and you do that for a few weeks yeah it's it's a few weeks to a few months we pair program a little deal like a little ceremony where you say spread your wings young developer you're free to fly no we don't it's it's pretty informal but we pair program uh a little bit just in general and then we just pair program more with new people it's so how do you know when to stop pairing like when to go to the little bit mode instead of the all day mode i just

know it when i feel it there's not a yeah maybe that's the thing we can formalize in your toes yeah i yeah i i kind of look to the sky and judge the omens um i think it's it's more when the person when the new person feels a little bit more confident and they're okay with pairing less it's here it is it's when the fact that i'm annoying to pair program with boom is more painful than oh yeah that they can't get stuff done by themselves it's when they say stop bugging Yeah, exactly. And it's like, good one. You used to be helpful and now it's not worth it to suffer. That's a good heuristic. I like that. Yeah. So, uh, at, at my company, we have done this two ways. The first way was something we started about a year and a half ago and we had like a three day

super immersive fire hose onboarding of all the things we would, we would have the new person meet every little team. We had about eight little teams, uh, meet the, meet all the product managers, get demos of all the different products that we build, get code walkthroughs for the different code bases that they would be interacting with. They would even sit down with our technical support team and listen in to user support calls to hear, to get empathy for the user. And that's like super cool. And then after three days, we'd be like, all right, now you're free, you know, fly, fly, birdie, fly. Well, this had two problems. Problem one was that it was such a fire hose that you'd spray the tank with water and only about 10% of the water would stay in the

tank you know and um problem two was that it created we think and this is kind of hypothetical but we think it created a mindset of dependency where the developer would say if it was important they would have told me in the onboarding and so i'm not going to dig into this thing you know and it was like they'll tell me if something's important rather than i need to go figure that out on my own and dig into it and learn it myself um so we scaled that back a little bit and now we do, we do like a one hour session where we introduce them to the organization and talk about our process. Like how do we ship to production? What's our release schedule look like? How does our, you know, what are the various responsibilities in the organization for like,

what's a team lead do? What does a manager do? And we go through all that. That's about a one hour deal. Let them ask any questions. And then we hand them over to their small team, which we call a mission team of about three or four developers at most to help them uh shepherd into the process and we don't usually do too much pair programming but that's up to the team to decide what they think would work best for each person and they know like this is a new person you're responsible for getting them up to speed on your team i mean we found that to be a much better balance of you know fire hose versus uh you know letting them kind of sink or swim on their own but with a maybe with a life raft they can cling to if things go bad and then the

interesting thing we found is that about two weeks in or three weeks into this process they will have enough context to be able to ask questions and get answers that stick so like if they want to deep dive into our source code or our database schema or something now they actually have enough background to ask that question and have it stick and so i'm pretty happy with where we are there yeah i like that i like the the going back later i think that's a that's a thing that i might steal um i want to say one more thing about pair programming sometimes there's there's this chunk of information that is what you want your company or your culture your team to be like and that's often a lot of mission statement stuff or values or best practices and it can sometimes feel

really good to tell people like we move fast we we ship often we have great test coverage we value empathy and there's just like this list of stuff that you tell people and by telling them you hope that you encourage those attributes in them that list often doesn't reflect the reality of of your team or what it's actually like to work there it's more kind of like an aspirational thing and and the thing i like about pair programming is it emphasizes the stuff you need to do your job instead of the stuff that you wish were true about your company um i think it's valuable to to introduce values and stuff like that but if you can introduce those through action instead of a powerpoint presentation that says here are company values i think they would stick a lot more

so so that's part of why i love pair programming as a way so you can like demonstrate this yeah it's like maybe when you're pair programming like you give them like look you need to demonstrate this attribute that we want everyone to have like this part of our culture yeah do you have like a checklist where you're like okay i demonstrated uh tenacity today uh no we're just tenacious um well i mean yeah if you really value test coverage and that's part of your engineering culture you will write tests as part of your pairing i got it or if you value empathy you'll you'll try and understand your pair and help make sure that they understand you and stuff like that so it's it's more kind of pragmatic it feels like yeah cool um yeah let's talk about

facebook okay so uh jameson you have a friend who's uh recently gone through the facebook onboarding process right yeah it wasn't super recent but yes okay i have a an acquaintance who has gone through it as well and they do something really interesting i think it's a six-week process where they introduce you to lots of different teams they uh teach you about the code base and the deployment strategies and the infrastructure and um and they have someone who's actually got the title of drill sergeant although i think that the metaphor ends the title and it's not really like you know yelling in your face and making you do push-ups although that would be awesome yeah um and and but it takes six weeks to get through this process and then at the end of

the six weeks the outcome is that you know a lot about the company and the social structures and the organization and then i guess jameson according to your friend that's actually where you get to choose your team right i think so that was i could be misquoting him but that was he said you kind of are exposed to a lot of different projects and teams and people and it's like that awkward like getting asked to the dance asking someone to the dance thing where you just kind of figure out they kind of like you and you kind of like them and then you then hey would you go tell the uh yeah the router team that i really like yeah exactly it's like you you kind of meet them and see what it's like and and then if there's if you both would enjoy working together

then you kind of end up there so that all sounds really cool and i gotta say that i've been guilty of having facebook envy and google envy and things like that in the past because they have so much infrastructure like organizational infrastructure to do really cool things like this that i have never had at a company i worked at and so i've always had to like figure out what will work for us when i don't have someone that i can pay to be the full-time onboarding drill sergeant yeah When you don't have 100 engineering hires every week or something like that, I don't know the exact numbers, but yeah, exactly. And, and so I think it's, there's a risk that when you read about these processes, you're

like, man, we suck. You know, we don't do all these awesome things, but I don't think that's the case. I think Facebook is actually quite unique in this regard. Um, just because of their scale or yeah, because of their scale mostly. Yeah. And the other interesting thing is like the ratio of users to engineers at Facebook is just off the charts high. And it's actually one of the things they track.

And so they're like, this is how we justify having these programs. You know, when you have literally like 300 million, well not 300, let's say like a million users per engineer, you know, like that's pretty amazing.

And so, yeah, I've never worked at a company that had that. Maybe the other way around. A million engineers for one user. yeah so i think what i'm just saying is i'm giving everyone permission to not feel bad about their weak sauce onboarding process when it's not a six-week boot camp like facebook yeah this does seem like a thing that scales as your engineering organization scales cool so um one other thing i

wanted to say is that uh it's really important i think to onboard new hires especially junior developers with your HR department or HR representative, if you don't have a department to walk them through some of the things that are probably new to them, like health insurance and time off policies and things like that. Um, like what is a deductible? You know, there's a lot of people starting out in the industry who probably don't know what a deductible is. And it's really boring to read about that online. And it's great to have someone sit down with you and explain it and then look at your face and go, you look confused. Can I help you? And so we do that at my company.

We have our HR representatives sit down with them. And I think it's pretty helpful. But again, you risk the fire hose thing because there's all these new terms and stuff. Yeah, we do that by pair programming with the HR person. There actually is an onboarding presentation, but I've never seen it because I started before it happened. Yeah, yeah.

And one thing that surprises me is that our industry doesn't really have a best practice for this that people talk about. I've never heard anyone sit down and go, here's a good checklist that everyone agrees. Yeah, this is generally a good idea for onboarding new people at your company. Have you ever seen anything like that? I have, actually. Not off the top of my head, but I've read articles about that.

Oh, okay. Yeah, I'm sure you see the occasional article, but it doesn't have a name. It's not like Scrum. It's like, oh yeah, we do the Scrum boarding. Well, that's because there's not an industry of people being onboarding consultants that make their livings off of that. Oh, excellent point. What was the other thing I was going to say?

Oh, so I know some organizations, is it GitHub? I don't know. Maybe GitHub is the one that I first heard this from. Have this idea that you should ship something on your first day. Have you heard about this? Yeah. Oh, yes. What do you think about that as part of an onboarding process?

I used to strive for that so hard. I thought that was so cool. It was so rockstar. And then when we went to the three-day onboarding program, we just abandoned that idea. We said, that's actually not that important. It's more important that you get grounded. um before you start shipping stuff shipping stuff is cool but getting grounded is more important the three-day thing is the the one you've moved away from now yeah the one we moved

away from but we still don't emphasize like shipping on your first day like don't worry your code will all go to production in two weeks and that's fine like that's fine with me yeah is that just because of the way releases work at your company do you think well well it is but i mean um like if you don't get a commit into our revision control system on day one or two or even in week one i'm not that concerned about it yeah i just don't think it's that important of a thing to strive for i think you can have a great onboarding process without that i think uh if you did this it would avoid some problems it might create other problems though like it would avoid the problem of your your your process is so cumbersome and and it's just so hard to get

started that it takes you forever to get anything done um does that make sense you mean if it's like just too much information at the beginning if it's that or if it's like it's so hard to get stuff committed or oh we're just gonna put you on like this documentation task to get you up to speed or something like it forces you to be focused on delivering that and that is cool and i very much appreciate that where that's coming from i just i don't think it's that important to ship on day one myself just you know on my team it doesn't it doesn't seem super crucial okay But yeah, like it could be indicative of dysfunction where it's actually really hard to get code into production, in which case you should deal with that. Yeah, I guess that's what I'm saying.

That it's more like if you do this thing, it could have some good effects. You could have a good onboarding process without it as well. Yeah, I think you're right. Cool. But I also do have GitHub Envy too. Yeah, well, yeah, that's true. Everyone has GitHub Envy, right? whoever writes the coolest blog posts has the it's usually companies that are focused on developer

tooling or developer products that are very cool and then everyone wants to be like them and that may or may not be good i think that may be an episode for another day like this uh developer hero worship that sometimes happens um and then learning about you know just seeing like grounding that a little bit yeah oh a nice little teaser yeah accidental teaser all right Well, I think that means we're about done. All right. Thank you for joining us. And where can people hear more about us, Dave?

They should go to our Twitter page, twitter.com slash softskillseng, or just look us up. We are at softskillseng on Twitter. If you have a question you'd like us to answer or attempt to answer, you can tweet us publicly or send us a Twitter direct message. That is the best way to get in touch with us. Many of you have been doing that recently. We've been really surprised. When we started this podcast, James, and I thought we were going to run out of material

after three or four episodes but there is like months of material now in our backlog so thank you listeners for sending it in and it's great please send more questions it's not just like yeah it's really good stuff what's the right editor to use or something yeah that has not been asked yet so we'll just you could be the first yeah yeah thank you very much and we'll catch you all next week bye-bye see ya