Hi, everyone. Welcome to my talk. My name is Riaz Virani. I'm a freelance web developer and you can read more of my stuff at Riazv me. Today's topic, the thing I'm going to talk about is called five tips for success. How to thrive at your first dev job. And forgive me, this next slide is designed obviously for a talk that's live. But I do want to take a second and actually have you introspect a little bit because I'm assuming that a number of you especially are kind of from this perspective of like you actually are breaking into the industry. You either are about to start your first job, you're either in a boot camp looking to finish your first job or, sorry, finish the camp and get your first job. Or maybe you're just in the throes of the challenges I'm going to talk about in the first few months. If you're not, if you've been doing this for a few years, this is kind of your chance to just take a second to reset yourself and think about what your experience was like when you did join the industry and kind of break into your first job. I want you to kind of channel that energy because it'll help you empathize and help other people on your team as they're joining. So I'm going to tell you a little bit of a story. Right. It's going to kind of guide us through this talk. So I want you to meet a friend of mine. Her name is Ruby. She wants to be a developer. And yes, I am a ruby developer. So that's kind of the inside joke there. Sure, some of you don't like Ruby or rails or whatever, that's fine, you don't have to, but our character is going to be named Ruby. So Ruby musters up the courage to go join a software bootcamp. It's one of these bootcamps that is sort of fairly common. It's a huge source of sort of developers into our industry. One of these like three to six month things. She's a little bit nervous and anxious, as you would be if you're leaving your job and entering something new and paying a lot of money. Those of you might notice there is a boot on top of the building because it's a boot camp. That's what they did. So Ruby comes in and kills at the boot camp, right? And some of you may have actually felt that you struggled a bit in the boot camp, but in this case, doesn't really matter. Our character, Ruby, did a fantastic job and soaked in a ton of knowledge and information. She finishes the bootcamp and she is really diligent about working all of the things that the bootcamp and everything on the Internet is telling you about how to get a job. She does everything in her power to get a job. She builds a portfolio site. She's out at meetups, networking. I guess in today's age, if you're in a place that is mostly doing virtual work, you're networking on slack or other sort of online technology groups. She's doing open source projects. She's doing codecadas to prepare for interviews and she lands the job. She does an amazing job at her interviews and she lands the job. Some of you may have again, had more of a struggle to get to this part. And I don't want to dismiss how much of a challenge it is to get someone to trust you when you don't have a ton of experience to say, yes, I'll take a chance on this person and give, give them a shot and have them join my team. It is actually quite challenging, and a number of you probably are in that phase where you're trying to get it. But now here comes the next question. Now what? So the gist of this talk is not about everything we've talked about so far. It's that a number of people, especially now that I've been doing this for like twelve years, really struggle when they join a team. I'm a freelance developer right now, but in my past life I've been a CTO, I've been a project manager and run teams. A lot of new developers have come onto my teams. It turns out that there's a lot of commonalities in the struggle that first year devs experience across companies. Again, first year. I'm talking specifically about their first year in programming in general as a professional engineer, not necessarily just their first year at that particular company. I'm hoping somebody can sympathize. Yeah, there's a lot of challenges that kind of occur. I just don't think we talk about it enough. We talk so much about how to get people jobs, we don't often talk about the things that they need to do to succeed at those jobs when they break in. And there's a couple of skill sets that aren't even purely technical that I found consistently help people out. In some ways, I'm actually coming to this talk from the perspective of actually had a lot of challenges, just like everyone has when I'm also helping first year devs as well, because it's a really big adjustment. And I think a lot of the failures actually come from people like me and leadership who don't actually know how to onboard those people. But if you're a junior dev, you can only kind of control what's in front of you, what you can do. And these are some of the tips. So here are the famous five tips. Here's the meat and potatoes of this talk. I put kind of catchphrases around them and we're going to dive into each single one as we go along. The first one is ask and you shall receive. So the idea there is to make sure that you are not just struggling silently like there is a time and a place to ask for help. And knowing when the right time is is kind of an art that sometimes senior developers have gained over time. But a lot of junior developers, they just don't ask enough for help when they get stuck. Secondly, it's called right now, worry later. And that's really about not being afraid of your code. You're going to make mistakes, you're going to write a lot of stuff that doesn't work, and you need to have the courage to kind of just go through that process. Three is go deep, not wide. Specifically, this is a response to a lot of boot camps that try to, as a marketing pharmaceutist, teach you a lot of different things because you can kind of say, oh, I learned this. I learned how to do iOS development and python development and front end development and Ruby development, but it's not actually the right way to approach it. When you're trying to enter a company and make sure that you can contribute in a way that's productive and respectful of your team and for your own growth. Fourth, dont put your teammates in a pedestal. So the crux of that idea is to not assume everything that a senior developer tells you is actually the right answer. Most of the time, they're your peers. They're figuring it out as well. I've seen a number of times where I might give someone an idea when they ask me for help. Turns out it's a bad idea. And they didn't tell me when we kind of went through it, when they worked on it for a little bit because they were afraid to tell me I was wrong. And this just came from kind of the culture of that company, which causes a lot of problems because people actually need to be able to voice their opinions freely. The final one is more of a tactical tip. It's one of the few that's less sort of abstract. It's called pseudocode is your friend. The idea here is when you're joining a new company, you're starting out, you don't actually have the syntax of second nature of whatever programming language you're in and senior developers generally do. And so to separate out the stages of when you're programming into different phases, that'll actually help you get through the logic and then the syntax separately. But let's get into detail. So the very first tip, ask and you shall receive. So we're going to go back to our story. Ruby's going to join us along the way. She's our friend, of course. So Ruby gets a ticket, but she's not sure how to proceed. She's afraid she's going to do it wrong and be found out as a fraud. What does she do? So this is the classic, like imagine you're a brand new developer, you join a company and they're like, great, they do some onboarding, but at some point they're going to ask you to write some code and they give you a ticket and you're sitting there. Some cultures, they may pair program with you and that's great, but in many they don't. In which case you're sitting there being like, I don't know how to approach this, or you may have an inkling of how to approach it, but you're absolutely terrified of being found out as an imposter. And sort of impostor syndrome in the software world is a really common thing. And that probably should have been the title of this section. So here's a really important point. You cannot wait forever to ask for help, or you cannot just throw your hands up and give up. I've kind of seen people generally, when they're doing this wrong, oscillate on one of the two extremes. They'll get a ticket and every morning in a stand up they might be saying, I'm working on this, I'm working on this. Without telling anyone. They're really struggling and they have kind of just been thrashing around. They haven't really figured out how to tackle it. And the other one is they at some point get so frustrated, they come and say, I just can't do this, and they throw their hands up in the air. And that tends to be sort of the worst outcome. Also the fact that more time they spend on it now, the harder it is to ask for help. And therefore, like, you'd be kind of being, obviously, I haven't gone anywhere in three days and I've just been giving an update that I'm just working on it. Obviously the answer is to ask for help, but I want to kind of address a quick point. Usually whenever I do these kinds of presentations and I've been in the audience, there's an element in me that listens to sort of the proposal of the sort of soft skills thing to do. And there's always a hidden part of my mind that's kind of like, yeah, it's not that easy. And there's this sort of like secret internal link of what the argument is that doesn't really hang up. And the argument here is a junior developer could say, but won't I annoy people if I ask for it? Won't I be found out as an imposter? And there's kind of a very specific answer here, which is you have to ask, but you have to ask intelligently. And I just put a paragraph in here of what I would say if I was in that circumstance, which is probably the best illustration. Right. I'm just going to read it out loud. So let's say you're in a morning stand up. Hi, everyone. So I'm currently working on x feature. I'm still working through the right approach for it, but right now y seems the best. I'm going to keep at it for today, but if I dont make good progress, I'd like to grab someone else from the team really quickly tomorrow to talk it through and get me unstuck. So kind of think through what happened there, right? I didn't just go and say, I don't know how to do this, and throw my hands up in the air and ask for someone else to come and get involved and just sort of give me the answer. I kind of was like, look, I do need to do some work on this. I need to spend a little bit of time thrashing to poke at kind of the approaches I'm thinking of. As a result, when I do have, if I can't make any progress and I don't feel confident with the approach, whenever I do ask for someone's time, I can be like, okay, here is the problem. I thought this, I tried that. I tried that. I looked this up online, it's not working. Help me get unstuck. And I didn't also ask. Unstuck is a pretty specific word. It's not do this for me. I can't do this. It's help me get the next incremental bit of information that I need in order to move forward to maybe the next part of the challenge. Right. The next part of the ticket. And as a manager, this would be amazing to me because I'd be sitting there going, okay, so you've identified there's a problem. You've given me those information that right now you're actually struggling. So I'm already forewarned about that. You've given me a timetable in which you're going to work on it yourself. And then you've told me what your next step is going to be, which is not to throw your hands up in the air. It's to ask for a limited piece of help to get you to the next phase. And I'm like, you have done my job for me as a manager. Right? You will gain so many brownie points if you try this approach where you're being very considerate about how much time you're drawing, but also making sure you keep progressing and communicating versus doing one of those two extremes of either working on it silently and thrashing or just giving up too quickly. So next point right now, worry later. So this is a little bit of play on words and we'll go back to Ruby to kind of get an example of what we mean. So Ruby does the best she can and puts up a pr to the ticket we talked about in the last point. The next day, it's got 20 comments and has been sent back. She will have to start over. She's crushed. She's not even sure if she wants those job anymore. If you're someone, and again, if, you know, if you're more experienced, this happened to you, right? And if you're a junior developer, it's definitely happened to you where you think you've got it and you put it in and someone just shits all over your code and it just really crushes you. So I'm not going to really spend a lot of time on the point that it's completely okay to mark up a pr, but if you recognize someone's new and they may really be trying to get their confidence, you should probably include a note in there being like, hey, by the way, I know this is a lot. You still did a really good job. Let's just work on these and we'll continue to improve. Like, giving them that little pat on the back can be really dramatic, but let's say you didn't get that because it's, again, as a junior developer, not within your control. Here's my answer, and this is somewhat controversial. When I've kind of talked about this with other people, the thing within your control is kind of how you respond and the answer isn't be perfect. And the answer isn't, oh, just feel good generically. You have to kind of get an understanding of the fact that you are new. You're going to write a lot of mediocre code as you improve. You need to embrace it and just ask your teammates to embrace the process as well. What I mean specifically by that is like, interview examples. You think about classic ways to get good at anything. You're going to be bad at it whenever you start. If you're just starting in the industry as the first time you're really writing code in a professional context, that means most of the time you're not going to be doing things as well as someone else who's doing it for five years. That doesn't mean you're bad, it just means you're learning. Fitness is a good example. You cannot beat yourself up. If you think of fitness when you go into the gym and you can't do the pull up like someone else can, it just means it's part of the process. You need to embrace the process and not necessarily be upset that you're not meeting some standard you've set out. So here's the sort of like, little voice in the back of your head, right, thinks it's like, right, so I just do my job poorly, just like, write shitty code and that's somehow okay, right? And have everyone look me that I'm the weak link on the team. Not really your job. This is kind of all of our jobs as engineers is really to try. And if you're new, I know there's a whole bunch of personal emotion mixed up in that because you're also trying to establish your own career. But there's a very big difference between someone who's trying their best and continuing to improve, and people notice that. And the thing I put on here is like, shitty code is very different from flawed code written by people trying their best. It just is. I mean, I'm sure everyone who's been doing this for a while has noticed people who just don't care. And if you are also consistently showing that when someone does point out a way to make your stuff better, that you really respond, they'll give you a lot of leeway in the sense that you're not going to be constantly battling people's response to you as like, oh, you're the one who's just doing stuff, really. So don't be afraid of your code. Like, the biggest point here is don't be afraid. Whatever it is, just keep going, just keep going, just keep going, you'll get there. All right, point number three, go deep, not wide. So as I mentioned earlier, this is really a response to how sometimes I've noticed boot camps teaching way too many things or people on their own because there's such a plethora of things you need to do to learn DevOps to front end, to backend to whatever in the world of web development, they just spread themselves too wide at the start. So let's go back to Ruby continued. Ruby loves learning. At her boot camp they taught her seven programming languages and frameworks. She feels overwhelmed with where to focus on her new job. It all seems too advanced compared to her boot camp. I think what kind of happens here, this is really what happens. Boot camps and those tech zeitgeist if you're trying to beat up on the news, especially in the JavaScript world, there's a little bit of an excessive obsession with the new and excessive variety and it's kind of your job not to get sucked into it. Not because learning new things is bad, but most junior developers don't fail because they dont know enough of a diversity of things. It's because they don't know any one thing sufficiently well to be productive on the team. So they're kind of like master of none. And that's kind of where you want to get in the long run. But in the immediate term when you're just new, you want to be able to get really good at one thing, and sort of voice in those back of your head is like, well, if I do that, I'll never really be a fully routed developer. The answer is not exactly focus is important when you start, you get really good at things when you focus on them, and so you focus on one specific technology that your team needs help with and then specific expertise will give you the credibility and the ability over time to be productive. Like you'll learn the rest. And what I mean by that is like hey, you're a junior developer, they know that you're going to need additional time, additional support, but let's say you have a good example is like there's a lot of developers that are more backend heavy and then I'm thinking from a rails perspective, right, because rails is backend heavy and then they'll learn JavaScript in the front end really just because they have to to deliver their application. But usually they're not design experts, right? Most back end developers dont really like CSS, so they've kind of hacked things together or maybe just used bootstrap or sort of a theme and they really struggle with that. Well, it turns out maybe you specifically like CSS and you like design and you like learning about that stuff even though you want to learn everything else. Focus in that area. Talk with your manager, be like, hey, what if I focused here? I really cleaned up our css. Well, now your manager has this sort of foundation so that when you're interacting with the team, you have a locus of expertise and credibility. You can be productive and contribute. And now you've got all this time, all those other stuff that goes on in that team is going to get absorbed into your head right, over time. Because you're probably going to go from CSS to more and more into front end stuff, right? Because you're going to be executing features and then from there you'll expand more and more to the back end and then more and more to the DevOps, right. It'll always be that there's another challenge you can focus on. But if you're always in training and not really able to contribute to the team, that's going to cause them to have a much difficult or different opinion on of you. Because if you solve the CSS problem and then you ask for help, well, now it's like, no, this person was awesome. They did a great job on that. It is worth my time to try to teach them and help them. So that's a really good thing to keep in mind. So next point, don't put your teammates on a pedestal. We talked earlier about the fact that senior developers are not magicians. Right. Software engineering is an art. So it's a very different perspective than maybe some other things that have these very precise inputs and outputs. So don't assume they always know what they mean or that they've communicated it clearly, or that they wouldn't try the idea they gave you and then realize, oh, it sucks, and try something else. Right. So let's go back to Ruby. A senior developer gives Ruby some guidance on the ticket, but it's not working. What does she do? She doesn't want to disrespect the senior developer by doing it her. Hmm. So what do you do? I think here it's kind of related to the first point and it's really about communication. But you do have to have some courage to realize that you cannot force a square peg into a round hole. And your job, like your responsibility to the team, is not necessarily to not say, I don't know if this is the right approach. I'm trying this and it's causing a lot of friction. It's your job to voice the pain and friction that you're noticing. That is actually the most important thing you can do. Oftentimes what will happen is it turns out like whatever you're noticing, if you actually point it out, the senior developer is going to be like, yeah, actually, now that I look at it, it doesn't exactly work the way I think. Or the other most common one is, no, you misinterpreted what I said because developers are pretty bad at saying, like, speaking code. I actually kind of mean this. And you're like, okay, that makes a lot more sense. Now, here's something that's really important. The longer you wait to do this, like you say, you take the approach, you start working on it for a day, it's like clearly there's something off. You wait two or three more days to bring that up. Now you've got a little bit of a politics problem because let's say there's a manager who's given that senior developer the assignment to guide you through this ticket. If you wait really long and then those becomes a problem, that senior developer now has to cover their ass because they have to make the points like, no, you're doing it wrong. It wasn't that I didn't notice that you were trying the wrong approach for several days. Right. So the earlier you can communicate, the better benefit you're going to have. And that's why again, the answer here is communication. Your job is to communicate about the code across your team. And the final point, again, senior developers are not God, they're your peers. Tell the senior developer what you found and ask for clarification. Half the time it turns out their approach was wrong and they'll admit it. Right? So pseudocode is your friend. This is the final point. Now, this is a bit different than the other ones because it's really a tactical point versus a sort of like philosophical point, but it's something I've noticed a lot. So, Ruby, go back to Ruby. This is our finale with Ruby. We're going to say goodbye to her in a second. She's starting to feel comfortable, but she's still writing code slower than other devs and team. How can she be more efficient? So here's this kind of really unusual point. I haven't heard a lot of people talk about it. Write your pseudocode in comments and pseudocode. If those of you who don't know what it is, pseudocode is basically where you write literally words describing your code, it's almost like someone had to translate the logic you're putting in your code as sentences, like the way you would talk about the code if you had to explain it in words. So it could be literally what you're seeing on the screen, your pseudocode. So if you write that first because you're thinking through the business logic, then be like, okay, I think that makes sense. Now just translate it into the syntax of whatever programming language you're in. You're kind of separating those two threads. And the reason this is effective is if you're new, it's very likely that the programming language syntax is not second nature to you. I don't really think about syntax much at this point. Personally. Whenever I'm writing Ruby or Javascript, like the languages that I'm most familiar with, I'm really thinking about the logic. But if you're new, you're actually spending a lot of those extra cycles being like, oh wait, where does the closing parentheses go? That kind of thing. So if you can separate those tasks out, it'll actually make you more productive because it becomes two simpler tasks instead of one more complex task. So the point here is, syntax sucks. Senior devs have been writing code for so long, the syntax of code is second nature to them. If you're not there yet, separate the process of thinking about the logic and writing the syntax of the programming language as separate, and that's it. That is the presentation. For those of you that don't know, gravity exists on earth. I love Neil degrasse Tyson. And yeah, just going back to my contact information mission, if you really are interested in some of the stuff I have to say, there's other talks and podcasts and other things that I put online, things, some of the things I've written. You can find it all at Riazv, me and I occasionally, but not very often, will tweet. Riaz. Virani. Riaz, thank you for joining me and enjoy your conference.