All this month on Build, we've been talking about on-boarding techniques for your new software engineering hires. We started out by talking about why on-boarding is important, and then moved on to showcase how pair and mob programming can help ramp up a lot of hires at once.
The next step is to give them a project!
Giving a new hire a meaty project can seem like a big risk. Seems easier to have them fix bugs while they ramp up on the code base.
But endlessly fixing bugs can be demotivating.
If you’re not sure when the right time is to give your new hires a meatier project, then you’ll definitely want to watch today’s Build Tip.
Chris Jobst who is a senior software engineer at Pivotal Labs is back to share some tips on how to balance bug fixes with meatier projects.
As you watch the episode you’ll learn:
Why bug fixing is often a priority, and how to motivate new hires through it
Why new hires are in the best position to spot technical debt and tackle it
When does it make sense to transition from bug fixes to a project
How to structure the project, when new hires are unfamiliar with the code base
Why pairing more experienced software engineers on a project with new hires can help new hires level up faster
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
Episode Transcript: When Does It Make Sense To Give A Newly Hired Software Engineer A Meaty Project
Poornima Vijayashanker: Hey Ronan, how are you doing, how's your team?
Ronan Dunlop: They're doing great, they're doing really good. In fact, I'm concerned, they're almost through the entire backlog of bugs and I'm not too sure what to give them next?
Poornima Vijayashanker: Maybe a project?
Ronan Dunlop: I don't know, I was really hoping to keep them on bugs for another six months.
Poornima Vijayashanker: Six months? You've got to give them something else, maybe like features, infrastructure work. You've got to mix it up or they're going to burn out.
Ronan Dunlop: I'm not sure they're ready. I'm nervous.
Poornima Vijayashanker: Well, I think that we're going to need to talk about the importance of balancing bug fixes with projects in today's *Build* tip.
Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker.
In the previous two *Build* episodes, we talked about the importance of onboarding new hires and shared how you compare or mod a program. In today's episode, we're gonna dive a little bit deeper and share why you want to not just give new hires bug fixes, but also transition to have them work on some meaty projects.
And to help us out, we're back with Chris Jobst, who is a Senior Software Engineer at Pivotal Labs. Thanks for joining today, Chris.
Chris Jobst: Great to be back. Thanks for having me, Poornima.
When To Move Past Fixes And Give Newly Hired Software Engineers A Project
Poornima Vijayashanker: So, Chris, you and I have been in the trenches, and you know a lot of times in generating leads and some companies, we won't name any, will start new hires out with a lot of bug fixes, some menial projects. It's no fun, but they do this, why?
Chris Jobst: I think they don't trust them, ultimately, but it's such a great way to get people to not care about the product.
Poornima Vijayashanker: So, at some places they do this for six months, bug fixes and stuff, when does it make sense to actually move past this and give someone a meaty project?
Chris Jobst: I think it's great to get them innovated as soon as possible. Fixing bugs can be a great way to learn about the code, but you want to give them a mix. Get them on features. That's how they're really gonna enjoy their job.
How To Structure A Project For A Newly Hired Software Engineer
Poornima Vijayashanker: So, I assume there's some way you want structure a project, because a lot of them won't know their complaint code base. There's gonna be reset a technical debt or other issues that come up, so what's a good way to set them up for success?
Chris Jobst: I think that using pair programming is an excellent way to both onboard them, and get them into the code.
Poornima Vijayashanker: Yeah.
Chris Jobst: You can have somebody more senior help them along as they're developing their first features. At the same time, doing some bug fixes, can get them to learn more about how the code really works at a deep level.
Poornima Vijayashanker: Yeah, and so what do you think the benefit is of doing that peer programming with a senior person?
Chris Jobst: Well, they're gonna ramp up a lot faster, and they'll probably learn a ton from a senior person. It's a great way to have your Junior Developers become Senior, very quickly.
How To Train Newly Hired Software Engineers To Handle Technical Debt
Poornima Vijayashanker: So they're probably gonna come across some technical debt and make it stock, not knowing what decision to take or how one thing will impact another module. What are your recommendations?
Chris Jobst: I think new team members are the best positioned to see technical debt, where others may have just put it off to the side for later. So, what they can do, is they can bring fresh eyes, and talk about it with their leads. Then, their leads can help them understand what are the priorities right now, and how to prioritize those things.
Poornima Vijayashanker: OK.
Chris Jobst: It just makes them feel heard, and it lets them understand what are priorities of the project.
Poornima Vijayashanker: So, how do we gauge the success of a project, because there's gonna a lot of learning and ramping up to do, so it's not like somebody can do a release every week?
Chris Jobst: Right, well I think it's really subjective, but a successful project, to me, is one that satisfies the users. If the users are happy, then that's success.
How To Motivate Newly Hired Software Engineers To Fix Bugs
Poornima Vijayashanker: Now, I know there comes a time for every software engineer where you've got to hunker down, do some bug fixes, do some menial work, clean out that technical debt, but how can you, as an engineering lead message that, especially to your new hires?
Chris Jobst: We have a weekly meeting to talk about the features coming up. You can make that a meeting, actually, about the chores, and the bugs that need to get done. This involves a PM, and gives the team a sense of unity. It can also give them a direction to go, so they don't feel like its' just gonna go on and on forever, and finally, make sure they understand why they are doing this. It's all for the user's benefit, and for their own. The code is gonna look cleaner by doing the tours and refactoring, and the bugs are gonna solve user problems.
Poornima Vijayashanker: Should there be a carrot at the end of the stick?
Chris Jobst: Absolutely. I'm a huge proponent of celebrating success, so have the team go out to lunch, or have a hackathon that gets them to take their minds off of it, do something else for a bit. In addition, if you have that weekly meeting, then you can setup your next feature, and get them excited about it.
Poornima Vijayashanker: So, Chris, you've shared a lot of great tips when it comes to onboarding new hire. Any final words of wisdom for us?
Chris Jobst: Well, this is a process that can always improve, and I think companies really do themselves a service by iterating and continuing to improve that. A healthy team always has new members joining, because you're rotating you're teams. You're getting new hires. So, make that an enjoyable process for them.
Poornima Vijayashanker: Wonderful. Well, thank you so much, Chris. This has been great.
Chris Jobst: Thank you for having me again. It's been really fun talking with you.
Poornima Vijayashanker: That's it for today's episode of *Build*. Be sure to subscribe to our YouTube channel to receive more great episodes like this one, and be sure you share it with your teammates, and your boss, and special thanks to our sponsor, Pivotal Tracker, for their help in producing this episode. Ciao for now.
Speaker 3: This episode of *Build* has been brought to you by our sponsor, Pivotal Tracker.
In last week’s Build Tip, we dove into the importance of onboarding new hires, and the benefits your team and company will experience if you invest the time into doing it.
Next, you might be wondering, what do you do if you have more than one hire? Or you have a hire that isn’t familiar with the language or framework your team uses and you want to ramp them up quickly?
Have you heard of techniques like pair programming or mob programming, but aren’t sure if they efficient and effective?
Well in today’s Build Tip, we’ll be sharing why pair programming and mob programming can be beneficial to getting new hires up to speed quickly on a new language or framework, and help you scale your efforts efficiently and effectively.
Chris Jobst, who is a senior software engineer at Pivotal Labs is back to help us out!
As you listen to the episode you’ll learn the following:
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
Check out these additional resources on programming methodologies:
How Pair Programming And Mob Programming Help Quickly Onboard New Software Engineers Transcript
Poornima Vijayashanker: Hey Ronan, how's it going with your new hires?
Ronan Dunlop: Great. I did everything that you and Chris suggested and...but I've run into a small snag.
Poornima Vijayashanker: Oh, what's your snag?
Ronan Dunlop: Most of my new developers don't know RAILS.
Poornima Vijayashanker: Oh, well just peer program with them.
Ronan Dunlop: There's just one of me.
Poornima Vijayashanker: Oh, that's right. And five of them. Well, have you considered Mob programming?
Ronan Dunlop: That sounds dangerous. What's that?
Poornima Vijayashanker: Don't worry, it's not. In fact, why don't we cover the benefits of pair and mob programming in today's *Build* tip?
Ronan Dunlop: That sounds cool.
Poornima Vijayashanker: Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In the last *Build* episode, I shared some tips for onboarding new hires.
In today's episode, we're gonna dive in and give you some more tips around how you can onboard engineers, get them up to speed on a code base or a programming language they may not be familiar with really quickly. And to help us out, Chris Jobst is back. You'll recall Chris is a senior software engineer at Pivotal Labs. Thanks for joining us again, Chris.
Chris Jobst: It's great to be back, Poornima. Thanks again for having me.
What Is Pair Programming In Software Engineering
Poornima Vijayashanker: Yeah, wonderful. So let's dive right in. What's Pair programming?
Chris Jobst: Pairing is when you have two people sitting at one computer. We often have two monitors and two keyboards and two mics, and they're literally working on the same code at the same time.
Poornima Vijayashanker: That's gotta be really time consuming to have two people doing the exact same task at the same time. What's the benefit?
When To Use Pair Programming
Chris Jobst: It sounds really daunting, but it's actually very efficient. You're basically doing code review a hundred percent of the time.
Poornima Vijayashanker: OK.
Chris Jobst: And you get to refactor together, so you avoid a lot of these common things that you'll see in other code bases.
Pair Programming and Refactoring
Poornima Vijayashanker: OK, so maybe for some folks that don't know code reviews or refactoring, maybe we could share what those are as well?
Chris Jobst: Sure. Oftentimes before something gets committed or accepted into the code base, you'll have somebody review it and make suggestions and then the original committer has to go back and change it, and then it goes back to the code review and gets accepted.
Poornima Vijayashanker: OK.
Chris Jobst: That's a feedback loop that we completely avoid with Pair programming.
Poornima Vijayashanker: And with refactoring?
Chris Jobst: Refactoring is simply where you take code and change the implementation without changing the functionality.
Poornima Vijayashanker: OK.
Chris Jobst: To improve the readability and maintainability of the code.
How Pair Programming Really Works
Poornima Vijayashanker: So in pairing, since you've got two sets of eyes checking each other's work, it probably moves a lot faster as a result?
Chris Jobst: I think so. There's code review going on, you're refactoring together, you're always talking about the best way to solve a problem and if you don't know what to do, instead of having to go ask someone or stop and email, you've got your pair right there.
Poornima Vijayashanker: Yeah. Which is probably the benefit for new hires?
Chris Jobst: Absolutely.
Poornima Vijayashanker: For our audience out there who may be new to pair programming, how can they get started?
Chris Jobst: Well, you know one computer and another monitor, and you need two keyboards and mics. Most people already have that on hand.
Poornima Vijayashanker: Yeah, and are there any rules, I'm guessing?
Chris Jobst: Absolutely. The biggest one is have empathy, and just be kind to your pair. You're both working together, it's pretty intimate, but it's a lot of fun too.
Poornima Vijayashanker: Now are both people writing code at the exact same time?
Chris Jobst: No. You decide who's going to drive at a certain time and type on the keyboard and the other person will navigate and maybe suggest, "Hey, what if we went over here and did this thing?"
Poornima Vijayashanker: So it's like a pilot/co-pilot and maybe you trade off?
Chris Jobst: Yeah, that's a great way of describing it.
Mob Programming Versus Pair Programming
Poornima Vijayashanker: Awesome. There are some situations where you can't Pair program, like in Ronan's case where he's got five engineering hires and they don't know RAILS so how can you work with a bigger group?
Chris Jobst: Well, you can do what's called Mobbing.
Poornima Vijayashanker: OK.
What Is Mob Programming
Chris Jobst: You get one computer and often a TV screen or projector and you have a bunch of people, five or more, look at the code. One person is typing and you're generally more teaching or gathering suggestions about how to best achieve a goal.
Poornima Vijayashanker: Got it. I'm sure somebody who's looking on from the outside is gonna be like, "Why are five people sitting around one machine and writing a single line of code?" What are some of the benefits? Why we would wanna do this?
Benefits of Mob Programming
Chris Jobst: As you pointed out, it's great for onboarding new people.
Poornima Vijayashanker: OK.
Chris Jobst: And what you'll have is people asking questions, oftentimes they'll ask a question somebody else didn't think of but it's a question that they need answered.
Poornima Vijayashanker: Got it. And I'm sure it also helps with the bus factor, right? Everyone's gonna know something, or know the same thing.
Chris Jobst: Definitely, you want everybody on the same page. You want them all knowing how the code works and if you've got a bunch of new people, it's actually more time-consuming to go and teach every person individually than to get them in a room and help them learn from each other and from the person who's the expert.
Poornima Vijayashanker: Got it.
Resources On Pair Programming And Mob Programming
This was a great primer on pairing and mobbing. For our audiences out there who maybe want to dive a little deeper, do you have recommendations on resources?
Chris Jobst: Definitely. There are two great books that I love. *Extreme Programming* and *Extreme Programming Explained*, both by Kent Beck. I recommend the former for engineers. It really talks about these practices and the process in more detail. *Extreme Programming Explained* is a great resource for PMs. It talks about it on a higher level and how a whole project can benefit.
Poornima Vijayashanker: Thanks for sharing these great resources and tips for us. I know our audience is gonna get a lot out of this.
Chris Jobst: Thank you for having me. I'm a huge proponent of pair programming.
Poornima Vijayashanker: So, for all of you out there, Chris and I wanna know, have you done pair or mob programming with your teams as you onboard new hires? If so, what are the benefits you've experienced? Let us know in the comments below.
That's it for today's episode of *Build*. Be sure to subscribe to our YouTube channel to receive more episode like today's and special thanks to our sponsor, Pivotal Tracker, for their help in producing this episode. Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
Have you recently hired a software engineer or maybe a few? Congratulations!
Are you starting to worry that they haven’t shipped any code yet?
Maybe they’re a bad hire...
Seems kinda harsh to think someone is a bad hire if they haven’t shipped code in their first day or week, especially if they haven’t been ramped up on the code base.
But who has time to train a new hire?!
Unfortunately the lack of onboarding new hires, and seeing it as unnecessary is becoming a pervasive misconception. Instead, teams and companies fault the new hire by thinking the new hire just isn’t self-sufficient if they need to be onboarded.
But how could someone (even a very seasoned software engineer) possibly review hundreds, thousands, or possibly millions of lines of code on their own? And be expected to know the nuances and decisions that went into writing all of it? Not to mention those notorious monkey patches that lead to bugs that only veterans on the team are aware of!
In today’s Build Tip, we’re going to explore why onboarding new software engineers on your team is important, and provide you with some techniques for doing it.
To help us out, I’ve invited Chris Jobst, who is a senior software engineer at Pivotal Labs.
As you listen to the episode you’ll learn the following:
Wondering what to do if you have more than one hire? Well, stay tuned, because in next week’s Build Tip we’re going to be sharing some best practices for ramping up more than one new hire at a time!
Why You Need To Invest In Onboarding A New Software Engineer And Not Expect Them To Ship Code On Their First Day Transcript
Poornima Vijayashanker: Hey Ronan, congratulations.
Ronan Dunlop: Oh yeah, we just hired five engineers.
Poornima Vijayashanker: Yeah, that's awesome. Are you going to start onboarding them soon?
Ronan Dunlop: Onboard them?
Poornima Vijayashanker: You know, walk them through the architecture, maybe do some peer programming.
Ronan Dunlop: I don't have time for that. That's why I hired five engineers.
Poornima Vijayashanker: So you're just going to let them sink or swim?
Ronan Dunlop: How else does one know if they're good or not?
Poornima Vijayashanker: Oh boy. I think we're going to need to cover the importance of onboarding in today's *Build* Tip.
Why Onboard Your New Software Engineers
Welcome to *Build* brought to you by Pivotal Tracker. I'm your host Poornima Vijayashanker and I've got a new *Build* Tip for you.
While hiring engineers is half the battle, the other half is ramping them up quickly. Today, I'm joined by Chris Jobst, who is a senior software engineer at Pivotal Labs. Thanks for joining us today Chris.
Chris Jobst: Thank you so much for having me Poornima.
Poornima Vijayashanker: Yeah. So Chris, a lot of people would say if you hire an engineer and they're not productive on the first day shipping code, they were probably a bad hire. What do you think?
Chris Jobst: Unfortunately, that's a really common misconception.
Software Engineer Onboarding Checklist For Managers
Poornima Vijayashanker: Yeah, what should a typical first day look like?
Chris Jobst: Well my first tip would be to have them meet the team and really make them feel part of that team.
Poornima Vijayashanker: Then what's the next thing you should do?
Chris Jobst: Well start off by talking about the product.
Poornima Vijayashanker: Yeah.
Chris Jobst: What are they building? Who are they building it for?
Poornima Vijayashanker: Got it. After that what would you do?
Chris Jobst: Well then maybe dive into the code a bit. Talk about the architecture.
Poornima Vijayashanker: Nice and what should you do as your talking about the architecture, because some people could have really big code bases?
Chris Jobst: Absolutely. I like to start at a really high level and then dive down bit by bit.
Poornima Vijayashanker: OK.
Chris Jobst: You don't want to overwhelm them on the first day.
How To Train Software Engineers
Poornima Vijayashanker: It's great that you mention architecture review. Again, some contrarians might think, "Well they should just set themselves up and dive into the code base. Don't make it too easy, we want them to sink or swim." What do you think?
Chris Jobst: I think the easier that it could be to set them up, the better they're going to be set up for success at the company.
Poornima Vijayashanker: Yeah, why do you think we should make set up a cinch?
Chris Jobst: Well if you really do want to get them involved in the product and the code, then make it easy for them to do that.
Poornima Vijayashanker: Yeah, so getting them ramped up and being able to download the code. Not have to install a whole bunch of jazz and this and that.
Chris Jobst: Have a setup script.
Poornima Vijayashanker: Yeah.
Chris Jobst: We have a few different ways of doing that for the computers that we use and it makes it so much easier.
Examples Of Onboarding Newly HIred Software Engineers
Poornima Vijayashanker: What's an example that you guys use?
Chris Jobst: We'll start with a base image and then we just have a workstation script that literally just installs a bunch of software.
Poornima Vijayashanker: What are the expectations for the new hire at the end of the first day? I know you mentioned they should meet the team, we should do an architecture review and make set-up a cinch, but what can somebody expect at the end?
Chris Jobst: I think that it's really important that they feel part of the team, but also that they feel connected to the user base and have empathy for the user.
Poornima Vijayashanker: Yeah, so getting a sense of who the user is and walking them through some use cases. Sharing some new testimonials.
Chris Jobst: Absolutely.
Poornima Vijayashanker: Usually it's an engineering lead driving the process like Ronan Dunlop, so I'm assuming they should maybe do some check-ins, either during that first day or during that first week? What's the benefit of doing a check-in?
Benefit To Onboarding Newly Hired Software Engineer
Chris Jobst: Absolutely. You want to make them feel part of the team and when they feel part of the team, they're going to stay at the company longer.
Poornima Vijayashanker: Yeah, that's a clear benefit to having a good onboarding process.
Chris Jobst: Definitely.
Poornima Vijayashanker: Well thank you so much Chris, these tips have been very helpful and I know they're going to help our audience as they onboard their new hires.
Chris Jobst: Glad to be here. Thanks for having me.
Poornima Vijayashanker: Sure. That's it for today's episode of *Build*. Be sure to subscribe to our YouTube channel to receive more *Build* tips like today's and thanks to our sponsor, Pivotal Tracker, for their help in producing this episode. Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.