The myth of junior developer risk and how to create a balanced engineering team with Lee Warrick of Tech Jr

Transcript

Ledge: Lee, it’s great to have you on. Thanks for joining.

Lee: Thanks for having me.

Ledge: If you don’t mind, give a quick intro of yourself and your work, for the audience.

Lee: I’m a career changer. I went through coding boot camp and then got hired right away into a big management consulting company. From there kind of learned some lessons and then got hired as a frontend developer at an e-commerce shop.

Aside from that, having been a career changer and just really in touch with the junior developer experience, I started my own podcast called Tech Jr. Also started a meet-up that’s focused on helping out junior developers.

Through that experience, really found a passion for helping out juniors and also helping companies understand how to employ juniors and utilize that wealth of resources that’s out there.

Ledge: Yeah. That’s a huge topic. People come our way all the time.

Off-mike you and I were talking, that we tend to focus on the very senior developer set. I know there’s a huge demand for juniors for all kinds of reasons, some of which are good reasons and some of which are not good reasons. The bad reasons being, well, at least it’s cheaper. I think that’s a little bit of a misnomer, but it’s a really great part of a strategy for a hiring company for all kinds of good reasons.

Just talk through that, that experience and what you seen on hiring side, and we can get back to the developer side after that.

Lee: Sure. What I’d see a lot, from talking to a lot of companies that are out there through the meet-up and just through our own community, is that nobody wants to hire juniors – unless they’re a consulting firm or a giant company or something, they have a lot of processes in place to handle juniors.

Your typical startup or a smaller company, it seems like they’re really focused on delivery and they don’t want to slow down anything. They just ran a super tight ship. The thought of taking any risk especially on a new person or a junior developer, it’s like they can’t handle it. They don’t even want to think about it. You see a lot of job postings for senior developer and you end up seeing crazy postings like, “Oh we need a guy with ten years of React experience or that sort of thing.

Ledge: Yeah, right. Ten years of React experience.

Lee: Exactly.

Ledge: That’s a good one.

Lee: But there are, like you said, a lot of benefits to hiring junior developers.

Ledge: Yeah. There absolutely are. Maybe we should start with some of the misnomers there.

You probably believe some of those things are partially true – the reasons that people don’t want a junior person on – but which of those are myth and fiction, and which do you think ring true and then how do we deal with it?

Lee: I think there’s really two big ones that companies look at when they say, “No, we’re not even going to bother.” The first one is technical debt.

The idea is, you hire a new person, they come on and, not only are they tying up your senior people that are no longer working on tickets, but they’re mentoring, but the new people are writing code that’s not great and then your senior developers have to go back and rewrite that code.

It’s true, you do have to watch out for that. Just like you would have to vet any developer coming into your company, you want to make sure that they’re onboarded properly and that they write decent code.

The misnomer there or the myth is that if you hire a senior developer that they’re automatically going to come in and just write perfect code. Everybody has to get onboarded, whether or not you have a ton of experience or a little bit of experience. Maybe you’re a little bit faster if you’ve done it before, but maybe you’ve also brought with you a lot of bad habits and bad practices from a previous shop.

Ledge: Yeah, a greater level of opinion that it might not…

What you hit on is that there are best practices and hiring for anybody, and what you really want to be doing is understanding, how do we work as an engineering organization? How are we going to onboard and train anyone?

Every company has their own way of using tools and technologies and their own version of writing code. I mean you can say React but there’s going to be 20 different ways that people utilize that framework, and it’s not enough to just name it. We get lost a little bit that, for example two A+ senior unicorn super rock star ninja developer is coming in writing React, they’re still have going to gel, and they’re still going to have to… They made it to the ground running but who’s setting the standards and where do those things come from?

What I think hear is that, a lot of this comes down to really good management and engineering practice to begin with, and that’s a separate dimension then from how senior a given developer is.

Lee: It’s especially prevalent in web development because, talking about React specifically, React is super un-opinionated. You can have those two rock star ninja developers come into your company, but if they both came from separate companies, they’re both used to working on wildly different code bases – because company A wants to use the Fetch API, company B used Axios – company A has a pages directory for all their pages on the website, company B just has components. The projects are going to be totally different.

You may hire those two engineers on and they both have very strong opinions about which one’s better.

Ledge: Absolutely. There’s a misunderstanding, at least a little bit, of who’s to blame for technical debt, I think is part of it.

What are some of the other points there? You talk about the mentoring. Does it actually consume a great deal of time from the current senior players in order to do that, or is that really another myth?

Lee: I think the issue there is that, if you have a practice of only hiring senior developers, you don’t really have any systems in place to onboard anybody else. You hire on a senior developer, you sit him at a desk and you say, “Hey, we expect you to make commits in two weeks,” and then you don’t touch that person.

Whereas, if you’re hiring a junior developer, maybe there’s some paired programming going on, there’s some onboarding process, there’s a little of mentorship where a senior person will sit down and say, “Hey, let me show you the code base,” and get you up to speed.

The more that your senior people are doing that, the better at that that they’re going to get. You’re going to be grooming your senior people to be better mentors, which means that you’re going to be able to handle junior developers, or even midlevel developers, much more easily.

Ledge: “But Lee, we need to move fast. We need to ship product. We’re 50 years behind on our backlog and we’re drowning.”

How do you answer that, because I think the urgency sometimes overwhelms the good thought process.

Lee: I definitely hear that. That goes back to what I was saying about there’s this, we have to iterate quickly and we’re a startup, we’ve got to get the product out yesterday.

There’s some level of compromise there where you have to not overload your senior people and give them some time to mentor. There’s a couple of ways to get around that.

For instance, internships. Maybe you bring on somebody for really cheap and you just give them a test run and then they can help out with the minor tickets that your senior devs can throw their way. They’re still going to need a little time to mentor that person, but you can try before you buy. Now, that being said, don’t be that company that just has a continuous stream of interns doing…

Ledge: Just abuses interns. Yeah. “Five dollars an hour, we’re going to get code bug crushers!”

It’s really not like that. I think you’re right. At the same time this company wants to launch or do whatever they’re doing, a smart company would also be thinking about, hey, what happens when we’re successful and our entire code base is controlled by one senior guy who doesn’t know how to manage anybody? Doesn’t know how to set code standards, or documentation, nothing’s commented?” All of that is processed at. It’s so-called the dark debt that you can’t get your head around when you need it and you start to have production outages.

I’ve seen companies be really successful – and this is not just in developers and engineering – but when you bring on more junior people, their number one job is to ask questions and write things down. To start to build that internal knowledge base and sharing. It’s great for business continuity.

That’s the kind of environment, maybe from a consulting company. Whether or not we all had fun in consulting companies, the one thing you learn there is that you ought to be transferring knowledge and you should be writing that stuff down because you owe it to the client.

Maybe if we acted that way as producers inside of our own companies, we would build a more enduring asset, and that full picture is really important.

Lee: Definitely if you had an intern or somebody new working on documentation, not only are they learning the code base but they’re creating a way for you to onboard people in the future. Their kind of knocking out that lower-level work that your seniors aren’t really spending time on either anyway. You’re spending a little bit of money but you’re getting a lot more out of that.

Then, of course, what happens? You’re going to have junior people asking the senior people, “Hey, this one feature, how does this work?” Then they’re doing a little bit of testing at the same time and exploring some of the practices that have been maybe passed over whenever you’re iterating so quickly.

Ledge: Right. “We didn’t have time to deal with that, just like we don’t have time to deal with new people, so now…” That is the definition of technical debt and the code isn’t going to scale. You make a good case, why do you want to hire the juniors.

Are there some legitimate downsides? Or maybe the best way to put is not your downside but just, what do I be prepared for in order to do this right? I think we can demonstrate that there are meaningful benefits and every senior comes from being a junior.

Lee: There’s some approaches that you can take. Namely, you have to slow down a little bit. You have to be willing to invest either money or time into your people and your company so that you have a process to get new people as you grow.

If you’re so short-sighted that you’re only worried about the product, what happens when your senior guy says, “You know what, I’m tired of working so hard. I’m going to go work for this other company that is only hiring senior devs also and they’re going to pay me another $30,000?” That person leaves, now you’re stuck with, “Well, gosh we have nothing in place to onboard people. We have nobody that’s good at mentorship. We have no documentation, and we need to hire a senior person to figure all this out.” That’s what you’re buying into when you iterate so quickly.

Ways to prevent that and allow yourself to hire on some juniors is to, like I said, don’t overload the senior people. Expect them to spend some time mentoring and doing code reviews and pair programming. Also, invest in the culture a little bit. Provide educational opportunities. Get people excited about development and where they work, and make sure that they’re happy there.

Then, if you want to keep the people that you’re hiring that are new, you’re going to have to pay them as their experience levels up, in a way. That’s another huge thing I hear about junior developers is, “Well, we’ll hire them on and then in a year they’re going to leave for another job.”

Ledge: It’s sort of the expectation that everybody should have of all engineers, if you are not in an awesome place to work. Engineers of all stripes have available to them many, many opportunities now. I think in software engineering and development it’s a seller’s market.

There’s an opportunity at all times to be recruited to something else that will pay you more money. It is incumbent on the organizations to really think about retention.

I also think that engineers look at retention in different ways. As you talk to junior mostly, what are the things that they’re telling you that they wish for, or that could be better, or that would keep them around?

Lee: I can tell you what they never say. They never say, “Oh man, I wish this place had a ping pong table,” or, “Man, I wish we had a beer keg in the office, or a whiskey bar or something like that.” That flashy stuff is neat for the first five minutes you walk in the door, but what people really want is a place where they feel like, if they get stuck, they can turn and ask the senior person next to them, “Hey, when you get like five minutes, can you take away this bug or take a look at this ticket? I can’t really figure it out.”

Ledge: That five minutes comes within the next hour. It doesn’t come like with a grunt two days later of, “Stop bugging me.” It’s so much about that attitude.

Lee: Exactly. There’s a lot of developers out there that are very passionate about that culture and atmosphere, and you can see that if you follow anybody on Twitter that’s a big developer or famous in that space. They’re really invested in helping new people. They’re super passionate about the code that they write and making it better and creating a community around it.

I’ve even seen that running the organization that I run, where you say, “Lee, you probably talk to a lot of junior developers.” To be honest, I talk to more senior developers than junior developers because those people show up in droves wanting to help.

It’s just matter of harnessing that within your own organization and getting that positive energy going where you’ve got people that… Maybe you’ve got a senior that’s own some absolute miserable bug that they’re working on, but then if they can take a break and work on something that’s simple to them and then get that dopamine hit of helping somebody, maybe their mood is a little better when they go back to that problem they were working on.

There’s a lot of like underlying benefits that you just don’t see in dollars and cents when you’re looking at it from really high level, but when you dig down into it I think it’s something that we need to really embrace as an industry.

Ledge: You’re making me think, and what just popped into my head is that your junior developer program, if you will, at a company is really going to be a valuable lens into your company culture. The things that you do, and the ways that you scale, and are you a place that people want to be? They will have that unique perspective.

Particularly someone like yourself coming out of a different industry, there’s a lot of practices that you’ll bring, having had experience working in orgs and now can apply that to code architecture. There’s junior with absolutely no work experience, and there’s junior with career change. Do you see any differences between those two types of groups and the things that you’re saying?

Lee: Yeah, there is a huge difference. Even just going through the journey that I’ve been through, you can tell when somebody is straight out of school or straight of college and they’re very young, they’ve never worked a job before. Those people need to be handled with care and need a really good interview process to sniff out the people that don’t even really care about development.

But then there’s also career changers where, they’ve left their previous job and their entire life behind and said, hey, I want to go after this development job. Some of those people are very passionate about it and they’re motivated, and they do spend a lot of time improving themselves and writing code. Of course, bring with them a lot of experience from other industries and a lot of insights.

So soft skills. They’re good communicators. They know how to handle customers, maybe. Maybe they have like IT or helpdesk experience. There’s a lot to be gained from hiring somebody that’s a career changer.

Again, especially in web development where, how senior is the senior person? Everything’s changing at such a rapid pace, how much value do you really get out of hiring somebody with ten years’ experience? The web doesn’t look anything like it did ten years ago.

Ledge: Ten years of React isn’t going to help you. Unless you wrote React.

Lee: Exactly.

Ledge: Even that would be, what, be five years old? Yeah, I get it. I think we all poke at the fun recruiter ads that don’t understand the technology at all.

I will second… I’m having the other way in my career. I’m always grateful for the problem solving ability and self-learning that is required in the engineering mindset. It’s also very useful to a business and all different other functions. If were to go back to coding – and I think about that a lot because I loved doing it – that context from the other functions. Which is really what you’re talking about. Sales, marketing, customer service, even different industries. That can be a real competitive advantage that companies could then acquire far below market value.

You’re going to have to level them up, you’re going to have to give them commensurate raises but, pros and cons all sort of being on the table, that sounds like a pretty good investment.

Lee: When you’re talking about helpdesk and IT, there’s a lot of hungry junior developers out there. Whether they’re career changers or not, you can maybe hire and them into those helpdesk/IT roles that you may have and let them knock out a few tickets with the Dev team, so they’re learning two sides to your business. If they work out, great, transition them into development. If they don’t then, hey, you have a helpdesk person, or they’ll eventually leave anyway. But they’re in a lower risk position than if they were actually writing your code base.

I think there’s a huge opportunity there as well to try before you buy.

Ledge: The risk orientation is a really good point. I hadn’t thought of it that way.

Well Lee, awesome insights. Where does everybody Tech Jr.?

Lee: You can find the podcast at techjr.dev, that’s T-E-C-H-J-R dot D-E-V. You can also find us on iTunes, Google Play, all that good stuff.

Ledge: Fantastic. I’ll make sure that we push that out there.

Before I let you go, critically important questions in our lighting round. Are you ready for this?

Lee: Yeah, shoot.

Ledge: Alright. Star Wars or Star Trek.

Lee: Star Wars, 100%.

Ledge: Alright.

Lee: I appreciate the Star Trek ethos, but it’s a little boring at times for me.

Ledge: It’s funny how many people say Star Wars and then need to caveat and not offend the Trekkies, so appreciate that.

What are you reading right now?

Lee: Not really reading a whole lot, just doing a lot of like video coding tutorials. Learning about React Spring and animations, all that stuff.

Haven’t really had time to pick up a book recently, to be honest with you, unless it’s a technical book.

Ledge: Fair enough. What can you not live without?

Lee: Oh, guitar. Got to play guitar.

Ledge: Nobody can see the video here but he’s got a big old rig behind him, so I bet there’s recent jamming going on here.

What’s the last thing you Googled for work? Probably same answer as reading.

Lee: Oh man, last thing I Googled for work. SEO is the last thing. Schema.org and JSON-LD, all that good stuff.

Ledge: I don’t know if you’re an Office fan, or a fan of The Office, but I like to watch that show, so I refer to it here.

Jim is, as most people know, The Office protagonists and Dwight is the office heel. There’s a classic episode where Jim is sending faxes to Dwight from future Dwight. He’s messing with him and he’s saying the coffee is poisoned and things like that. I like to ask people, if I gave you a piece of paper and one of those big, thick black Sharpies and you are future Lee and you can send that fax back to yourself in your past, what do you scroll out on that paper?

Lee: Probably winning lottery numbers, to be honest with you. I don’t really like to…

Ledge: He’s a pragmatist, folks.

Lee: You’ve got to be practical. I don’t really want to sit and reflect on my career path and how maybe I could have done better or worse. I’m happy where I ended up. The journey was a big process that made that happen, even though there were missteps along the way.

I started out at the University of Florida studying computer science and then I moved away from it and didn’t pursue it for ten years after that. Maybe if I had continued with it, I’d be in a totally different position, worked with different companies, learned to hate it and then maybe never discovered it in a way that makes me happy in the first place.

Ledge: Well Lee man, thanks for being a good sport. Thanks for talking about the junior developer stuff. I think it’s a really important missing topic in a lot of the thought leadership that’s out there in our space. Keep up the good work. We’ll be watching.

Lee: Alright. Thank you.