Thinking about your onboarding process can save your whole team a whole lotta time and tears.
In this episode, we talk about onboarding early career developers with John Britton, founder and CEO of raise.dev, and Carolyn Stransky, software developer and author of the DEV post, “Onboarding a junior developer to your team? Here's 12 tips."
Ben Halpern is co-founder and webmaster of DEV.
Jess Lee is co-founder of DEV.
John Britton is the founder and CEO of Raise.dev.
Carolyn Stransky (she/her) is a software developer and journalist based in Berlin, Germany. Lately, her work focuses on frontend technologies, accessibility, and documentation. She is currently participating in the Google Season of Docs Program as a technical writer for the GraphQL Foundation.
[00:00:01] JL: Triplebyte is a job search platform that allows you to take a coding quiz for a variety of tracks to identify your strengths, improve your skills, and help you find your dream job. The service is free for engineers and Triplebyte will even cover your flights and hotels for final interviews. So go to triplebyte.com/devdiscuss today.
[00:00:19] RudderStack is the warehouse-first customer data platform built for devs. It is open source and built API first. So it is easily customizable and fits into your existing development processes. RudderStack’s multitude of SDKs, sources, and destinations make it easy to instrument, adjust, and route customer data from all of your digital touchpoints. Start building a better CDP for free today at rudderstack.com.
[00:00:45] The more you know about web development, the more fun it is. With Pluralsight, you can take your skills and your career to the next level. Start a free account today to access 50 expert-led courses, plus five extra free courses rotating in each week. Charged into 2021 with the confidence of someone who has development experts in their corner, go to pluralsight.com/free to create your free Pluralsight Skills account today.
[00:01:12] CS: Then I realized that if a company doesn’t have the will or the infrastructure to support a junior developer coming in, then it’s almost more harmful than not hiring them.
[00:01:36] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all our lives as developers. I’m Ben Halpern, a co-founder of Forem.
[00:01:43] JL: And I’m Jess Lee, also a co-founder of Forem. Today, we’re talking about onboarding early career developers with John Britton, Founder & CEO of Raise.dev, and Carolyn Stransky, Software Developer and Author of the Dev post, “Onboarding a Junior Developer to Your Team? Here’s 12 Tips.” Thank you both so much for joining us.
[00:02:00] CS: Thanks for having us, really excited to be here.
[00:02:02] JB: Yeah. Thanks. Looking forward to the conversation.
[00:02:04] BH: So before we dive into the topic of onboarding, I’d like you to both introduce yourselves. Carolyn, can you tell us a little bit about your background?
[00:02:13] CS: Yeah, sure. So I’ve been coding for three years. I went to a bootcamp in 2017. I’m based in Berlin, Germany. So all of this is in that context. And since then, I’ve been working. I worked as a technical writer and now I’ve been a full-time software developer focused on front-end technologies for the past two years or two and a half-ish. And during my first job as a junior developer, I was able to actually onboard another junior developer onto my teams. So a lot of my opinions and experiences are really based on my own experience as well, also being confirmed by her experience, if that makes sense, kind of like a domino effect. And before that, I was a journalist. So that was what I was doing before I got into tech, a little bit of marketing when I first moved to Berlin.
[00:03:06] JL: What made you jump into a career switch?
[00:03:09] CS: So I studied journalism in university and then I moved to Berlin pretty much immediately after that. And I tried to do some freelance work, but being a journalist in general is pretty difficult to make a sustainable living off of and being one in a foreign country that you don’t speak the language was really hard. So tech was a way, there’s a big startup English speaking tech scene here in Berlin and I was able to make some friends through that and eventually work in marketing. I realized that developers were treated a lot better. So then I switched. That was probably the really honest answer, but it’s true.
[00:03:51] BH: My transition into software development was essentially because I had a job in marketing and I sort of knew how to code a little bit and I thought the software developers are also treated better and had more say into everything, even the marketing stuff, because they could just say like, “Oh, we can’t do that.”
[00:04:10] CS: Exactly.
[00:04:11] BH: Yeah. I wanted to be one of the people who says, “We can do that.”
[00:04:15] JL: Yeah. I think that’s a great reason to switch careers.
[00:04:18] BH: John, what about your background?
[00:04:20] JB: Yeah. I got my start in software development really early. I started programming when I was in elementary, middle-school aged building websites in the ’90s. I always used to tell myself that I didn’t want to have a career in software or in programming because I didn’t want to sit behind a computer all day. I ultimately ended up getting into the field because it was the thing that I knew how to do. It was the easiest way to make a living. And I also learned that kind of having an intersection between being a software developer and being an expert at something else really opened up a lot of doors. So I went to university at RPI where I studied engineering, and then I transitioned into computer science before dropping out. When I dropped out, the reason was school was getting pretty expensive and I had a job offer already in a startup. And I joined as a lead developer at a pretty early education-focused startup. I spent a few years doing that and then stumbled my way into a really cool job title called “Developer Evangelist”. I was a really early employee at Twilio and I ended up working there because I saw a job posting. It said I would get to travel, teach people how to code, and be part of a building a really cool software product. And it sounded like just like the job for me. So I joined Twilio as a developer evangelist. They’re based out of New York City for a while. I ended up leaving to work on an education and nonprofit called “Peer 2 Peer University” with a few friends of mine. In total, I spent about five years doing that. And then again, just by chance, a really awesome job opportunity came up. It was a role at GitHub called “Education Liaison”, effectively building the GitHub Education Program. So I joined GitHub in 2012 and I was there for about seven years. Up until recently, we created the Student Developer Pack in a classroom and a bunch of other education-focused developer programs for people who are early career developers getting into the field. About a year and a half ago, I started a new company called Raise.dev. And our mission is to help developers reach the next stage of their careers. We’re primarily working with early career developers right now, but the goal is to work with developers at all stages of their careers and help them get to the next level.
[00:06:24] JL: What an amazing history. So Raise.dev, can you tell us what kind of work you do there to make the lives of these early career developers easier?
[00:06:34] JB: I think that the big problem we’re trying to solve is this idea of the software developer experience gap. When I got into software development, the web wasn’t what it is today. There weren’t the resources available to learn how to code self-taught. I remember getting into it. I picked up a book at the bookstore, “Teach Yourself How to do HTML in 21 days.” And I read the book cover to cover as a kid and started hacking around with things. But today, we’ve got all these like really amazing online resources. You’ve got things like Codecademy, YouTube videos, tons of independent content creators, and then you’ve got the coding bootcamps, which are all really awesome. But once you kind of teach yourself or learn in school or get to the level of like, “I know how to code, but I’ve never had a job coding,” it’s still really hard to make the jump from self-taught or taught in school to being an employed software developer. And it really comes down to the fact that employers hire based off of experience. And the problem with that is that it’s hard to get experience if you don’t have the job and it’s hard to get the job if you don’t have experience. So when we started Raise.dev, the initial idea was, “How can we get these people experience?” And the simplest solution was to just give them jobs. So I went out and hired a bunch of developers and started paying them to do work without any real business model whatsoever, just the kind of idea that we’d figure it out as we go. And so the end result is that our business is focused on helping developers get real-world experience, working on real software with real teams at real companies, so that they can put on their resume, put on their CV, “I have job experience,” and then they’re much more able to get hired.
[00:08:13] CS: I’m so glad that you pay them. I just want to like have that in.
[00:08:17] JB: Yeah.
[00:08:17] CS: Because I think it’s something that I got a lot of advice when I was first looking to switch in that was like, “Oh, just volunteer. There’s a plenty of organizations where you can basically volunteer to be a dev and build stuff for them and whatever.” But I was like, “I need to be employed.” Like I have a visa, I have rent to pay, I need a job. So I appreciate that.
[00:08:40] JB: This is a really tough challenge to solve too. Access to the program is really important to me and I want to make sure that it’s not something that’s only available to the people who have the luxury of being able to take six months or a year off of work. So when we started the program, it was definitely a paid opportunity upfront. With that in mind though, the money has to come from somewhere. A lot of it is like coding bootcamps. We’ll do things called ISAs, Income Share Agreements, where you don’t pay anything upfront. And when you potentially get a job down the line, you pay a portion of your future income to cover the cost of the program. My goal for the way that the monetary side of this works is that we find a way to get the companies to be the ones on the hook for paying for the educational costs so that the devs can get the experience that they need by doing their work and you’ll have a base income that they can survive on. So it’s a reasonable position for them. And then ultimately, the company who makes a hire, they would pay for recruiting fees anyway. So maybe there’s a way to figure it out like that.
[00:09:41] BH: Yeah. I think it’s a pretty well-understood notion in our industry that there’s certainly a trap for early career developers who don’t have that experience yet, need the experience to get the job. But I would also observe that there’s a lack of people willing to take on that challenge because it’s such a balance of economics, just a tough challenge to sort of close that loop and it’s going to be really cool to see what comes out of Raise in the next few years.
[00:10:11] JL: Yeah, and for companies who do take on that challenge, they also need to be really thoughtful about how they onboard their junior developers. So Carolyn, you wrote a piece on Dev titled, ““Onboarding a Junior Developer to Your Team? Here’s 12 Tips.” Can you talk more about why you wrote that post?
[00:10:29] CS: Yeah. So it’s a lot of exactly what you just mentioned. I think a lot of companies don’t realize what they’re getting into when they want to hire a junior developer. And when I say junior, I mean someone where it’s their very first software engineering job. So a lot of people kind of see it as cheaper labor, but they don’t realize that there are a lot of maybe knowledge gaps that might not be apparent right away. For example, in my bootcamp, I learned how to code, but I didn’t learn how to collaborate. So I didn’t know how to make a pull request. I didn’t know how a lot of my git environment worked and things like this. So my post was inspired by a friend of mine who was onboarding his first junior developer and wanted to get some advice on how do you help someone get started as a junior, what are some red flags or maybe things you should avoid. I went on a huge Twitter rant and turned it into a blog post, which all good posts, I think start from, some sort of inherent rant or feeling.
[00:11:38] JB: I have two questions. One is, “Should companies be hiring early career devs? And if so, what are the motivating factors for why they should be hiring early career devs?” Because I heard you mentioned sometimes it’s a way to get cheap labor. And to me, that’s like an immediate red flag of I don’t think the motivation to hire early career devs should be cheap labor. And I wonder what your thoughts on the issue are and I can definitely share a bit of mine, too.
[00:12:03] CS: I agree with you. It’s definitely a red flag. I think that’s something that’s hard to figure out in an interview process, but it’s definitely a red flag. And it’s funny because my answer to the “should companies hire junior developers” has really changed. I think when I was a junior developer, I was really like, “Every company should hire junior developers. We’re so great.”
[00:12:28] JB: A little bias.
[00:12:29] CS: A little bit. But I was like, “We add so much value. Look at what we can bring.” I was feeling really empowered about that. But then I realized that if a company doesn’t have the will or the infrastructure to support a junior developer coming in, then it’s almost more harmful than not hiring them. That is an opinion I hold today. So I’m curious about what you think.
[00:12:54] JB: No, I totally agree. When I was at GitHub, GitHub famously had a no management structure for many years. And that kind of led to this thing where we couldn’t hire early career devs or inexperienced devs. We had to hire people who have done it before and knew the way because there was basically no management infrastructure for new devs. And I think that the real, a couple of reasons why I encourage hiring managers and companies to hire early career devs, one is to widen your talent pipeline. So if you want to hire a more diverse representative team, this is one way to get more people into your pipeline from a wider range of backgrounds. Another is building up your management infrastructure and making it so that your company is not a hundred percent dependent on kind of the unicorn senior engineer that does 15 different things. Instead, you’re building up your skills around how to properly train and onboard new people on your team. And I’d say also hiring early for devs is a way to build into your management structure, a sense of like continuous learning. I always say this to the devs that I’m mentoring that if we knew how to solve the problem, you’d already be done. The job of a software developer is to figure things out as you’re going. And if we already did this solution, we wouldn’t need to hire a developer. We’d just buy a piece of software to do it for us. Right? And so encouraging that kind of an environment on your teams where everybody is investing in themselves and investing in each other is a really, really valuable thing to do. And I think that the best organizations are going to be the ones that have that kind of a culture. And if you orient yourselves around being able to hire early career devs, you’ll also build yourselves to where you’re helping your managers level up and your team leads level up as well. So it has kind of knock-on effects throughout the company.
[00:14:43] CS: I also think that if you have a structure where you have mid-level and senior devs, but your senior developers aren’t mentoring as part of their job, what are they doing? I mean, saying that as someone who’s never been a senior developer, but really I see it as, at least in the organizations I’ve worked in, such an integral part of being senior is kind of lending back that knowledge. So I would agree.
[00:15:06] JB: That’s really the idea of force multipliers, right? And from my time doing more kind of community-based marketing, one of the things that we talk about a lot is rather than having that one-star person in your community that goes out and does the thing, how can you empower them to reach many, many more people and give them leverage? And I think the same thing is true for your senior engineers. It’s great to have a senior engineer who’s writing code, shipping features. But if that seems, then your engineer can help the 20 or 15 other earlier career engineers in the team level up, now you’re just paying dividends for a very long time.
[00:15:43] CS: Totally right.
[00:16:02] Join over 200,000 top engineers who have used Triplebyte to find their dream job. Triplebyte shows your potential based on proven technical skills by having you take a coding quiz from a variety of tracks and helping you identify high growth opportunities and getting your foot in the door with their recommendation. It’s also free for engineers, since companies pay Triplebyte to make their hiring process more efficient. Go to triplebyte.com/devdiscuss to sign up today.
[00:16:27] RudderStack is the warehouse-first customer data platform built for devs that builds your CDP on your data warehouse with support for cloud data warehouses like Amazon Redshift, Google BigQuery and Snowflake. RudderStack makes it easy to collect, unify, transform, and store your customer data as well as route it securely to a wide range of common, popular marketing sales and product tools. Start building a better CDP for free today at rudderstack.com.
[00:16:59] JL: John, you’re the first person that introduced me to the term early career dev. Can you speak a little bit to that? I noticed you haven’t used the word junior at all in our conversation.
[00:17:09] JB: Yeah. This is something I do on purpose. I think that the word junior, when you’re talking about somebody as a good junior software engineer, it puts them into a box where other people unconsciously will think that they are less capable. Just because somebody is new as a developer doesn’t mean they’re not an established, highly skilled individual. And so I really just prefer to use the term early career dev to talk about the fact that maybe this is their first or second job in the field, but it doesn’t necessarily mean that they’re a first time having a job in any field, or also the possibility that there’s a hierarchical kind of ranking when it comes to this stuff. And I think that it’s more of an inclusive, like welcoming term, in my opinion.
[00:17:55] CS: I feel a little bit conflicted about this argument of, “Should there be junior devs, early career? What are they called?” But in my mind, I think having any sort of label like that is better than having no labels. I’ve seen a lot of organizations or people fall back on calling everyone software engineer, and that is it. And I think that can also cause problems like while it might be more inclusive on the surface, it’s neglecting the fact that this person might need more support or this person needs more of a structure. So it’s a hard debate of what is really inclusive. You know?
[00:18:34] JL: John, you’ve onboarded a bunch of early career developers to help them bridge that gap between their first full-time role at a company. And Carolyn, you’ve been through the experience as a junior developer and then immediately after onboarded another junior, I’d love to just learn some of the advice that you both have. Carolyn, can you share a couple of things that you think are really important to companies looking to onboard junior developers?
[00:21:49] JB: I think the biggest challenge that not even just early career developers but new team members at company space is all of the baggage around the deployment or the continuous integration, setting up your dev environment, basically things that are not your core job. So if you think about working on a product company, your core job is build a new feature, fix a bug. It’s not set up the infrastructure. It’s not build the thing that runs the unit tests. All of these things are ancillary to the end goal of building the product that your end user wants. So when it comes to early career devs, or even just new team members joining, they generally have an area of expertise, something that they know how to do. Maybe they’re a web developer or maybe they’re a mobile developer or maybe they know a front-end framework, maybe they know a couple of different things, but they might not be experts in build tools and all of this other stuff that’s involved with getting your app running in development and then getting changes that make out to production. And so all of that difficulty leads to kind of my number one recommendation for teams that are bringing in new developers is make development environment set up and deployment to production as smooth and simple and streamlined as possible. So the ideal situation is that on day one, a developer can get their laptop. They can run one command. Their entire machine will be set up with all the appropriate security settings and everything that’s needed for that company. And then they can choose a project within the company’s code base, run one command, and then that code base is running in development on their machine. And then they can write some code on a branch, make a pull request, get code review, and then click the merge button and it’s in production. Right? And so these are all things that the developer coming into the team should know how to do. They should know how to run a script. They should know how to set up their machine. They don’t need to know the ins and outs of your development environment. They should know how to make a pull request. They should know how to get some code review. They should know how to merge, but they don’t need to know how your Kubernetes setup works or how your AWS EC2 setup is working, but they can still get changes out production hopefully on day one. And this is a really, really tall task for teams to do, but I know it’s possible because teams I’ve worked on have done it. At GitHub, when I was working there, we had this really cool kind of mantra for all of our apps. It’s called “Scripts to Rule Them All”. There’s a blog post about it. If you Google it, there’s a GitHub repository. But the idea is that every project that you make inside the repository, you create a folder called “scripts”, and inside that folder, you have a few standardized scripts that are named like script server, script CI builds, script test, script setup, script bootstrap, and each one of these does a defined set of actions for the project that as a developer, I can understand the interface. I can understand if I want to run my test. I run script tests. And then the script, whether it’s a mobile app or it’s a web app or it’s an Electron, Hybrid cross-platform app, it will run all of those things for me automatically, so with the development environment. And investing in those types of things will make the experienced developers on your team much more productive and it will make it much more possible for you to bring new team members in and get them up to speed really quickly.
[00:24:56] CS: I have a question for you about that.
[00:24:58] JB: Sure.
[00:24:58] CS: Who is in charge of doing that?
[00:25:00] JB: That’s a really good question. Depending on the size of the company, I think if you’re a really small startup, try to do it right from the beginning. That generally means the founder or the CTO or whoever the lead engineer is adopting this kind of principle from day one. I’ll tell you, as with most things in computing and in programming, if you do it right from the beginning, it will be a lot easier than trying to come back and change it all later. If you’re in a much bigger company, I’ve worked at companies that have had teams called “developer experience” and also a team called “friction” where there’s essentially a team of developers whose job it is to make sure that other developers’ productivity is not hindered. And I’ve never really seen this kind of pattern at companies that weren’t developer centric companies, but I think it’s a really smart pattern.
[00:25:45] BH: Yeah. We’ve had the experience of aiming for similar things. One hiccup we had along the way, which I was reminded of with John’s point, was that sometimes we made it possible to deploy on day one. But we actually, I think, have loosened from that now and have focused on some like early tasks to actually sort of like deemphasize having to do any meaningful coding until you’ve done a few other things. So we have like some basic stuff, like everybody adds a PR to our repo to like add their name as a contributor, to an area and stuff like that, focus more on the team handbook and some other stuff, just like Slack channels that they can subscribe to and like the communication flow and getting to know the team more so than just like the technical component, which kind of follows closely thereafter.
[00:26:38] JB: Yeah. I think that’s totally right. And when I say being able to contribute code on day one, I don’t think it’s necessary, but your infrastructure should support it. It shouldn’t take me a week to get my development environment set up. And I also think that because you’re an open source company, I think that that’s a really good forcing function for you to keep your new dev environments really easy to get set up because you want to get the community involved as well. The higher the bar of entry to getting your dev environment running the less likely you’re going to have community contributors as well. So that helps you. And I think what companies can learn from that is this is just another case we’re working like open source can really help you improve your developer throughput and your team efficiency.
[00:27:20] CS: I also like what Ben said about not emphasizing the push to production on day one, because I think that’s something that I would have been, I mean, I’m still a little afraid of if I onboard to a new team and they’re like, “All right, you need to push to production. Now it’s your first day.” That feels like a lot of pressure. I like what John said about being able to, but not being forced to.
[00:27:44] JB: Carolyn, I wonder if you have any suggestions for other things that maybe aren’t directly code related that new developers on a team should be doing, let’s say, in their first week. Ben was just saying about like employee handbook, getting them oriented to Slack channels, things like that. But are there other things that you have seen or that you recommend people get involved with?
[00:28:04] CS: I think something that really helps me, ironically, both as a marketer and as a developer was, especially if you’re working for kind of a larger organization, being able to understand how the other departments work and how that affects your work. I think engineering specifically is in a really unique position in that you have all of these stakeholders from all of these other departments who have maybe more of a direct connection to your end user or your customer. So knowing how they operate, how they intake feedback, how that feedback is communicated to the engineering department, how that is prioritized, at least for me, that’s really helped my work. And I’ve noticed that it helps really any developer onboard, but also specifically early career developers because you kind of see the bigger working system rather than just your team in your department. It helps you figure out the why component of your work, like, “Why am I working on this bug fix? Why am I working on this accessibility improvement? Who is benefiting from this?” It makes you feel like you’re having a real impact on someone’s experience. And I think that’s really valuable.
[00:29:23] JB: Another thing that I do with all new members of the team that helps with the why impact is to have them do customer support. A lot of times customer support is thought of as a chore, but it really is a good way for developers on the team to get to understand who’s using this thing, why are they using it, what are their problems, where are they hitting issues with our software, where are we not meeting their needs and to really build up a sense of empathy for the end user. We had this thing that we used to do, which was also kind of like a support rotation. So when you first joined the team, you do support for, let’s say, your first week, or you do a couple of days in your first week. You answer user support emails to get a sense of what the customer feels. But then as an engineer, every engineer on the team kind of does a rotation where for one week out of every like two or three months, the developer is kind of on-call with the support department where the support department might come across issues in the code base or issues in the application that cause problems. And rather than file an issue that never gets addressed because it’s low priority, there’s a person who’s a developer who’s on-call whose job is to not solve the end user’s problem, but actually write code that eliminates that class of error or that class of problem. And that really helped a lot in the teams that I’ve been in as well.
[00:30:42] BH: So to summarize a little bit about this before we move on to some member responses and have a little bit of discussion about what the community is saying, there’s a lot of challenges that organizations face to onboard early career developers. There’s a lot of realizations along the way. When you are an early career developer and you start to get later in career, like, “Oh, this is like where it wasn’t so easy for the organization and I needed to kind of understand.” But then there’s opportunities that the industry needs to identify where if you’re not making this part of your flow, you’re going to have some cultural blind spots. It’s going to be harder for everyone to contribute because it’s not easy for anyone. It takes experts only to be able to even run the development environment. And ultimately, there’s probably a correlation between the overall organizational integrity and consistency and its capacity to bring along new employees, bring new people into the culture and let everybody succeed. Any additional points before we move on to responses?
[00:31:50] JB: I would just add your point about the organizational capacity to have early career developers. And I think that there’s a correlation with that and also success of your organization. I don’t think you need to be well organized to have early career developers, but if you can build the frameworks to support early career developers and internal learning and education of your staff, you’re going to be a more successful company because what you’re going to be doing is going to end up retaining the employees longer and you’re going to be able to help them level up to fill the needs that you have rather than having to go out and find new talent all the time.
[00:32:23] CS: I would add that I think if you’re an early career developer listening to this podcast and you’re experiencing a lot of friction or a lot of difficulties within your organization that it’s a two-way relationship and I think you always need to remember that. There are so many factors that go into onboarding any developer and also specifically that go into onboarding junior developers. And so if you’re feeling like you’re failing, it’s not necessarily because you are. It might just be an organization or structure that doesn’t work for you and that is absolutely okay.
[00:34:04] JL: Now we’re going to move into a segment where we look at responses that you, the audience, have sent us to a question we made in relation to this episode.
[00:34:11] BH: The question we asked you was, “Any tips for onboarding developers?” Our first response was from Helen.
[00:34:17] HELEN: These are my five tips for a better onboarding process. Number one, announce their arrival. This is especially important in large or distributed teams. Make an announcement on Slack before they start and tell the team who they are and what it is that we do. Now focus on your teammate to repeat over and over what they do with each new person they meet. Number two, team purpose. Make it really clear how the team fits into the company as a whole, who your key stakeholders and how you know you’re making a difference. Number three, meet and greets. Consider doing these in groups rather than endless and potentially awkward one-on-ones. Give some context on what to cover to. The space or time are valuable. Number four, documentation. Make sure you have everything documented up-to-date and cover off the good and the gotchas. No documentation, no problem. This is a really good opportunity to work together and write it as they learn with you. And number five, following up. Onboarding doesn’t just stop after the first week or even the first month. Catch up with your new teammate to make sure they have everything they need and get their feedback. A successful onboarding program seems the message that you and your teammate is valued, that the team is organized, and that there’s a plan to contribute to their success.
[00:35:34] CS: I really want to echo the first point, the announce their arrival point, because I had that issue with the junior developer that I onboarded. She was added to our team. And no one told us until like two days before she came. And I think if you especially are going to onboard someone who’s earlier in their career and you’re going to take that on as part of your work within your team, I really believe that everyone should be aware and ideally be on board and ready to participate in that process and really be like an integral part of them coming on. So I think all of her points were great, but I want to really especially echo the first one.
[00:36:17] JB: I think the thing I would add to this is that you should have a process for onboarding. You should make sure that maybe the first time you add a new person to the team, you start to document the process. One thing that I found very useful is having an onboarding checklist. This is something that on the first day, the hiring manager can meet with the new hire and kind of walk them through the checklist of, “This is what your first month is going to look like. Here are the things you have to do on your first day. Here are the things you do on your first week. Here are the things you have to do on your first month. Here are the guidelines on how to achieve all of these things.” But the really important component of this is that it’s written down, it’s organized somewhere, and it’s something that is like kind of a living document that you can change over time. So each time you add a new team member, you can always keep it up to date. We just use pull requests and GitHub repository to keep a checklist so that anytime that somebody has a problem or something’s not covered in the checklist, they can just add it.
[00:37:08] JL: Our next response is from Greg.
[00:37:11] GREG: One practice I really enjoyed over the last few years is the practice of putting developers into QA when they start. It’s a great way for developers to learn the product, meet other people on the team that are going to be looking at their code, understand what they’re going to have to be dealing with when looking at their code, like logs and error messages and whatnot of how they should be structuring their code for that delivery. Great topic.
[00:37:38] BH: The idea of getting people into QA is pretty similar to what was mentioned earlier of getting people into support. It’s a lot of the same ideas. You’re getting closer to some of the problems, but from a different perspective. And I’ll also say that this approach, which you can definitely do for everyone across the organization, any new hire shouldn’t necessarily be unilaterally above getting into QA or support or anything. And it’s certainly important to have an organization where people are willing to chip in and not being like above the work of other folks. But I will say that I think implementing one of these programs is going to be a lot easier with junior developers in general. And I think that’s one more area where culturally integrating newer developers into the team is that much more useful when you can actually create programs where the junior developers’ likelihood of buy-in is going to be that much higher and then it all snowballs from there.
[00:38:36] JB: So I just wanted to comment on your point about buy-in. This is something that I really love about hiring early career devs is that they’re incredibly eager and there’s almost like no such thing as a task too small. And so I think it’s a really strong motivation for why to hire early career devs is that they’re willing to chip in and they’re willing to put in hard work.
[00:38:57] CS: I want to add something about juniors and buy-in and being eager. One advice I’d give to people who are onboarding junior developers is don’t mistake being eager to do things as them actually enjoying the things that they’re doing because I think there’s a lot of pressure as someone when it’s your first software engineering role. You really don’t want to screw up. You really want to be successful, especially if you did put a lot of time and money and tears into a career switch. You feel like the stakes are really high. So at least for me, my first development job, I would have done anything that they would have asked because I was so desperate to pass my probation period to stay, to do that. But I didn’t enjoy most of what I was asked to do. And I think a lot of people later were like, “Oh, Carolyn, she’s so enthusiastic about this. She loved doing that.” And I was like, “No, but you asked me to, and it’s a job and I wanted to keep it.” So I just want to throw that out there. It goes a long way to also ask your new developers what they enjoy.
[00:40:05] JL: Let’s hear what our last respondent, Amish, has to say.
[00:40:09] AMISH: So I think the onboarding actually starts before they joined the team. The managers need to take care of any accessories on getting delivered. Another thing is I think it’s pretty common in the industry today is having an onboarding mentor. So this onboarding mentor should totally give a high level architecture of the services that are owned by their team, the upstream and the downstream systems, and a brief what are the technology stacks are there, the common tools that the new developer is going to use in the coming weeks. Then in terms of work, I think every team should have a bootcamp. If that is there, it’s the best. Otherwise, just have a project with a couple of small task that the new joinee can work on because these tasks, they help the new developer to get familiar with the development process, the tools that the team owns, the team standards and the expectations, et cetera. They get to know about it more. Then directly jumping on to do, to make changes in the production quarter. I think those are some of the points that I have. Thank you.
[00:41:24] JB: The point that Amish made about being ready before the developer starts, I think applies not only to early career devs, but any new developer joining the team. Something that we’ve done on our teams in the past that’s kind of to this point is the first week schedule is kind of like all set before the person even shows up and they have full access to know what that schedule is going to be. And I think the key motivation for this is so that the new team member is not surprised by anything. The way that we’ve achieved this is actually once they sign their job offer and they set their start date, they’ve signed the offer. We have all the appropriate non-disclosure agreements in place, whatever, we actually give them access to a couple of basic accounts. So we give them their G Suite account, which has their calendar and their email address. And then we also give them a little bit of access to the team Slack channel. And we don’t expect them to sign into it or use it, but they have the option to if they would like where they can actually just view what’s going to happen in the first week. And in that first week, everything comes through as like calendar invite of what’s going to happen and when it’s going to happen and it’s just to help with that knowing what to expect on your first day, rather than showing up on your first day and being expected to deploy the production like you know kind of what’s going to happen.
[00:42:37] JL: Carolyn, John, thank you both so much for joining us. This was a lot of fun.
[00:42:41] JB: Yeah. Thanks. This was a great time.
[00:42:42] CS: Yeah. Thank you.
[00:42:53] JL: I want to thank everyone who sent in responses. For all of you listening, please be on the lookout for our next question. We’d especially love it if you would dial into our Google Voice. The number is +1 (929) 500-1513 or you can email us a voice memo so we can hear your responses in your own beautiful voices. This show is produced and mixed by Levi Sharpe. Editorial oversight by Peter Frank and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, please email [email protected] and make sure to join our DevDiscuss Twitter chats on Tuesdays at 9:00 PM Eastern, or if you want to start your own discussion, write a post on Dev using the #discuss. Please rate and subscribe to this show on Apple Podcasts.