 All right, everyone. Before I start, I need to enlist you in helping me fulfill a dream I've always had, but part of fulfilling that dream requires that you all stand up. So I've always wanted to walk on stage and have a room full of people standing and cheering for me. Perfect, thanks for fulfilling my dreams here in Buffalo this morning. So my name's Eric Steens. I'm from Minneapolis. I work for a shop called Software for Good. We focus on projects we think are making the world a better place. I'm happy to talk to you more about them later. And if you're on the Twitter, I'm at mutual arising. And this talk is going to be about being a junior developer, about how to be an awesome junior developer, about how to mentor junior developers, about how I became a junior developer. So I'm interested, before I get into it, too much who in the room identifies as a junior developer or aspires to be a junior developer? Awesome. And who in this room is a senior developer that mentors junior developers or has junior developers on their team or works with junior developers? So I think this talk will be relevant to everyone that just raised their hand. If you didn't raise your hand and you want to go get coffee, it totally doesn't offend me. Feel free to do that. I don't feel bad for starting with this now because Sarah started with it yesterday. This is my GitHub contribution graph. Of course, you can see on the left there is time I was at Bitmaker Labs last year, which is a boot camp in Toronto. I'll talk more about that in a minute. And on the right in March was when I got hired at Software for Good. I started pushing code to production on day one and have been doing so ever since. And in the middle is my first warning to aspiring junior developers if you're leaving school or a boot camp and you're looking for jobs, don't just stop coding for three months. And I have a secret. As BJ mentioned, this is my first conference talk. It's my first tech conference talk. And yeah, I came down last year and loved the conference so much that when the CFP came out this year, I happily submitted a talk. So I wanna talk a little bit about who I am and how I came to be here. And this will be brief because I know you didn't come here to listen to me talk about how I came to be here, but I took a rather circuitous path to being a developer. I actually have a background in sociology and social work. I have a master's in social work. I spent about 15 years working in the nonprofit field. And most of that time is a racial justice researcher working around structural racism and land use policy. And I also ran a community center in inner city St. Louis for about three or four years. So yes, that means according to Tumblr, I am a highly trained and professional SJW. So about four years I got laid off from the nonprofit I was working at, which is unfortunately all too common. And I decided to strike out on my own because one thing you might know about small nonprofits or might not know is that they rarely have the budget for an IT staff. So what happens is the one person on staff that's the least afraid of technology gets to do all the IT work. And for a number of reasons that happened to be me, I had been doing kind of static website coding and Dreamweaver and Frontpage since the mid 90s and I helped work at the hardware and software support center in my undergraduate and graduate school. So I kind of did everything for the small nonprofits from setting up printers to setting up our network to building small websites to setting up donation systems. So I decided to strike out on my own and open up a solo consulting company specifically for small nonprofits that don't have an IT staff. And I also stumbled into a job as the web coordinator for an international mental health nonprofit which was running a rather large Drupal site. I actually don't recommend being the web coordinator for a large Drupal site if you don't know PHP. It's fairly painful. But somehow I got us from Drupal 5 to Drupal 7 and I had this consulting company and was doing everything from setting up online donation forms to doing the aforementioned printer fixing and I liked it a lot. And I ended up during this time building a lot of the same kind of brochure where WordPress sites for these small nonprofits over and over again. And I got pretty good at ripping apart a WordPress theme and putting it back together. And I liked giving my tech skills to nonprofits but it was just not satisfying anymore building the same WordPress site over and over and skinning it a little differently. So I decided I was going to become a coder and I looked into maybe going back for a CS degree and that was totally impossible for a lot of reasons. So I ended up at Bitmaker Labs which is a boot camp in Toronto last fall. It's a three month Ruby and Rouse boot camp kind of follows the mold of a lot of other boot camps. Happy to talk to people about the good things and the bad things about the boot camp model of learning if you're interested. And I came out of there and of course the first stop on my journey as a junior developer was getting hired. So this is kind of my first big piece of advice for people in the room. And this goes for senior developers and junior developers. We have a tremendous amount of hiring power and hiring privilege in this field. In all my years of working in the nonprofit industry no recruiter ever called me and said, hey I've got this great opportunity working with at-risk kids and there's unlimited paid time off and there's a ping pong table there. It just didn't happen. So we have a tremendous amount of hiring power so really I want to encourage you if you're going into interviews as a junior developer don't think of it as an audition. You're not going to write code and have people hold up a sign that said that code is a two. Really think of it as a mutual meeting to make sure that your needs are being met and their needs are being met. And first and foremost what I mean by that is make sure they actually want to hire a junior developer make sure they're not just looking for a kind of crappy senior developer that they're just not going to pay as much as their senior developers. So make sure that they've thought about mentoring make sure they've thought about onboarding if you're a mid-career if you're kind of a mid-career switcher as I was make sure that they're excited about the other skills that aren't just development skills that you're bringing to the table and that they have a plan for using them. In my case I asked about all kinds of stuff I asked about what their support for my learning was going to be asked about what their pairing and mentoring culture was going was like asked about what their commitment to diversity and social justice was. I asked a lot of things you may have 15 other questions 15 other priorities and that's totally fine but I really want to encourage you to be really explicit about what your needs are and think of it in terms of if this company can meet your needs not just if you can meet their needs. So I got a number of job offers anecdotally I got a lot of job rejections too but anecdotally every place that I pair programmed as part of the interview process with either the CEO or the CTO or a senior engineer offered me a job every place where it was just a standard interview process turned me down for a job. So I really want to encourage hiring managers in the room if you're not doing it now really think about pairing with people as part of the interview process especially like a half day few hour pairing session it's a really great way to get to see what people's skills are beyond trivia and you can make them comfortable you can help them out. It works really well for me. And I eventually took this job at software for good I'm a full stack developer there which brings me to my first story which is about my first day and there's actually no emoji for nervous which surprised me but so I'm showing up for my first day and I'm half convinced more than half convinced that by the end of the day I'm going to be fired for not knowing how to code which I'm sure some of you have been in that position as well. But I show up there and I meet with the project manager and my boss and they say, okay Eric we have this project we'd like you to work on it's a rescue project so some of you might have little warning bells going off in your head already it's a rescue project it was this app that did a ton of stuff but one of the things the app did was it collected a bunch of data did some things to that data as apps tend to do send it off to an API got the response back and then built a nice PDF report from the response and email it to some folks and they said, you know this API has changed it's gone from version one to version two we want you to go in and collect the new data that needs to go to the API and reformat the API call and reformat this report that comes back so I thought to myself, okay I'm not entirely clear on this API business I know what an API is I don't really know how we call one I'm assuming that the PDF stuff is just a view but I know how to add fields to models so I'm gonna start by adding these fields to the models so I dig into the code a little bit and there's a parent model and there's about 30 children inheriting from this parent model so a little bit of a God object maybe and I get into the code and that's probably too small to read but it doesn't matter because it's very unreadable code anyway I get into the middle of this model and method missing is overridden and it's overridden I have no idea what it's doing I can't read the code I can't figure it out so I think to myself, okay I'm just gonna go to the schema, right we have the schema in Rails I'm gonna figure out where all these attributes live so I can figure out how to change them so I go to the schema and this is the entire schema for that model minus the timestamps there's one field it is a text field it is called data it cannot be null it turns out that 100 attributes are living inside this data field as a giant serialized hash and method missing was being overridden to be able to get and set these attributes and at this point, again I'm not, you know I don't have much Rails experience at this point I'm fresh out of a bootcamp but I'm thinking this is not a very Rails-y way to store 100 attributes in your database so I figure, okay scheme is not helping either I'm just gonna go to the tests and figure out how they're getting and setting these attributes of course there are no tests so I go back to my mentor we're about, I don't know it's sometime after lunch now so I go to the senior engineer I'm kind of pairing with on this project and basically say, okay I have no idea what's going on we sit down and go through the code for a while together for the rest of the day make some sense of it and basically decide that the entire first two to three weeks I work on this app all I'm going to be doing is writing tests for kind of the existing functionality in these models and documenting how they work before I change them so these are my two primary skills for a junior developer two primary skills you should be instilling in your junior developers I think as a mentor is testing and reading code and for me they go hand in hand there's this nice quote from SICP about readable code I haven't actually read SICP but it's a good quote I don't feel bad about this because evidently neither had been interestingly enough I found writing tests for someone else's code is a particularly nice way to read it and so I would encourage mentors out there if you're looking for homework for your juniors give them a chunk of code and tell them to write unit tests for it it's a particularly good way of practicing testing and a particularly good way of practicing kind of navigating large code bases because going from working on toy projects to working in a giant code base is really it's a whole new skill to be developed in terms of how you read and navigate a code base that large so mentoring I feel strongly about mentoring I actually feel strongly enough about mentoring that I would suggest that if you can't mentor a junior developer don't hire a junior developer it's actually not fair to that junior developer it's not fair to the other senior developers on your team that are going to be working with that junior developer and it's not fair to your clients everyone kind of loses so I want to talk a little bit about ways to be a good mentor and I have some mentoring rules and some of you may recognize these rules these actually aren't mentoring rules they're the Hacker School Code of Conduct rules but they work very well for mentoring except for one maybe no backseat driving you should possibly backseat drive if your front seat driver is about to drive you into a wall that is part of being a good mentor but there's a proper way to do backseat driving and that's this just don't ever use their keyboard don't take the keyboard away if your junior is driving don't ever take the keyboard away from them just because you're a little impatient or a little frustrated or you think I can just code this for them and they'll see what I'm doing and they'll learn it because they won't and it's kind of demoralizing the next thing I want to talk about is code review code review is I think the single most important way for me so far that I've gotten better as a developer our workflow at SFG actually is we submit all any code that's going to master has to be submitted in a poll request no matter how small and you're never allowed merging your own poll requests so every code has another pair of eyeballs on it and as part of that eyeballing we do code review and I kind of made it explicit upfront that I wanted the code review not only to be used for making sure the code was all right but really be used for my learning so I want to talk a little bit about bad code review and good code review in terms of encouraging learning bad code review is basically not getting the balance between being too specific or being not specific enough I've found too specific is obviously writing code for them in the code review that's too specific it's kind of the same as taking their keyboard away from them not being specific enough giving the code review comment like this needs refactored okay this needs refactored if I knew it needed refactored I probably wouldn't have submitted it that way if I knew how to refactor it I wouldn't have submitted it that way in the first place anything mean of course that should go without saying but part of programming is laziness so we tend to be economical with our words so if you're doing a long code review it can feel a little off-putting if there's just line after line after line fix this, fix that we talked a little bit yesterday about kind of giving positive regard for effort people have put in so sprinkling some compliments in your code review can really make a world of difference these are actually statements I pulled out of code reviews I've gotten in the past couple months that I thought were particularly good the first one, compliment sandwich right off the bat great job getting this feature to work but you could probably refactor X and Y into another object so to me this is kind of the perfect balance of specificity kind of tells me what I need to look at it doesn't really get me all the way there but it shows me where to look to get the code to a good place of course pointing out incomplete test coverage another thing that's really helped me is when people point out that there's a more idiomatic way of doing something in Ruby or there's already a Rails helper that does what I'm doing my favorite example of this is my code in the code I was writing when I first got there I was often doing a lot of nil checking and then someone was like hey there's this method called try in Rails that does exactly this and now I use try all the time and I love it and lastly what I call a Socratic code review there's one senior engineer I work with a lot that likes to just ask questions in code reviews so questions like what's gonna happen if we pass nil into this method where does it blow up so just asking questions that kind of point towards ways that the code needs to be improved I just wanna say nitpicks are great readability is important style is important definitely point out trailing white space improper indentation just don't do nothing but that and have your juniors do code reviews as well I do code reviews every day obviously if it's mission critical business logic maybe you want a senior pair of eyeballs on it as well but I learn a ton from reading my coworkers code and I find a lot of things that can be improved in it if you're not working somewhere that does code reviews I highly recommend Exorcism most of you have probably heard of it if you haven't it's kind of crowd-sourced code reviews on practice problems it's a great site you should check it out Katrina Owen and some other people put it together just gonna talk a tiny bit about pairing because sadly we don't really do it we don't have a pairing culture we're trying to change that I'm trying to change that I found pairing to be really helpful in the past but we don't do a whole lot of senior junior actual pairing two people one keyboard but we have started doing junior pairing and I think letting your juniors pair together is amazing because they're rarely going to have the same strengths and weaknesses and it's kind of like a force multiplier effect where they're way more productive and it kind of just builds team cohesion so I have a little bit left but I want to stretch so I'm gonna have a little 10 second intermission here and lead into a story about a side project I really like soccer and as some of you may know the World Cup was this year and every time the World Cup rolls around some friends and I get together and do a fantasy draft where we draft teams and players and get bragging rights depending on how things go and so we did that this year and we got to the end of it and started entering all the data into a spreadsheet and one of my friends said hey Eric, you're a programmer now can you make something that just does all this automatically that knows the score of every game as it happens in real time and updates all these points and this is about three days out from the start of the World Cup and I say no no I cannot do that maybe in another four years when I'm a better programmer but I'm laying in bed that night and I thought to myself I know web scraping I know the state is out there there's actually no reason I couldn't do this so I literally got up at like three in the morning started hacking on a scraper and in a couple days I had this scraper working that was the first day of the World Cup and the games happened and the scraper worked and we had this little website called bragging rights and it updated everyone's points and I was in first place based on points and I was feeling super awesome that I did this so I was at work and I started telling people about it and my boss said well that's really cool have you ever thought about turning it into a full-fledged API and open sourcing it and opening it up and I said no I don't know anything about building APIs the World Cup has already started there's no way I could build it in time it's not all I don't think people would use it anyway and he was like well why don't you think about it why don't you take the rest of the week and work on this API and if you get somewhere with it great we'll throw it up on one of our servers and host it during the World Cup and if you don't get anywhere with it don't worry about it so this is part of encouraging failure if it doesn't go anywhere don't worry about it but just take the rest of the week and work on it so I did and I ended up building as far as I know the first free open-source real-time World Cup API that had everything from goals scored to cards to substitutions to obviously the results of the game and I submitted it to Hacker News and it went to the front page and then it became the most trending Ruby repository on GitHub and then it had 300 stars and a bunch of forks and I don't say this just to brag although I do say it to brag a little bit because I think celebrating junior accomplishments is really important it really provides confidence to go through all the times every day where juniors feel like I just can't do this there's no way I can figure this out I can't do this I should pick another career but I bring this up because I learned a ton I learned more in this week than I probably had in like the two months previous I learned how to build an API I learned a ton of stuff about JSON I learned how to use Rabbold for templating I learned that when you have a popular open-source project every person in the world makes a feature request and no one writes code and makes a poll request except for one person who submitted a poll request and fixed a time zone issue for me which I will be forever grateful for because time zones are really sucky I've always heard time zones are really sucky but I didn't know how sucky they were until I tried to do something with them and I bring this up as well because my company paid me for a week to work on this totally irrelevant side project that had nothing to do with our mission nothing to do with the clients but they ended up getting a developer out of it that had really leveled up in skills they ended up getting some great publicity so I really want to encourage you whatever it looks like at your company maybe it's not 20% time maybe it's something else but if you can encourage your juniors to have passion projects on the side and even carve out time to mentor them and help them along with those passion projects those projects are going to get them to level up in skills way faster than the projects they're working on for clients so I have about eight minutes left it looks like so I'm going to go through some very quick important things and no particular order design patterns so getting out of a bootcamp and working as a developer now for a while the one thing I wish I knew better other than JavaScript is design patterns and I really encourage you if you're mentoring to work with your juniors on design patterns not only showing them where they're being used well but where they're being used poorly because I found that once you start learning about design patterns once you have like three of them under your belts everything's suddenly an observer pattern and it's like I can just do the observer pattern and it's like no maybe that doesn't fit so show them places where it's working well show them places where it's working poorly another thing that really helped me was watching other people code there's a site called peep code I think it's now called plural site they have a bunch of kind of webcasts of people just coding for an hour hacking away at something and talking about what they're doing is they're doing live coding and live refactoring and that was super helpful to me read books right now I'm reading design patterns in Ruby I have a lot of other recommendations if you're interested but just read books but not too much maintain work-life balance I know when you're so overwhelmed by stuff you feel you need to learn it's easy to get sucked into coding or learning about coding all the time but that doesn't do anyone any favors so maintain a work-life balance and I have just a couple minutes left and I thought I would talk more about this in this talk in terms of why hiring junior developers but when I started putting together my slides I realized that a lot of other people had already talked about the pipeline in regards to having a more diverse tech community much more eloquently than I would in this talk so when I make these slides available I'm gonna list some things you should go read and amplify those voices instead but I do have a few thoughts on the pipeline primarily from my time working in the racial justice field and the biggest thought I have that we should keep in mind is that diversity is not necessarily equal to social justice and one of the reasons we talk about hiring junior developers especially junior developers from non-traditional backgrounds because it's a way to make tech look more like the world we live in but the only warning I will give there is that diversity is in fact not the same as social justice of course they're in a relationship together and that relationship is kind of a reinforcing feedback loop which can either work as a vicious spiral or kind of a virtuous circle more diversity in our workplace obviously results in more social justice more social justice results having a less hostile work environment would certainly help with the fact that women are dropping out of tech at three times the rate of men but the risk we run if we focus just on hiring and hiring junior developers and hiring for diversity I think is that we're pushing this problem out to some future and saying hey maybe in 20 years if we improve our hiring then we'll have a diverse workforce and less hostile work environments and have a socially just tech community but in fact we can do the work for social justice in our tech community starting today and starting now and that will I think actually that we stand a better chance of having a more diverse workforce if we're working for social justice than we do getting to a socially just workforce if we're just focusing on diversity so that's my talk thank you Buffalo I'm at Mutual Rising