Soft Skills Engineering - Episode 36: Unlimited Vacation and Enforcing Best Practices

Episode Date: November 22, 2016

In this episode, Dave and Jamison answer these questions: What do you think of unlimited vacation policies? How do I enforce coding best practices? Show notes, because Jamison is feeling ambitious: The Netflix culture slides we mentioned pylint, the linter Dave talked about

It takes more than great code to be a great engineer. Welcome to episode 36 of the Soft Skills Engineering Podcast. I am your best friend and your host, Jameson Dance. I am your second best friend and host, Dave Smith. It's like the friend that you invite to most of the things. No, maybe I'm not your second best then. Maybe I'm your tenth best. You're my first best.

We actually have a listener comment. Do you want to read that, Dave? Yeah, this comes from listener Steven, and he says, Hello, and thanks for letting me listen. To which I say, you're welcome. All you want. Also, you don't have to ask permission. Well, the files are hosted on Dave's server, so maybe you do need to ask him permission.

He says, I just had a couple comments on avoiding the avoidance problem that you guys talked about the last podcast. I feel like if I try to plan my day out really well, that i am more forced to do the tasks during the time i've allocated for example my eight hour day allows the structure of two hours of work 15 minute break two more hours of work then lunch two more hours of work 15 minute break then two more hours until the end of the day i feel that when i allocate that time to myself it really puts me on the spot to work on whatever needs to get done during that time so there you go there's a little avoidance avoidance technique from our

listener steven sure just adding a lot of structure yeah very structured which again that fits into that category of things which is like if your boss made you do that you would um write angry posts about them on social media but doing it to yourself feels like responsible and motivating cool yeah cool thanks steven yeah thank you uh this episode is also sponsored by dev mountain the coding boot camp we will hear more about them later thank you dev mountain yes thank you I did get the second Ferrari that they stiffed me on, so the accounts are settled. Let's go to our first question. Do you want to read it, Dave?

Sure. This comes from listener Michael J., and he's asking about unlimited PTO. PTO is an acronym that stands for paid time off. Or partial pterodactyl overflow. Do you know what pterodactyl starts with, Jameson? No. Well, no, it's okay. It's just pterodactyl overflow then.

Yeah, pterotactyl? Okay. Anyway. Because isn't it P-T for pterodactyl? I think pterodactyl. Oh, yeah. The first two letters are P-T. You got it.

Yeah. That would be lowercase T. Yeah. Well, maybe. Depends on how loose you are with your acronym requirements. We apologize to all of our paleontologists who are listening. Okay. so michael writes i have considered several jobs that offer unlimited pto but i have reservations

i like the idea that i could take longer vacations but i also wonder if that type of break would be frowned upon or deemed as taking advantage of the situation so unlimited pto where did this idea come from did it come from that netflix deck about the culture netflix culture deck uh that is a good because it's kind of like a meme now in tech companies it's it's like the default i feel like it's like the culture bible yeah well well no not the netflix thing specifically just it feels like the default policy for tech companies in well probably in small nimble hip startups right yeah yeah i've actually only ever worked as a full-time employee of companies with paid with unlimited paid time off oh really interesting so you have no idea what it's like to

accrue vacation and sick time and that will certainly not stop me from having strong opinions about it though so i have worked five years in an unlimited pto environment and about 10 years in a like a traditional vacation accrual environment i work now in an unlimited unpaid time off environment where if i am not working then it turns out no one will pay me that's right unlimited unpaid yep uh well what do you think you i mean so james and i are gonna disagree on this one a lot i think but personally from my experience at the company where i did unlimited pto i loved it i loved it because it meant you just never had to work right yeah i didn't i didn't go to work for five years gotcha unlimited i found the loophole in your little plan

my my company's policy actually was that they had no vacation policy like that was officially written in it's like or not written in was that there is no vacation policy and which of course means effectively unlimited pto um no one i don't think anyone that i was directly familiar with ever abused the system so badly that it came back to bite them but um i do know i did notice that there was quite a bit of variability between uh some people's vacation time and others you know of course i noticed that even at the traditional accrual places as well sure you know some people just like to bank the vacation and some people like to take it i mean so you you liked it because of the freedom and the flexibility right there's not

well bureaucracy you have to go through you just kind of talk to people and well no no that's not the reason empirically speaking i took more vacation like per unit time at uh my unlimited pto place um i took a lot of vacation like you know i i don't know if i did you ever count it up yeah i was trying to think if i've ever actually tallied it up but all i know is i looked back and i went holy cow i took a lot more vacation now than i did when i was working at a traditional vacation accrual place um yeah i don't know i don't know if i could put a number on it but it definitely felt like i was taking more maybe maybe maybe that's the secret that's the secret everyone thinks they're taking more when they feel guilty for taking vacation yeah so maybe i'll talk

about two experiences i had i worked at one company unlimited paid time off and i hardly ever took any vacation and that was kind of just the culture there people there didn't take a lot of vacation the the leadership didn't take a ton of vacation and that to me gets to the problem of unlimited paid time off it's all implicit if they say unlimited you kind of just look at your surroundings to see what the cultural norms are like it takes an explicit thing which is you get this many days of vacation and it takes away the explicitness and then you just have to intuit it based on context and there's some number where if you take more than that people are going to be mad at you but now you don't know what that number is anymore because it's gone

so in in in this job that i don't i don't i mean i never pushed it so i guess i don't know what the number was but the the expectation set by the behavior of my managers and and leaders was you just kind of work a lot and don't take a lot of vacation and it's super chill when you do like you just say hey i'm going on vacation and it's fine no one was mad or anything but that just didn't happen very much whereas if you had an explicit number of like two weeks or three weeks of vacation or whatever then you just know you don't have to worry about like are people going to be mad at me is this gonna cause any problems it's just like this is the policy so i can do it Um, at my last full-time job at, at Kuali, the vacation policy was also unlimited paid

time off, but the CEO actually was, um, was a good example of actually using that vacation. Well, he was horrible because while he was on vacation, he worked pretty much nonstop, but at least he said he was taking vacation, but he did go on. Yeah. We, we gave him a lot of crap for that, but he, he did go on vacation a lot. He went on like a three week long trip with his family in the summer and stuff. So in that case, um, people took more vacation in general because even though the policy was the same, the implicit culture around it encouraged it a little more.

So I think it, it can be good and bad and done poorly. It can create this weird negative feeling of pressure to not take vacation. Like at the first company I talked about, I felt a lot of pressure to not let my teammates down and not kind of leave them in the lurch and and if i just bounced i felt like i was leaving them in the lurch so yeah i don't love it the most again i haven't worked at a place with explicit vacation policies though so maybe i'm just wrong i mean it seems like you could do that in a horrible way too yeah um yeah like even if you are accruing vacation on a traditional schedule you could still have a culture that discourages people taking vacation right yeah that's very

true but at least they have to pay you for it yeah and that that's an important point that i think some people fail to realize at interview time when they're considering taking a job with unlimited pto oh yeah they do not pay you that's right when you quit you will not get a check for your unspent vacation time because you could be like hey i want my unlimited pto check yeah infinite dollars this is probably a good question to ask either way but you should try and feel out okay here's the vacation policy what do people actually do like how many weeks of vacation did you take last year because if it's unlimited paid time off but no one uses it that's very different than unlimited but people actually use it a lot yeah exactly and i i think a good

question to ask during the interview process is to ask each person you meet do you take more vacation or less vacation than your previous job and then ask them if their previous job had an explicit vacation policy and just see and that'll tell you a lot I think yeah I mean back to the implicit versus explicit thing I think implicit things in general can be more prone to abuse by bad actors either people that abuse the unlimited vacation policy to take a lot of vacation or like weird pressure to not take vacation at least if there's an explicit vacation policy you can kind of point to that to back up your your i don't know your idea when you want to take vacation i mean there are definitely trade-offs either way but you you should know what what the facts

on the ground are about the vacation policy if the policy is like a big shrug like i don't know we're super loose and hip here there's there's something behind that and you should find that out definitely um i i'm having this thought and i don't know if it's real so you tell me jameson but i wonder if people who struggle with ambiguity would also struggle in an unlimited pto situation yeah that's what i was trying to get at and you are smart so you said it explicitly yeah i put it explicit versus implicit i think you're totally right um and i think everyone would struggle with the policy if there's a bad culture about it you know but um but even if there's a good culture you might still struggle if you're not the kind of person who thrives in

ambiguity yeah if you're if you're worried about job performance or kind of making a good impression or i don't know i could just see it being tricky if if if things are not magically amazing all the time well that's all i had to say about it i had a great experience with it and my favorite part was that uh about two months after i got hired at my last job we had a baby and i needed it to take some time off and i was super worried that i wouldn't be able to do that but because there was no accrual rate i just took the time and uh it was great like no problem i didn't have to like go into negative sick time or whatever which i have done at other jobs you had to donate blood to the company to make it up yeah um that's so that was great so there's definitely upside to it

because it's the only policy i've experienced it's literally both the best and the worst vacation policy i've ever seen so that's all i got there you go best and worst question answered question answered all right i uh i will read the next question okay this is from listener hugo how do you enforce coding best practices i'm growing frustrated fighting for more readability in the code separation of concerns less if else is etc when i feel like my team doesn't care or doesn't think it's as important as i do how do i defend software best practices if my team hasn't read books about it or thinks those ideas are only fluffy how do you this is like the classic question of how do i influence my team to do something

if they don't think it's a good idea yeah and i'm not like in charge of directing the team you know attack ads about the code no there was i've heard about that done for real like uh oh what was it i think i was listening to an interview with a very experienced developer who was talking about how uh someone on their team would write like weekly emails um that highlighted some particularly bad code and one time it was his and he just felt like crawling under a rock it was just terrible experience um and i think they they discontinued that practice eventually but yeah anyway that's not how to do it i think but i'm just i just have this vision in my head

of like hilarious i don't know voiceovers with dour music behind them and like 15 nested if-else statements the leading cause of bugs in this code i don't know like a political like a political ad yeah political attack yep but about the ternary operator i would say that if you're asking for this you really need to understand why you're asking for it um and have like some real solid evidence behind it you know if you can point to production bugs for example that these coding practices would have prevented that speaks volumes over hey i think it would be easier for me to read this code if it was formatted this way yeah that's a that's a huge point that you want to be super careful you're not conflating your preferences

with best practices i know that in past times in my life i have been guilty of this i just read a blog post that seems really cool and makes a strong argument and then i'm like i want to be smart i want to have an opinion and then i just go find a thing that doesn't match that blog post in our code base i'm like this is garbage it's broken and like then that adds to my power somehow the next day you come in and you're literally one inch taller yeah uh i'm not saying you're doing that at all but but it can be tempting to say like i don't like it therefore it's bad but you want to make sure it actually is bad writing code is so elusive because i i myself will look at the code that i wrote even just a year ago and code that i thought at the time

was written really well and just think this is garbage you see that's how i know i'm a better developer than you because when at the time i write code i'm like this is garbage i'm a year ahead of you it takes me a full year to come to the same conclusion that you come to in mere seconds yep uh so how do you well do we want to get into discovering if something is an actual best practice or do we want to just assume that there's some set of those um oh boy i mean well i think you hit it on the head if you when you said if you have data like you can point to production outages that this would have solved a lot of that can be around operational stuff or testing of some kind or like patterns in code that cause it to be less readable so it's easier to slip bugs in

or something but some kind of data point either from experience or or stories or something you just make up i guess oh yeah well and this this will depend a little bit about on your environment like when i was writing a lot of c++ code there were very clear guidelines like a big one was uninitialized variables you declare a variable you don't put a value in it the value is going to be just some random crap like it's if it's an integer it doesn't default to zero it defaults to whatever was on the stack before you got there and that led to all kinds of runtime bugs and it was like okay you know even the compiler would warn you about that stuff and so like in those cases basically the crappier your language is the more imperative it is that you do these things and

the easier the easier it is for you to find examples of these things gone wrong you know and i think no c++ developer on earth would argue that those aren't valuable uh things to fix you know yeah and um and yet you know we have we take this argument all the way from like the very basics of this is going to cause a crash to i don't like my curly braces on this line you know on the same line with the if statement and somewhere between those two things there's a point where you should stop stop enforcing the practice right yep you were you were just saying that you know maybe we assume that you've these practices are right and or rather that you've already settled on them and that the ones you've settled on are actually correct you know like it's

a pretty big assumption yeah i think if you feel incredibly strongly about best practices and you have a giant list it's probably valuable to pare that down a little bit if there's this much resistance to it to kind of the core things that you think will be the easiest to adopt and add the most value instead of just like we have to rewrite every single file to fit this giant long list of things so making it incrementally adoptable is is a big part of it yeah that's a big part although that can be hard um like i'll give you an example of when i started my last job about five years ago we had uh it was python and we had about 9 000 pi lint errors that's the one of the linters that you can use on python code and i remember thinking wow why do we even have this you know it's like

9 000 errors this tells me nothing right um and i i remember i took a week like literally a week i was i actually okay this is gonna make me sound really stupid especially in light of our last conversation but i took a week um uh away from work and just in my off time i would just kind of chill out turn on some music and crank through some of these errors and fix them and also change the rules to be you know to throw away the the ones that were just too too pedantic and over the course of that week i got them all eliminated got us down to zero and then we could actually put in place a zero tolerance policy where we could say look you can't commit code that has a linter error and and at that point we could be pretty productive but until that point it was just

so hard to even see any value through all that noise that's a very concrete benefit of the unlimited paid time off policy it fixed all your linting errors that was unlimited paid time on now we know why you took so much vacation you're secretly rewriting parts of the stack it's like paid time refactoring yeah so at kawali i worked with a guy who was very experienced had led a lot of teams had run a bunch of different projects and he came in to to lead this new team at kawali and just put his foot down and was like this team has 100 test coverage on everything we do no matter what and there were a bunch of us that were like but all this stuff about why it's not effective and it doesn't truly make your software better and like we had all these

arguments about it and he was like i don't care in a very nice way he's a very nice man but he was like so he didn't actually he didn't actually groan no no he was like i've done this on several projects it allowed us to move way faster you guys have some uh performance issues that that i have not seen in projects that did this and he had just this he had this wealth of experience to fall back on to back his idea of best practices up um and it actually ended up a couple people that were against the idea ended up working on that team with him and came away totally convinced of it so wow if if you have strong data like that well strong anecdata i guess where you can say i i have done this and it totally worked and it's the solution to a problem you're having right now

that can be really powerful strong data or at least a really compelling storyline yeah and just you're a good storyteller yeah along those lines though you know people like this developer that you're talking about he has probably had this conversation a dozen times in his career about yeah which practices are are the ones we should enforce you know and so i think you need to be careful when you approach this situation especially if you're really junior and you're like hey i read this blog and it's got all these revolutionary ideas for coding best practices you know and this other developer might be on your team going look i've had this conversation 10 times you know and it's like all these ideas that you think are revolutionary we've talked them all through i've

tried them some of them work many of them don't you know and it's like you need to be aware of that and i think the best thing you can do on your team in this situation for this listener is to talk to the other developers and understand why they're opposed to the ideas. And maybe they have valid reasons, maybe they don't, but you need to know, I think. Because as you approach how you're going to pitch this idea, knowing that will help inform how you do it.

Yeah, this is hard to do as a more junior member of the team. I think you're right. It definitely helps if you have some kind of respect or leadership on the team, because it's a lot easier to just say, like, trust me. And then people will trust you because that's, that's basically what you're saying, right? There's, there's so much intuition and software is so fuzzy, right? People will quote these random things that they think are facts that are just totally

made up or totally specific to someone else's company or code base. Like everyone can find anything that convinces them of the thing that they think is true. So at some point you just have to like count on people thinking that your ideas are good. yep that's a very depressing way to think about it now that i said that it is but one of the things that i love doing is putting in place some kind of measurement so that you can have a before and after you know like in for example in the case of the c++ uninitialized variable thing like it was a no-brainer our our uninitialized variable bugs went to zero when we started initializing all of our variables yeah did we solve all bugs no but we certainly reduced

that class of bug to nothing um and maybe we just traded them for new kinds of bugs but at least you know hopefully you have the ability to look at your code six months after you implement these practices and then decide whether things are better and you just initialize all the variables to this like random memory address problem solved we never have uninitialized variable bugs now we have some seg faults though i've also found teams to be more receptive to ideas like this if they see that there's a path to evaluate whether it's good you know in in the future and they can see that this is like a pilot and it's like wait we're gonna learn together and together if we can see that it's not helping then we'll throw it out you know like it's really easy

to throw out best practices a lot easier than adopting them yeah it's yeah the culture of the team is so important to this because any team can make any best practice fail if true if they want it to right if they have decided it sucks then it is gonna suck um so there is a lot of kind of empathy and understanding and working with the team to make them open to the idea that there are things they can do to improve their lives and kind of add some hope if they're just in despair about everything and there's a lot of cynicism and everything sucks and it's the worst then you're going to have a tricky time absolutely and in that case you should invoke the old soft skills engineering standby rule wit your job and find a better one yeah cool well has the question

been answered i believe the question has been answered sir you are welcome that's a good question and i would love to know how it goes yeah please let us know well jason can people oh that was a question collision yeah you go first i was going to ask you what can people do if they want to find out more about movies playing in their area oh there's probably some apps for that well we'll add a section to our website on that if they want to find out more about the podcast they can go to soft skills.audio we have a bunch of past episodes there we might have comments soon someone added a poll request to our website yeah comments dude shout out yeah thank you kind stranger um the magic of the internet i was gonna look up

the name here great conversation on twitter where we were saying wouldn't it be great if we had comments so listeners could could talk to each other about each show and this one internet stranger named vermillion one submits a poll request to add comments to our website totally awesome uh speaking of twitter you can follow us on soft skills eng that is also a place you can go to submit questions or just kind of yell at us there's also a form on the website where you can submit a question if you're not on twitter or you just want to give a bunch more detail and there are probably other things that i'm forgetting um you can spin the wheel of fish on our website what that's a pull request that hasn't come in yet like a wheel made out of fish

Yeah, like it's got different kinds of fish on the wheel and you spin it. To what end? That's a movie reference, actually. And if you don't know it, then we'll have to talk later. Okay, cool. Well, I'll find out what that is, I guess. And thank you again to DevMountain for sponsoring. You can go to softskills.audio slash DevMountain to show that you both love us and are interested in them.

That would be great. All right, we'll catch you next week. Bye-bye.