Soft Skills Engineering - Episode 29: What Should I Do When Starting A New Job?

Episode Date: October 7, 2016

Literally the only episode that the advice “quit your job and get a better one” doesn’t apply. Dave and Jamison answer the question: What should I do when starting a new job?

It takes more than great code to be a great engineer. Welcome to episode 29 of the Soft Skills Engineering Podcast. I am Jameson Dance. And I'm Dave Smith. And we are your hosts. Did you know the plural of host is not hosts, it's actually hosti? Oh, I thought it was hostin. Hostess.

Hostesses. That's a thing. We have a comment from a listener. Do you want to read it, Dave? Yeah, sure. This comes from listener Matt, and he gave us this little comment, actually a story after listening to episode 24, which was about whether you should be a specialist or a generalist. And he says that at a former employer, a boss once told him that he needed

to become more of a specialist so that his boss could defend him to business people. And that what happened was they were coming across some hard times with the company and, you know, cuts were coming. And so he said, quote, he said that if he is facing cutbacks or defending raises or bonuses, he can explain the value of a specialist more easily this person is my best rest api designer for example which is key to our architecture or that person represents us with the ietf which is key to our strategy versus as a generalist that person is so versatile i can use them almost anywhere which to a business person sounds like i could replace them with almost anyone so this person is the best cog yeah they're the most replaceable that's their

specialty yeah so that was a very interesting perspective on specialist versus generalist and i should mention without saying the name of the company that he worked for it was a large company well known in the software industry and um i thought that was really really interesting perspective and it was once again a reminder of how my limited view based on my own experience is just such a small glimpse into the industry yeah i think it's a pretty solid idea to take everything we say with a gigantic like deer's deer lick sized chunk of salt knowing that it's yeah it's based on who we are and what we've seen yeah doesn't necessarily apply universally hopefully there are themes you can pull out that apply universally also one one way

to do this if you pick a small enough niche you can be a specialist in anything so if you just learn the emacs shortcuts really well you could be your team's top developer productivity advocate i am irreplaceable if yeah if you're just jumping through hoops have you seen the size of that guy's pinkies that's a little emacs joke there you could poke through steel with them all right i think it's time to read our first question i will do it okay this is from a person named mark and they say hey dave and jameson i am offended that they put dave's name first but i'll still read the rest of it anyways i'm going to be starting a new job next week can you

talk about what are some good and effective ways or approaches you take during the first month at your new job your first three months there etc also maybe share what you've learned in the past good or bad thanks so much love the pod love the pod it's spelled podcast i love the pod no way love the pod it was the best thank you so much mark that was that was a friendly joke i hope i didn't make you feel bad no way it was awesome uh yeah great question mark and one that is very timely actually because i myself will be starting a new job after nearly five years at my existing job in about two weeks i finally took the age-old soft skills engineering advice which is get a new job quit your job you know what i actually quit my job since we started this podcast oh boy what

what have we done i don't know uh i think the clear first thing you do is establish dominance we actually both agreed on this i my my strategy would be play it like a reality tv show look to the camera say you're not there to make friends um the camera is sometimes hard to find but you'll find it if you look hard enough i mean refer to the ceo by their name by their first name of course and talk about them to other people in casual conversation. As if you're best friends. Yeah. If you share desk space with people,

just slowly slide your stuff outwards until you command a larger amount of real estate. All these things signal status, and that's really what you're trying to do. Yeah, figure out who you think the most dominant engineer is already and figure out a way to remove them or or humble them right if you i think if you can reverse a binary if you if you can invert a binary tree on the whiteboard faster than they can then by default you are now the most dominant person on the team

challenge them to a whiteboard off yeah oh man those are terrible ideas jameson every single one tell me good ideas oh boy it is it is challenging to start a new job because everything is new and it's like it's like gravity goes the opposite direction you know yeah it's it's a great way to find out the experience i've had has often been i i only discover when i start a new job what things i do because they're genuinely good and what things i do because it's just the way things worked and there's there is kind of like it feels like you uh miscalculate how many steps are left and like take an extra step and get this weird jerk in your body it's that same kind of feeling

sometimes you mean on the stairs stairs on the stairs well it sometimes happens to me just normally yeah walking to the street no on the stairs i caught your metaphor i actually think the job, getting ready for a new job actually start, well, sorry, that was poorly worded. Starting a new job techniques begin before your first day on the job. One of the things that I've done is I will try to email or get in touch with your manager or someone on your team and ask about the various technologies that are in use on the team. And before you begin, try to study those technologies. You know, maybe it's like a framework or maybe it's a programming language. And just that way when you show up you're not just completely blindsided by all these new technologies

you can at least come in with a little bit of a foundation but you do have to be careful because like for example the current job that i'm going to you know they told me some the programming language that they're using they told me that the framework they're using um and then i just made some assumptions about build tools and i emailed the manager today after studying them for a while and said which build tools are you using oh they're like oh we use a homegrown thing for that i'm like ah crap so i just wasted time studying these two build tools but you know so but do do take the time i found that to be really beneficial that's a cool idea i like that idea of of studying up ahead of time especially if it's different from what you were doing earlier i think the the main

thing that i would want in starting a new job is to find the structure um and and what i mean by that is there's there when when people work together there's some kind of organization or hierarchy that springs up um sometimes it's explicit sometimes it's implicit you might find out that all deploys go through this one person and that'll like dramatically affect the way you work or uh that all the engineers have opportunities to make product changes whenever they want and that has other effects too but just kind of exploring and discovering the the human structure in the job not not to manipulate it or be sneaky or conniving about it at all but just because i think if you can find those things out it will um it will help you get stuff done which is your your

goal yeah totally well i think what you're saying is try to identify the process that's that's going on even if it's not well documented you know like they may say yeah we do scrum but jessica over here signs off on all of our builds you know and it's like oh that's not really part of scrum that's just something you have to figure out yeah yeah fine yeah find all the implicit things i guess i mean another obviously you need to learn the code base and that might be a whole different question how do you go about learning a code base although not quite a soft skill so maybe will pretend it doesn't exist i think sometimes learning a new job is like stepping into a dark room where you can't see anything and you have to like feel with your hands the shape of the room

and then you're going to bump into some things with your head and your toes and then you have to come out and like write down the shape of the room on a piece of paper based only on what you felt right like sometimes you walk into a new organization and you're going to bump into things right? Like, oh, I didn't know it was done that way here. And I would say that you can react one of two ways when that happens. When you bump your head into something, you can either like get mad about it and try to change it, which might be the right case in some, it might be the right course in some cases, but usually for the first little while, it's more, you need to spend more time understanding it and trying to map it out in your mind and understand why it's there. I think before

you start asking for overhauls yeah that's a great point i have a friend who um they're they're fairly senior and they get hired usually into leadership positions but they have this explicit rule that says i'm not going to suggest any changes for a month because it's so tempting to go in see a thing that you don't like and just be missing the context about why it exists and then you can go on some rants about why it's not a best practice or they're holding the team back or whatever and just kind of raise a big stink without knowing necessarily that maybe there's a good reason why that happened maybe there's some organizational scar tissue that this thing prevents from this this thing prevents a disaster from happening that happened before like you said

there's a lot of context and I think your goal is to learn that context and as a new person to the organization there will definitely be things you have new experiences from outside that you can bring in and there probably will be some things you can suggest to change but if you suggest those too early you risk kind of jumping the gun definitely really good point so mark asked explicitly um what do you do the first month the first three months have you ever thought about it in that way where there's kind of a checklist a timeline where you say the first day i will do x the first week i will do y that kind of thing or do you approach it more casually uh every job i've started has such a different onboarding process or non-process

that you just kind of go in on day one and you're like i have no idea what i'm about to walk into you know so no i've never i've never had a schedule how about you i haven't either but this question made me want one yeah i i wrote one down i mean day one you should get the code running whatever that means i mean if you work at facebook you're not gonna have facebook running on your laptop but step one get facebook running on your laptop all of it that would be a productive hire if someone could do that on their first day but something that you're going to be working on there's some way you're going to interact with it and run it to see your changes and and you should have hopefully you should have that up and running the first day yeah although at some companies day

one is just fill out all the paperwork and then day two get on your computer yeah the first day you have time to to do work things um again this depends heavily on the company and their deployment style but i i think it would be cool to deploy something your first week so whether that means check it into the version control system or actually deploy it live just have something it doesn't even matter if it's tiny or a readme change or whatever just something that you do that is handed over to other people just i think that can kind of break the ice i know that when i start i mentioned this before i worry that i suddenly have forgotten how to do my job and just getting getting something small out of the way first helps me um first of all

learn what all the processes are for getting that done but second of all just prove like oh yeah i can do this i yeah i can i can move this button that's well it'll help you shed some of the imposter syndrome that is probably inevitable with starting a new job because you really are an imposter right you don't know anything and then at the end of the month i have sneakily format all the source code to your liking uh that's where my checklist ends though i wish it was better i really like the idea of engaging in the deployment process as soon as possible now we should talk about that like for a web company that's going to probably mean starting the process to get something into production for a shrink wrap software company

it could mean just getting your code through qa and ready you know on the train for the next release even though it's not going to go on the next release and i think that's really important because that will force you to engage with the process and it will make it will give you first-hand experience of actually moving through the system and i don't know about you jameson but when i read about processes it's like oh yeah i think i could do that but then when you actually follow the process it's like 10 times more um like more retention knowledge wise yeah for sure so i love that one more thing i would say is i liked your metaphor dave about exploring a dark room i'm going to add to the metaphor that if you had someone to guide you through that room

it would be a lot easier to avoid the giant spiky pits every company has like crazy every successful company has crazy incomprehensible things that just look horrible and stupid from the outside and they're usually because of like legacy reasons and and someone that can help they don't necessarily need to be a mentor but someone that that you can ask questions to kind of a partner that you feel comfortable approaching and and getting the lay of the land from can really helps speed that up instead of you just bumping into things by yourself. Totally. So, so you need to find someone you get along with and that is open to answering your questions a little bit. And some places will explicitly set that up for you. Some places you just kind of

have to figure it out. Yeah. So questions, you mentioned questions, and I think that's something that you're very likely to have a lot of when you start a new job. And probably one of the most frequently, one of the questions you'll ask the most frequently is jargon. Like I heard this acronym what does it mean in the context of this company you know like i heard the word peanut butter and jelly sandwich and i think i know you know is that actually a sandwich no no that's that's the name of our build and deploy system you know like that's going to happen a lot and so one of the techniques i like to use and i know that other people also use is write down anytime you encounter a word or a term that you don't understand write it down on a piece of paper

or wherever you write things and then later um batch them up over the course of like a day or two and then ask people in batches hey can you help me define all these jargon terms so that you don't uh a you don't bother people like every five minutes you know what does that acronym mean what does this acronym mean and and b you actually get all the answers to your questions that's wise advice it's interesting that i think that i feel like this question we've repeated things we've said in other contexts so to some extent the stuff you do when you start a job is also the stuff you do to be effective at your normal job true um when you whether you've started or not it's i don't know i just feel like we've talked about the batching questions thing before

yeah yeah we've talked about that's all i can remember that we've talked about before i swear there were more well maybe maybe toppling the alpha engineer yeah we've definitely talked about the whiteboard battles thing before actually so maybe that's just a thing you do every so often i mean just because you're the top the alpha dog right now someone's going to challenge you you got to keep those whiteboard skills sharp one of the other things i like to do is be willing to volunteer for things even if they look scary because as a new developer um you don't even know what you don't know yet and sometimes you might be inclined to just kind of fade into the shadows and not draw too much attention to yourself. But I say volunteer for stuff. If you

know if the team lead is saying, hey, we need someone to work on this, raise your hand. And if you if you're not going to be able to do it, then you know, you could ask like, hey, do you think I could do this? But go for it, do things that will stretch you and that might make you feel uncomfortable. But you know, do it and just see what comes out of it. I think it's a great way to get engaged with a new team. For sure. And my final piece of advice, this is the last thing I have is when you start a new job, you should probably have the expectation that you're going to need to work more hours than a typical work week for you because you're going to be learning so much stuff and trying to come up to speed that I recommend planning to put in a little bit more

time than usual. Really? Yeah, I think so because it's just you got a lot to learn and you want to also be productive at the same time. But on the other side of that coin, it's important to manage expectations with your leadership so they know like hey i just want you to know i'm putting in a ton of crazy hours to just get up to speed but i don't plan on working this way forever forever you know that that feels dangerous to me because i i feel like the kind of organization that notices that you're putting in extra hours and is like oh yeah good work but not really looking at your output is is also the kind of organization that's going to expect you to keep doing that they're gonna be like oh why aren't you working that much like how come you're so lazy now yeah exactly i

don't know it just seems it seems scary and also i mean anyone that's hired engineers know that they they spin up over time and there are things you can do to be effective right away but but obviously you learn the existing code base more you learn the patterns more you you you grow So I find it weird that there's this expectation that what I, what I understood from your question is in order to be productive at the beginning, you need to put more time in because you're going to be less efficient basically. Yeah. But I don't, I don't think you have to be as productive at the, when you first start

your job is when you're at your peak performance. I don't know that that seems weird. That's definitely true. Um, I mean, I think that nobody is going to expect you to be contributing at the same level in day one as month six right i mean you're definitely you're definitely going to get better and faster and more productive but you also have a crap ton of stuff to learn at the beginning and so maybe it means you spend time at home studying things i mean maybe you're coming up to speed on a new language like we talked about and i don't know that's just kind of how i approach it i

i definitely can see the danger though like you might establish a precedent that could be pretty harmful so maybe you do it in secret maybe you hide under your desk with your textbooks and you study your programming language book or are you just i think you mentioned doing it at home right that seems reasonable like you just go home and if you're really concerned about um speeding up but you don't want to um create weird expectations then you just do it where they won't create weird expectations except maybe with your family it's a different question yeah all right well everything else to add jameson i don't think so i think we have answered this question question answered good luck at your new job mark you too dave by the way good luck at your new job all right so

that's it for today jameson how can people find out more about the show they can either go to softskills.audio and see past episodes subscribe uh read the glorious copy that dave and i wrote they can also follow us on twitter at soft skills eng that's where we collect our questions from so if you tweeted us or dm to us we will put your questions in the queue you should probably also follow at dj smith 42 on twitter that's dave's twitter handle yeah definitely follow me jameson feels bad because he has more followers than i do i feel great it means i'm better than you that's right that's what i've been taught uh you can follow me too i guess i'm at jurgason j-e-r-g-a-s-o-n thanks for joining us one more week thank you so much we'll catch you next week bye