On this episode of Eat Sleep Code, Mike Hand shares strategies for training and mentoring as well as some common and some less obvious pitfalls. When and how to give feedback are covered. In addition, Mike shares advice on using code reviews and pair programming to your advantage, and how to be the experienced developer juniors think you are, with the focus on practical dos and don’ts you can start using right away.
Mike has been in software development for over 10 years, working everywhere from top 10 defense contractors, small privately owned companies, freelance, and the world of consulting.
00:00 Ed Charbeneau: This podcast is part of the Telerik Developer Network. Telerik by Progress.
00:15 EC: Hello and welcome to Eat, Sleep, Code, the official Telerik podcast. I’m your host, Ed Charbonneau, and with me today is Michael Hand. How you doing, Michael?
00:23 Mike Hand: I’m doing great. I’m really excited to be here, both at Stir Trek and on Eat, Sleep, Code. This is really exciting for me.
00:31 EC: Yeah. Thanks for joining me. Like you said, we’re at Stir Trek 2017. We’re gonna be watching Guardians of the Galaxy 2 tomorrow. We got a lot of great speakers here, including yourself. What is your session about tomorrow, Michael?
00:46 MH: The idea basically… The title is “Care and Feeding of Your New Junior Dev”, and the idea is, eventually, you stick around long enough in this industry, in this career, you’ll find yourself not being a junior dev anymore, and there will be junior devs behind you, and not everyone really understands how to approach that, how to pick up the people behind you and help them along. That’s kind of the thrust of this, is that it’s actually something that most people can do. They don’t necessarily realize that, and it’s something that most people should do.
01:26 EC: Okay. This is really, really good career advice type stuff, soft skills type of a topic. Before we get into that, tell us a little bit about yourself. Where do you work? What do you do?
01:39 MH: Yeah, I’m currently working for HMB. They’re actually right here in Columbus. I’m part of the local dev community. It’s a very exciting time of year to have a big conference like this. People come in regionally and from around the country. It’s awesome to have right here in our own backyard. Basically what HMB does is, we’re a consulting company, so they find clients for us to work at and we go and we solve their problems. We have devs of all levels and what we try to is bring everyone through the ranks and go out and basically make other companies’ lives easier by solving their pain points.
02:25 EC: Yeah. I have to give a little shout out to HMB, ’cause I’ve been in the area quite a bit in the Columbus area and in Louisville, so I know quite a few people actually that work with you, and the reason I know the people that work with you is ’cause they spend a lot of time in the community.
02:41 MH: Yeah, that’s right.
02:41 EC: Which is amazing, so hats off to that.
02:43 MH: Yeah, HMB really is a company that supports and encourages interaction, both within the company, which is important ’cause generally we work at client sites, to get us together every quarter for a quarterly meeting and make sure you’re in touch with the people you’re working with and could be on your next project with, but also getting out and engaging with the dev community in our city, being part of that. Being present in conferences. Hiring from local colleges and all that stuff.
03:13 EC: Yeah. With that said, it doesn’t surprise me that you’re talking about mentoring junior devs in a talk when several people that I know from your company are always in the community trying to support new people and teach new things. Let’s talk a little bit about the talk that you have tomorrow. How did this come about, this whole session that you’re giving?
03:38 MH: I’ve been doing software for about 10 years, give or take. I’m not early on in my career anymore, kinda early middle. I got a long way to go. But just the idea of, when I was starting out, there were people that were there for me and it made a huge difference, and not everyone has that opportunity. I think a lot of entry-level jobs, they’re seen as starter jobs, and you work for a little while just to get experience so that you can get the job that you want, so the realization of that, but also… I’ve been at HMB just shy of a year now, and one of the unique things about HMB is everybody has a mentor, and most people have mentees, so you’re usually in the middle of that kind of mentor ladder somewhere. It’s not just something that HMB encourages, everyone just gets assigned a mentor, and seeing how that can make a difference in the career path of a junior dev, that’s definitely something that I’m a big proponent and advocate of, and I think it can really change the course of someone’s career trajectory in a very positive way.
05:05 EC: When you say junior dev, are you talking about people that are coming out of school? Are these folks that are interning or have just interned? What’s the scope of the junior dev?
05:19 MH: I don’t think it has to be defined super explicitly or formally. I think the general thrust of, at least my talk is, is the idea is maybe you’re in an internship or maybe you’re just in the first year of your first full-time job, in that range. That’s the thrust of what I try to cover in my talk. From the perspective of an entry level dev, they come in and like, “I’m just trying to survive.” They’re in survival mode, and they don’t know necessarily how to approach like, “Do I look like I’m getting enough work done? I don’t know how office politics work. I’m trying to learn a new project, maybe I’m even trying to learn a new language,” all that kind of stuff that the more seasoned developer understands is part of the process. But an entry-level dev, basically, for the purposes of this talk, is someone who doesn’t necessarily understand that. They haven’t done that before. Probably in the range of first year or so and less.
06:25 EC: Yeah, office politics alone can be more difficult than any programming language that you learn.
06:29 MH: Absolutely, yeah. And just to understand who are the important people on your team, and who are the important people who aren’t on your team? Who do you talk to when you need to solve X-Y-Z problem? Whether it’s something as simple as, “Hey, my PC is locked down and I need to install this application to be able to talk to my database.” How do you solve those problems? Your entry-level dev doesn’t necessarily know. Sometimes, just simply about, “How to do I find the resources that I need to be able to do my job?”
07:05 EC: Yeah. One thing you might want to watch out for, is you don’t want some person that’s not your direct report giving you tasks to do.
07:13 MH: Right, Right, exactly. ‘Cause you can find yourself doing work that… Then your direct report comes back and he’s like, “Hey, what have you been working on? You shouldn’t be working on that. We have this deadline coming up that now we’re behind on.”
07:27 EC: “It was refactoring Joe’s code. He said it needed to be looked at.”
07:31 MH: Exactly.
07:34 EC: What are some of the other things that you can do to help the junior devs on your team?
07:39 MH: Well, I wanna point out that, this is something that I think a lot of people… It’s easy to fall into the trap of saying, “I think this is something that I’ll be ready to do a year from now,” and you find yourself keep saying that. One of the things that I talk about in my presentation, is I like to point out that obvious things aren’t obvious. One of my favorite examples of this right now, and I give a couple in my talk, is like a Rubik’s Cube. This is a favorite example of mine ’cause I just picked up the Rubik’s Cube a couple months ago, and now I can solve a Rubik’s Cube, but if you look at a Rubik’s Cube and you know how to solve it, it’s always obvious what’s the next move you should do, but if you don’t know how to solve a Rubik’s Cube and you pick it up, it makes no sense. If you have that knowledge it seems obvious to you, but I think it’s a good example because it’s clear that knowledge had to be acquired.
08:41 MH: Now it’s second nature to you. You’ve done this before. You can do it on demand, but you had to earn that. You had to develop that experience, and I think a lot of developers don’t realize the experience that they do have and can pass on. That’s something that people… It’s not part of their day-to-day job. It’s not writing code, so they think that it’s not something they should be focusing on, but in reality it’s very important to build up your team, and everyone has something to contribute. You need to realize that there is a ton of knowledge that you can pass on to the people behind you, and that’s even if you’ve only been doing this for a year or so. You’re already ready to turn around and start giving back.
09:30 EC: Yeah. You think about how long some of us have been working with computers in general. I’ve been probably in computers almost 30 years plus now, and the little things that you do, just by muscle memory, let’s say, those things aren’t as obvious to somebody that’s brand new to the field. Even stuff like what plugins work great in your editor, things like that, are just general tips that you wouldn’t think of giving ’cause they’re just habit, like “I have a fresh install. Here goes Visual Studio and the Web Essentials plugins. I always install those.” It’s just second nature for you to just do that. Your junior dev might need some pointers in the right direction. That might save them boatloads of time, just because they’re not in the same habit that you are.
10:24 MH: That’s exactly right, and that’s the flipside of the coin, is if you’re in a position where you’re trying to bring up a junior dev, you can’t focus on the hard stuff first. The stuff that’s obvious to you is not obvious to them, and they need to be exposed to that so that they can get to whatever the hard problem is that you’ve been working on lately. They need to be built up with maybe a new IDE, maybe a new programming language, maybe a new framework, something that they’re not familiar with. They learn plenty in school but some of those day-to-day things that you’ve been doing for a couple of years are not day-to-day for them yet.
11:05 EC: Going on the theme of pointing out what’s not obvious. What are some of the things that benefit you in doing this for a junior dev?
11:18 MH: Right. I think one of the things that’s missed is, when you have someone new join your team, but especially when they’re entry level, this is a perfect opportunity for you to work on creating the company culture that you want to work in, because they haven’t been exposed, basically, to any kind of company culture before. The people who join your team new but they’re mid or senior-level, they bring that previous experience with them and those previous ideas, and they might work to shape the culture, but if you’re imprinting the company culture on someone, they’re gonna turn around and do that to the next person as well, and it won’t take too long before that starts to work its way through, and you really have a great chance to influence the future of the company that you’re working at by being involved in an entry dev’s growth that early on.
12:14 MH: But a couple other things that I covered too, is… And I know this is true for me every time I go through my code. But if you are explaining code to an entry level dev, there’s gonna be so many times where you’re like, “Oh, okay, so this is where we had to hack this together,” or “I know this comment says this. That’s changed since then.” It’s actually a great opportunity to find some weaknesses in your code base too, things that have been lurking there for awhile, maybe some crafty corners that you haven’t touched since the last time that you explained the project to someone who was new, and those areas that don’t get touched often. And they’ll ask questions from a fresh set of eyes too, so it’s an opportunity to improve your code base as well.
13:11 EC: Yeah, you get a new perspective on things, so that’s a win for you. They might see a better way of doing something that you don’t realize because you’ve been there for X amount of years, or you’ve been doing it this way for so long that maybe they learned something, or just a past experience of theirs and maybe even just using a different language, they might see something that you didn’t see before.
13:35 MH: Right. Plus, typically, and obviously this isn’t always the case, but if you’re bringing an entry-level dev on to your team, the most common thing is they probably just graduated from college. Nowadays maybe they came from a bootcamp as well or something, but they were just in a very specific training learning some, in many ways some very basic things that it’s actually easy for more senior developers to forget, like “Oh, you’re using the wrong string comparison there. You’re comparing string pointers and not the contents of the string.” and they can remind you of some of those basics that they’ve just had hammered into them for the past several months or years and you haven’t necessarily thought about for awhile because you haven’t been in learning mode. You’ve been in doing mode, and sometimes you just forget the things that you haven’t done for awhile, but they’ve just been tested and quizzed and doing projects on all that kind of stuff and they can bring that refresher knowledge to your team as well.
14:37 EC: Do you have any past experience where you’ve done some of this supporting junior devs and it’s either turned out bad, good or indifferent?
14:50 MH: I think one of the things that I wanna point out is a way to have success here, is to make sure that you don’t get caught in a rut of doing what’s worked before. I’ve been on a lot of different teams. One team that I was on, I was basically the sole senior developer, and we had a guy who was fresh out of college. We had a guy who was fresh out of technical school and we had a guy who actually did not finish college and he was self-taught. It was a much different experience than, for instance, the team that I’m on now where we have a pretty even mix of junior developers and more senior developers, and obviously everyone’s just different. Everyone has a different background, different interest, different personalities. It’s important to realize, when someone tells you something that’s worked, you gotta apply that with a grain of salt, and take into account the exact circumstance that you’re working with.
15:44 MH: I think that’s a good point to make. I think we’re actually doing very well now. The team that I’m on has a couple entry-level devs, and an equal number of more senior folks, so we have a great opportunity to work with them one-on-one at times and train them up. When you have an entry level dev that wants to learn, they just latch onto that, and you can tell they really just wanna grow in their career and take it to the next level. And as you’re doing that together you really both benefit, because you have different perspectives. I especially like working with people who come from these code boot camps, because there’s a certain diversity that comes from that kind of background, as opposed to your more traditional college education. And also I think there’s a certain enthusiasm that comes from someone from that background that’s infectious. The willingness to go through a program like that, sometimes leave a career and take up software development, it’s not hard to be inspired by that.
17:06 EC: Yeah. I remember one year I did an event called Code PaLOUsa, and I’m from Louisville, so I knew they had a program like that. They have a program that’s by the public works there and it’s called Code Louisville. They take people and they train them, for free. It’s done through the Louisville Public Library and some other things, like Treehouse is involved. And we had 10 tickets to this conference that we didn’t have to use for, so we donated those to Code Louisville. And watching those people make time to get to the event and attend every session possible, was just inspiring in itself. They’re finding babysitters in there trying to take off of work or working all night after the event to make up for the time they missed. They’re just really, really wanting to learn, so they’re doing everything possible to get in there and take advantage of that free training that was offered. It’s good to see people that really want to learn, and it makes it easy to teach them because you feel like you’re getting investment from your time back from people that are really appreciative of it.
18:26 MH: Yeah. I think we’re really lucky to be in this field. It’s very exciting. It’s hot right now, and sometimes we need a reminder that seeing these people come through these programs, it’s just it’s very on-point. It really can get you energized, if you’ve had a bad week or your code’s just not working. Just realize people are literally taking opportunities like that just to try to be involved in what we’re doing.
18:53 EC: Knowing that you can help them make a better life for themselves is rewarding also.
19:00 MH: Yeah, it is.
19:03 EC: Speaking of events ’cause we’re at Stir Trek, is that something that you would do with a junior dev, maybe take them to an event with you and do some training that way? Is that a good mode of getting junior devs on board?
19:19 MH: Yeah. I think it’s a very cool opportunity, and one of the things that I talk about is trying to imprint on an entry level dev that you work your job, let’s say 40 weeks, standard, things like that, but you should be trying to do something that helps you further your career. What I try to encourage people to do is, even an hour a week, and I say that’s on average. If you go to an event like Stir Trek where you’re spending all day doing something, that’ll probably hold you over for a month or so, an event like that. A conference is definitely a great way to get exposure to a lot of different things. Not all of the sessions you go to you might walk away with something that you wanna go home and try on your own, but you’ll get exposure to a lot of different areas, or you might find a track of several talks in a row of something that you are very interested in, but it’s about expanding your horizons. And conferences, obviously are something that I believe in, being a speaker here at Stir Trek, and it’s a great opportunity to get out and see what’s out there, especially when you’re early on in your career. You haven’t necessarily been exposed to a lot, and you don’t maybe necessarily know how to start on your own. You can go to a couple sessions and pick the most interesting thing to you from that day and then try to spend the next several months doing a project on your own, or maybe even meet other people who are interested in and do some collaborative work.
20:58 EC: Yeah. One piece of advice I’ve given… Wouldn’t just say junior devs, this goes for anybody that’s learning any type of code. Even if you’re at a senior level, there’s always something new [chuckle] that you don’t understand, and that is to go to a session. Even if you think it’s a billion miles above your head, go to it anyway. Listen to it, and I guarantee you three months down the road you’ll be working on something and you’ll go, “Oh yeah, I remember when I was in that session this speaker mentioned you can write the code this way or download this thing that’ll help.” There’s gonna be a tool or a piece of syntax or something that you’ll remember. You’ll be surprised at how your brain goes back and rewinds and remembers those things that you saw and you put the pieces together later when you do understand the basic building blocks of whatever was over your head back then.
21:56 MH: Right. Yeah, some of the advice that I like to give people, is if you’re not finding yourself saying, “Oh, if I had known this back when I was working on that project, it would’ve made things so much easier.” If you don’t find yourself being able to say that a couple times a year, then you need to consider finding ways to pursue new knowledge.
22:23 MH: Because it’s so common that… There’s new programming paradigms, new frameworks all the time, and if you’re not out there, just even taking a survey of them and seeing like, “Oh, this would have been a great fit for that problem we had that we literally had to hack a workaround for, this is the library that would’ve solved it.” Now you’ll have it for next time.
23:20 MH: Right.
23:20 EC: You see these things get churned up in other places and it helps to… It helps to know other languages too, and go back and forth to give yourself different perspective as well.
23:31 MH: Right. The concepts do tend to bleed over. For me, I’m a Java guy. We just got Lambda’s, and if you didn’t have some functional background, maybe you don’t care, but when you realize the power that can come from something like that and to have it exposed now to your language, you’re ready to go with it if you’re familiar with the idea, otherwise you’re just like, “Okay, that’s another tool that I will put in the back of the shed and let it get dusty.”
24:12 EC: And everything old is new again, right?
24:13 MH: We’re all reinventing the wheel.
24:14 EC: It’s probably all been done before my generation.
24:19 MH: Java’s just doing in it in a more verbose way.
24:24 EC: It’s a fun space to be in though. I enjoy it, and I enjoy helping other people that are new to it learn. And another piece of advice that I have as a speaker, is approach speakers. You’re a speaker as well. We’re not above anybody else. We’re here to actually talk to people, and it doesn’t have to be on a stage setting. If you see somebody with a speaker badge on, pull ’em aside and ask them questions.
24:56 MH: That’s absolutely right. Generally they’re here because they want to talk to people, and one of the ways that a speaker will do that is by standing in front of an audience and delivering a scripted presentation, but for most speakers I would say, they actually hope that someone will pull them aside afterwards and have a conversation about something either that they talked about or that is relevant, or just to say, “Hey, I’ve seen you speak once or twice. I hope we run into each other again,” start a conversation, start a relationship. There’s not gonna be a speaker out there who’s gonna run off the stage right after a presentation and try to duck anyone who has a question.
25:42 EC: Not usually. [laughter]
25:45 MH: I suppose if you go to enough conferences there’s gonna be one, but generally the mind set is that they’re here to engage with you. I know, for myself, that there’s nothing special about me. I’m just a guy who happened to get his abstract accepted.
26:02 EC: That’s right. 99% of the time speakers are very approachable, and you can have some really great conversations, which is why I started this podcast. [chuckle] I knew I could find speakers that are willing to come, like yourself, and find yet another platform to talk to people and mentor new people and help teach those junior devs.
26:25 MH: Yeah. That’s right.
26:26 EC: So great stuff. Where can we find more information about your talk or yourself?
26:32 MH: I will be submitting my slides to… I think Stir Trek is doing a GitHub page, or a speaker slide desk, or whatever it is. I’ll definitely be submitting my slides to that. You can find me on Twitter. I am underscore, secondhand. If you don’t put in the underscore you’ll either find there’s a used thrift store, and there’s also a band that… I’m trying to get in on their territory. That’s one way to reach me. Or I’m out there at conferences. I go to Code Mash, Stir Trek. I will be going to Code PaLOUsa this year.
27:13 EC: Excellent. I’ll see you there.
27:14 MH: Find me after my talk. Ask me for a business card and we’ll get in contact.
27:20 EC: There’s a lot of great conferences around the Midwest area. Code PaLOUsa’s a great one, that’s coming up June 7th, I believe.
27:32 MH: Yeah, I believe so. Just about a month away.
27:33 EC: Yeah. Still tickets available; some great speakers like yourself are coming, so come out and see either one of us there. And good luck with your session.
27:44 MH: Oh thanks. Same to you.
27:46 EC: Thank you. Thanks for coming on the show.
27:48 MH: I appreciate the opportunity.