Escaping the Software Trough of Despair With Laurie Barth

When you are a consultant, you can't just learn a framework and then choose a place to work that uses it. Your clients will have their own needs and constraints that you're going to have to adapt to serve your client well.

The constant learning can feel like a freefall. Constantly feeling dumb is panic-inducing. There's this trough of despair in software, where you swing between feeling like a genius and then going right back to despair.

We can't just learn, but we have to learn well. It's critical to retain what you learned. Keep a developer journal, start a blog for yourself, discuss what you learned in a study group, etc. The less you have to relearn things, the less time you'll be spending in the trough of despair.

The dreaded technical interview tends to have the problem of not testing you on anything that you should be learning. You have to spend your time cramming and hoping that the interviewer gives you problems that are still fresh in your mind. A one size fits all solution doesn't work and doesn't end up being objective. Candidates should get the opportunity to show off their skill and what they already know instead of figuring out what they don't know.

Transcript

"Escaping the Software Trough of Despair - With Laurie Barth" Transcript

Laurie Barth

• Twitter
• Website

Joel Hooks

• Twitter
• Website

Transcript

Joel Hooks: Hi Laurie.

Laurie Barth: Hi.

Joel Hooks: I am super stoked to talk to you today, mainly about the tech interview pipeline and the issues that we see with that. But I wanted to kick it off, and I know that you are a board game aficionado. I am as well. And I was wondering, what do you have on deck? What are you playing right now? What are the board games that we should check out?

Laurie Barth: I have a new obsession with the game Azul, I don't know if you've seen-

Joel Hooks: Oh, it's great.

Laurie Barth: Right? It's so much fun. It's aesthetically pleasing, which I always love. But I love making friends play for the first time on the side of the board that isn't predetermined and watching them get through two rounds and think they're doing really well, and then panic that they didn't plan out their pattern well, and they're locked and they can't do anything.

Joel Hooks: I like that one. And a lot of my focus in general lately, because I have all these really complicated board games that take two hours to explain and set up, and what I really love, like I've been trying to ... And Azul fits in this, it's the 8+ games, right? That are really deep and have a lot of strategy but don't take an hour to ... or aren't intimidating to get started with.

Laurie Barth: Exactly. I always love games like that. Splendor for example, my husband and I learned it as a two-player game, and it was fun the first time we played it. But we're like, "Oh, that's all there is to it?" And the second time we played it, we realized that it gets more and more analytical and subversive. And I love that because at first glance it's super simple and easy, and then you realize that you can start purposefully preventing the other player from doing well, and it gets really tactical.

Joel Hooks: That's nice. I've also really loved Moniker lately. I don't know if ... Have you seen this game?

Laurie Barth: Ooh, no, I haven't seen that one.

Joel Hooks: It's like ... there's Cards Against Humanity, right?

Laurie Barth: Right.

Joel Hooks: Which I played, and it was all chuckles, and you could see grandma say just absolutely naughty things. And then after a few times, it's like, "Wow, grandma's saying naughty things, and I don't like it." It's like Facebook during political season, and I don't want it anymore.

Joel Hooks: So Moniker kind of takes that place. It's like this party game and you can play with up to 40 people, and it's actually kind of a creative commons license. It doesn't have a copyright or whatever. You can make your own version of this game. But it starts, and you go around, and it's kind of this combination of charades and guess the entity, and just really is one of my favorite fun party games.

Laurie Barth: Yeah. I was just gifted, I don't know if you've played Code Names, but I was gifted the Harry Potter version of Code Names, which I haven't tried yet. So that's definitely on deck.

Joel Hooks: Yeah. Moniker is in the same category as Code Names in terms of like a fun party game that gets people enthusiastic. It's super simple though. That's what I love, too. I just love something you can hop into and everybody kind of inherently understands and you can just have fun.

Laurie Barth: I'm going to have to check this out.

Joel Hooks: But then I'll also play a 12 hour Twilight Imperium session.

Laurie Barth: Oh, do you have Twilight Struggle?

Joel Hooks: Yes, I have it and haven't played it. I've been scared of it to be honest.

Laurie Barth: It's a little intimidating, I'm not going to lie. We've gotten through it I think two or three times and every time I have to refresh the rules for like five hours.

Joel Hooks: Yeah. It's thick. Is it GMT games that makes it? They make all the simulation games, like you get their train simulators where you have like a functioning stock market and it's like wow.

Laurie Barth: We get smarter when we play these things. Learn a little bit of history.

Joel Hooks: So they have a mini game that's called Twilight Squabble. It's hilarious. It's a tiny box. It's a four by three box and it takes 20 minutes to play it. It's like the essence of, of Twilight Struggle, but in this tiny little little box. If you like Twilight Struggle, you might like it.

Laurie Barth: Definitely going to have to look all of these things that my husband is going to thank you so much for all the money I'm about to spend.

Joel Hooks: Yeah, I have to stop watching board game YouTube sometimes.

Laurie Barth: Oh, boardgamegeek.com is dangerous for me. I subscribe to their newsletter and I just should not.

Joel Hooks: It's like, yep, need that, need that.

Laurie Barth: Exactly. It's like, Oh there's a Kickstarter. I mean it's not like I can wait. If I don't give them money then the game won't exist. I won't get to play it.

Joel Hooks: Bonuses, miniature stuff. Great.

Joel Hooks: So this is a, I mean this is a podcast about software development.

Laurie Barth: Same thing, right?

Joel Hooks: Board games are awesome and I think there's a lot of crossover there, to be honest. But I was curious, how did you become a software developer? What was your path to this field of work?

Laurie Barth: So it's a little bit weird. Starting from a really, really young age, I was going to be an attorney because both of my parents are lawyers and my dad tried really hard to convince me not to do that. Going into college I was like okay, I'm going to study government so I'll do great in law school, but I'm going to also major in mathematics because I just loved math. I always loved math. And the kind of merging of those two things is political polling because I particularly like statistics. I happened to go to a college, Franklin and Marshall college in Lancaster, Pennsylvania, where they have a political poll that runs off of campus. And I interned there for three years and I had a boss, shout out to Angela, who was amazing. She said the only way I'm going to let you be a summer intern instead of just a school year intern is if you promise me that you'll take a computer science 101 course while you're interning, like in the evenings.

Laurie Barth: I kind of pushed back and I was like, I'm not that geeky, I'm not that hardcore." And she's like, "No, no. I've had to teach myself all this stuff. If you ever want to work in this field, it's going to serve you really well and this is the advice I wish I'd gotten." Of course she was right and I loved it and I ended up minoring in it and eventually getting my masters and the rest is kind of history.

Joel Hooks: Yeah. And then here we are, right?

Laurie Barth: Right, exactly. Yeah. No time has passed since she gave me that advice and today at all.

Joel Hooks: Now you're a consultant essentially, right? You work for a consultancy and you help organizations build software and that sort of thing. Looking at your past and the present and your observations about this field, what are some qualities of a really good software consultant?

Laurie Barth: I think there's a lot of things. Software consultants have to be comfortable wearing a lot of hats and being unopinionated, which sounds weird because obviously you're supposed to give your perspective and your ideas, but you can't sit there and say, this is the technology I like and this is the technology I'm going to use. You have to ask the right questions and make sure that you're picking tools and solutions that work for the constraints and the realities of your clients. That's kind of the opposite of how a lot of product builders work in terms of, "Hey, I love working with React or I love working with Python and I'm going to go out and look for a job where I can do that." I don't have that luxury and that's both a blessing and a curse. I learn whatever it is that I need to learn to best solve the problems of the clients that I work with.

Joel Hooks: Does that keep you in, I don't know, almost like a mild state of panic in terms of new clients or new projects? Do you go in and ... how do you deal with that? This feeling that I don't really 100% know this but I can learn it.

Laurie Barth: Yeah. I was talking to my boss about this probably about a year ago and I said, "I'm doing too much constant learning where I feel like I'm constantly in free fall, and I'm constantly like on unfamiliar terrain and I don't really know which direction to go." One of the things he mentioned and I think has really served true is, if you're going to be in a field where you're constantly learning, which all of software development is to a certain extent, you need to make sure that you have a pretty good balance between learning and then using what you've learned. If you don't get to use it for any length of time beyond solving like a quick immediate problem, you just get frustrated because you're constantly going through these iterations of feeling stupid, right? It's okay to feel dumb maybe 50% of the time, but feeling dumb 100% of the time gets frustrating and a little bit panic inducing.

Laurie Barth: So you're absolutely right. It is hard. And I've tried to find a balance and 10 Mile, my company, has been really great in helping me find that balance. And then the other thing is, you get really good at failing quickly with documentation. I've learned a lot about what good docs look like, at least for my type of learning. And so when I need to solve a problem, when I need to learn a new technology, I'm pretty fast at doing a quick scan. Figuring out if investing time in this particular resource is helpful. And if it isn't, I go onto the next one because I don't have the time to waste and it's not going to help me solve the problem.

Joel Hooks: So what are you looking for in good docs? What are the signals that speak to you when you were doing this research?

Laurie Barth: It does a bit depend on what I'm working on. So if it's a technology that I already know, I tend to look for a straight up API writeup saying, these are the parameters and these are the functions available to you, and here's an example or two of how they work. I'm big on examples. If it's something I don't know at all, I much prefer kind of a scaffolding or a skeleton of what a project should look like or a function should look like or an example. And then I'll take that, deal with all the dev ops environments, set up nonsense on my computer, but I know that the code itself is working and if I can get it running then I know I can iterate that code to the point I need it to be in. So I'm not struggling on two fronts at once as it were.

Joel Hooks: You mentioned set up and dev ops nonsense and I agree, I think people are like, "Oh it's so confusing. I had a hard time learning React." And then they'll write a whole article about it, and really what they've written about is their struggles with Webpack and Flow and learning Redux and all this stuff that goes around a project. The initial setup is where a lot of the struggle is. Once it's set up, many people can can attack the problem easier. What do you do to deal with that initial setup nonsense? How do you approach that?

Laurie Barth: It's actually funny, Ashley McNamara had a tweet a while back where she was talking about how so many tutorials that we see are kind of missing this step zero of the things you don't know if you're not familiar with that piece of technology. I think for front end, the rise of CLIs has been really helpful. For other pieces of code I'll look for get hub repositories for sure. Anytime I can find a code pen or JS fiddle or something similar, that's really wonderful because it's removing all of that other nonsense and when you remove all that noise, I'm like, Oh, if this is working here, I'm just missing X, Y, Z. But I think a lot of it comes with experience and saying, okay, I've seen that error, I know that's an NPM error or I know that's a versioning issue or a permissions issue. I wish there was a better answer for that other than once you see it a couple of times it kind of sticks in your brain and you remember it for next time.

Joel Hooks: For me too, it's a lot, how do you read blogs and how do you parse that? It's so much noise and then you're trying to find the actual problem. For me, from years of teaching in a workshop setting and actually being a consultant too, the ability to spot simple typos or just little patterns, like a visual scan that gives you pattern recognition, I guess is the word.

Laurie Barth: It's funny that you say that because I'm pretty sure anyone who follows me on Twitter will see that every Friday I'm posting some really stupid typo. That's my signal that I need to go home.

Joel Hooks: It's time for the weekend.

Laurie Barth: Right.

Joel Hooks: On one hand it's disheartening, right? You spend hours and you discover that it was like a misplaced character, and at the same time there's this sense of exhilaration that comes from solving that problem. To me, and you mentioned kind of the trough of despair or kind of this feeling of ignorance that we get in software. Then you go and I feel really dumb, and then you feel like you know a super genius and then really dumb and a super genius and it's a sign wave.

Laurie Barth: It's funny that's, it's kind of the definition of being a software developer, right? It's constant despair and then you get like five seconds of elation and then you're back in despair for the next problem.

Joel Hooks: Yeah, I love it. And you know, it's like you get the flow state and the puzzling aspect of the whole operation is really fun. If that's your definition of fun, I suppose.

Laurie Barth: Right. I always tell people I was a bit ... this is a bad thing to be, but I was kind of Hermione Granger in school. That was my personality type in schoolwork, in classes and stuff. And I think that's why I make a good software developer because I cared about grades and I cared about those wins that told me I was doing a good job, and I've just taken that mentality and moved it to Jira tickets and so we're good.

Joel Hooks: I know this is important in your work and you've talked about this before and I'm really curious. At some point in your career you are probably going to end up being a teacher and a mentor and I'm wondering why that's important. Why is it important to have more teachers and more mentors helping folks?

Laurie Barth: Obviously we know we have a shortage of people in this industry in general and as we progress, every field and every area is going to require some kind of technical literacy and knowledge. We're constantly looking for mid level people and senior level people and those don't just appear. We grow them. And so as much as everyone in the industry can kind of use the struggles they've been through and their learning and their experience wanting to throw a computer out the window because of some stupid bug, and make that available for other people to leverage and kind of like climb on top of their shoulders. I think we've made it so that we can focus more on what matters and the more gray area conversations that we have around what we're building and why we're building it and how it's having an impact instead of, okay, I just spent five hours getting Webpack to build. I don't have any energy to have these harder, more important conversations.

Joel Hooks: What you're describing to me it sounds a lot ... I'm a front end person. That's like my general job description. We talk about UX a lot and understanding our users and the problems we're trying to solve. Is that kind of a part of that? Are we, as a group of folks with more experience, imparting that kind of knowledge and passing that along? Is that part of being a good mentor?

Laurie Barth: Yeah, I think it's everything. I think it's teaching people, especially people new to the industry, that asking the right questions isn't just about asking Google the right questions. It's about asking the right questions in general at kind of a meta level and within the problem domain that you're working. It's continuing to refocus ourselves, again, on the stuff that that matters. Yes, sometimes that means the performance of splice versus the spread operator, but if we have that written up somewhere and someone's kind of made that knowledge available and not something that you need to test for yourself, then that's half the time that you could have spent on that issue and you can focus on something that maybe has a bit more impact.

Joel Hooks: So when do you know that it's a good time to actually ask for help? We do a lot of research, we spend a lot of our time Googling and reading stack overflow and banging our head against a problem. At some point it becomes more efficient just to either fire up Zoom or message somebody or walk over to their desk if that's your situation and ask for help. How do you know when that's the time?

Laurie Barth: I will admit to being a terrible use case for this. The first software engineering job that I had, I had a wonderful technical lead who let me ask a truly staggering number of questions. I mean the stupidest stuff, and I hate to use the word stupid, but things that I easily could have googled. Instead I went and asked him, and he would answer them. The rule that kind of worked for us was, I never asked the same question twice and so he was always willing to answer. But I think one of the things we take for granted is that when you enter this field, you don't have that Google Fu as it were. You don't necessarily know the keywords you should be putting in.

Joel Hooks: The vocabulary.

Laurie Barth: Or how to find the right answers. And so I think if you try one or two searches or if you really feel like you don't even know where to start, feel free to reach out to someone to ask a question. I don't think there's anything wrong with asking questions. I think the problem comes when you don't take that data point and store it away for later. That's why I talk about developer journals a lot. Basically the idea that you have a document somewhere, whether it's online or directly static on your laptop, that keeps track of all the resources you've looked at and all the problems you've solved so that you aren't having to solve the same thing twice.

Joel Hooks: I encourage people to start blogs if they're able to and have the time and inclination. To me, in my career when I first started, I was 35 years old. I couldn't just jump into this job and make a very entry level salary because I had bills to pay. So I used My Space on the internet. It's still joelhooks.com, as basically my developer journal. I'd solve a problem, get a problem, be confused, do the research, ask somebody, and then take that information and basically write a journal entry to myself about what the problem was and how I solved it. That's the situation where you end up googling and in the future you land on your own solution, which is like an amazing feeling. It's like, wow, look at me doing my, my past self doing my ... shoot yourself a solid. That's amazing. Is that similar? Is that kind of the similar approach to what a developer journal would be?

Laurie Barth: It absolutely is. I think that's why a lot of people actually recommend that people who are beginning write blogs and I think that's a great recommendation. But I also think not everyone is comfortable with that. Not everyone wants to put themselves out there in a public way. There's a lot of different ways to get that same benefit. It can be taking notes for yourself, it can be taking notes for a small group of people, maybe if you have some kind of study group that you're sharing things with. Or it can be publishing it for the world to see. Then you'll end up like I did this morning where someone said, "Hey Laurie, your example is broken. Go fix it."

Joel Hooks: Now you get to support your blog posts. I recommend turning comments off. I don't have comments on my blog because I have never had a fruitful conversation in that way. And a lot of this really gets down to, and I think another aspect of this is is technical writing, which I think is a hugely important skill to have as a software developer on a team, especially as we get more into remote work and this sort of thing. We have to write, and this communication is important. What are your thoughts on learning and becoming a good technical writer?

Laurie Barth: When people ask me kind of what my most critical skill that I think has kind of made the difference in my career is, it's always writing. I went to a liberal arts school and I majored in government so I had to do a lot of it. I think technical writing, there's a couple things that come to mind. There are different voices that you can use and there are different audiences that those apply to. For a while, a lot of the technical writing that existed was kind of this white paper style. A lot of keywords, very formal, almost read like a lab report for the hard sciences. And I think we've moved away from that, made more conversational style technical writing that helps people who need something a bit more accessible, and explaining things in layman's terms, using examples that aren't all kind of like geek chic as it were.

Laurie Barth: I love Ali Spittel, obviously does some really funny stuff with music lyrics from the '90s and modern, which I love. I think having things that are accessible and people can relate to or kind of pique their interest is important. I think it's also important to think about how much you are including in what you're writing. Things that are bite size are a lot more accessible. And so I try as best as I can to break things down into the lowest common denominator that I can. I was recently diving into ES 2019, for example. Every single feature that I came across that I wanted to write about was its own post. I'd give probably two to three examples of it and more explanations behind it. The idea is that someone can jump in on their lunch break and see something that's short and not super intimidating and a quick thing for them to learn and look at.

Joel Hooks: On Egghead if you go and you look at the videos, and we have courses and all that fun stuff because people love things that are packaged and they can watch. You can also take any individual lesson out of that. We really strive to cover a single concept. I want you to get this, take it away, spent five minutes watching this instead of something buried in the middle of an hour and a half. Which would be the difference between the long form articles too. To me written words are much more accessible than than video in that regard.

Laurie Barth: Yeah. I was joking with someone on Twitter the other day about going to YouTube to find a solution to a problem and being like, just get to the point already. I actually ... the ES 2019 stuff, at least a couple of those are currently Egghead videos of mine.

Joel Hooks: Nice. Let's get into what's wrong with the way that software developers are interviewed and hired in this kind of modern age of web development?

Laurie Barth: Let the ranting begin.

Joel Hooks: That's what I'm here for.

Laurie Barth: I'm really passionate about this topic. I don't really know when I became passionate about this topic, but I think a lot of it has to do with feeling like I've passed the gates of jobs where I kind of got lucky, and then really exceeded expectations when I was in the role, and looking back and feeling like there was a really significant disconnect between the skills that I had that my managers were really excited about and thought brought value to the team, and the skills that I had been tested on in the interviews. I think this is pretty common, especially with the kind of stereotypical major company, whiteboard interviews, crack the coding interview, all of that stuff.

Joel Hooks: I have that book. It's super thick. I was reading it and I got it because I was curious. Here's full disclosure. I've had a very light experience in terms of interviewing. Both times I've had, and I've only had two in my life, had a technical interview. They simply wanted to talk about articles on my blog. And I look at this, that's great for me, but when you're looking at this technical interview, I would never pass. I don't even know how to approach that. I'm 10 years into this career and I would never pass without just simply like cramming and prepping it for a specific job interview. I don't even know at the end of the day, does that really signify how this person will perform, or can they do this job that we have at hand? What can we do to be better? How do we improve that, and is that even a necessary part of the standard of hiring folks?

Laurie Barth: I saw someone write the other day that even if you study and you do cover to cover cracking the coding interview, there's still a fair amount of luck involved in what white boarding question they put in front of you and how to the forefront of your mind it is, and whether it's something that you really, really studied. Okay, the solution is optimized for a hash table which you know really well versus a link list which you're a little more uncomfortable with. All that kind of nonsense. We like to think it's objective and it's not. In my experiences, I don't think people need to code in interviews, which is kind of this crazy outlandish statement. There's a couple of reasons for this but the one that sticks out to me is the idea that coding in an interview is allowing you to ask the best questions and get the best people and see whether or not they can code when you put them in your company.

Laurie Barth: The two experiences aren't similar. Coding in front of people with a specific amount of time in a blank IDE, or not an IDE as it were, and kind of going through this whole process, is not at all related to jumping into an existing code base, pattern matching, figuring out problems, fixing bugs, making new features. There's this big difference between a blinking cursor and what most of us experience, which is integrating or working with existing things. There's not a great way to test for that unless you make a mini little bug for people to solve, which, if you want to do that, okay.

Laurie Barth: What I like to do and what we at 10 Mile have done a fair amount of, is we look at an at a resume and find something that piques our interest and ask them about it and say, "What did you build? What did you like about it? What was your experience?" We're not looking for what they don't know. We're looking for them to show us what they do know. Instead of these repetitive questions that we think size up everyone exactly the same way, which they don't, we are catering to the experiences that our applicants have had and seeing how they might be able to teach us something new.

Joel Hooks: It's funny when you say that because now I look back to these job interviews that I've had that I described and I'm like, those were good job interviews. We did. I didn't have ... Give me a blinking cursor or a whiteboard and what you're going to receive in return is crippling performance anxiety for me. That's not who I am and that's not what this job is. For most circumstances it's not a live performance gig. I have a really hard time with that sort of scenario. One of my ideas is that, what if we paid people? What if we paid people for their time and gave them assignments and that sort of thing? I don't know how that scales, but to me that seemed like a better approach.

Laurie Barth: Yeah. Some people are doing that. I think it almost can't be a one size fits all, which I know is a struggle for people because they're thinking hiring, it has to be the same. It has to be objective. But if we kind of threw that away and said, okay, it's never going to be objective because it's people interviewing other people and we have no idea how their day is going thus far and what their mindset is. They may be in a position to do their best, they may not. If we throw that away, I think we get to a point where we say, how best can the candidate show us their skills and their knowledge and what they know, and kind of branch off from there?

Laurie Barth: If that's, I would like to do a take home assignment where you pay me and I show you how I code, great. If the answer is I am a great communicator and I want to sit there and I want to explain to you what I've worked on in the past, awesome. If the answer is I would rather just sit there and have you watch me solve a problem or a bug, awesome.

Joel Hooks: Yeah, like a pair programming kind of thing, right?

Laurie Barth: Yeah. I think all of those can be viable, and the problem that we run into is this idea that one size fits all. We've done a lot of this because we're so afraid of this false positive where we get someone into our company and they're a total washout, right? And they're like, well, if they hack my coding interview, I'm going to add seven gates to this interview process to make sure we get the best person. And that doesn't do that at all. It just creates a whole bunch of other things that you're screening for that you don't actually care about and it makes your candidates miserable and it makes them hate you.

Joel Hooks: You end up with a checklist and a linear flow where really, it's more like a graph versus linear boxes that we tick and we go through these boxes and we'll get a good candidate. And that's because of our individuality as humans. It just doesn't work. It's like I talked about pair programming and often see that as, well you should pair program with your candidates. Unless you know that's what the job is, because there are shops where pair programming is integrated, unless that's what the job is, or even some candidates when they first meet you and you know each other for five minutes, they don't want to sit down shoulder to shoulder. They might freeze. So that doesn't work for everybody. So it's like finding what does work. It's a challenge. It's a really hard problem actually.

Laurie Barth: It's a really hard problem and I appreciate that people are starting to talk about it and starting to share ideas and solutions. And I think when people do that, we have a lot of knee jerk reactions of like, "No, that won't work because of X edge case." And what we have to acknowledge is that all of these are going to have edge cases and so we need ... the adaptability really ends up being the most important thing. Do what will best allow the candidate to shine and show off what they know. And I know in larger companies that kind of freaks everybody out. They're like, it has to be the same. I don't know how to fix that problem, the HR problem and the legal problem and all of that. But I'm hoping we'll get there because we need to.

Joel Hooks: I think there's risks and rewards for hiring less experienced people. You mentioned that folks are always looking for mid to very experienced developers. They want what we call senior developers on staff. But then there's the opposite side of this where what if we take folks that don't have the same experience and develop them and develop their skills and their talents and their professional capacity over time? I was wondering, have you seen that successfully? What do you think about that idea?

Laurie Barth: I've been that kind of newbie engineer who was brought into a company and had the opportunity to learn and really thrive and I'm so grateful for that experience. There are pros and cons and really all of the negatives are when you haven't set up your company to provide those mentors and those teachers. That isn't the same thing as saying we have senior engineers on staff. I think it's kind of a two ply problem as it were, but we've turned a lot of people into senior engineers based on their expert use of a tool instead of their ability to elevate the people around them. I don't really have a strong opinion about the titling there, but there is a difference between someone who has that senior engineer experience and someone who is a senior engineer because they are a mentor and because they are a teacher. If you bring on newer coders who have this amazing drive and ambition and ability to grow so, so fast without resources for them to turn to, then you're doing them a disservice.

Laurie Barth: Even beyond that, I think you want to make sure that you have work for them to do that is at an appropriate level with the support that they need, with the resources that they need, and make sure that you're giving the person who's going to be that resource enough time away from their other tasking because it's not just a wash. That takes time, that takes energy, and you will see the rewards of that. I have no doubt. But you have to kind of set up your structure in such a way that allows for it.

Joel Hooks: Maybe my favorite ways that I've seen this structured is the apprenticeship model where where you come in and there's folks that are apprentices and then folks that are set up as the mentors. It's just like in your job description that people are going to come in and you're going to help them a lot of the time. I've seen people grow and thrive under that environment.

Laurie Barth: Yeah, I really like it. I think the problem that we see is, too often, and welcome to capitalism, the idea that you're hiring someone who would be a junior, which is not a term I love. And you say in your job description, hey, we just want someone who's excited, someone who's willing to learn, someone who has some foundation. You end up going with the person who has the most experience and will allow you to pay them the least. And so that's how this kind of rat race starts of, I need to know every framework under the sun and I need to have done all of these personal projects in order to even get my foot in the door because there's someone else who will. And I wish I had a solution to that because I think it kind of benefits those who have the free time and privilege and opportunity to spend all of that energy leveling up. And then we get a bunch of people who look the same and act the same and think the same.

Joel Hooks: You mentioned, I want to get the person with the most experience at the least price. I think a lot of folks are, are timid about this idea of developing less experienced folks because they're worried, we're just going to train them and then they're going to leave, they're gonna find another job. And so we wasted all this time and effort. There's an opposition there, right? If you're trying to save money and you're trying to hire the least expensive, a viable solution versus guiding somebody through and then elevating their pay along the way and developing a culture in your company that facilitates that and facilitates growth both in skills and compensation. That's the balance that has to be ... if you want to keep them, if that's the organization you're trying to run and people are going to leave. But how do we do that? How do we keep them in our company and in our organization over time?

Laurie Barth: It's so true. There is that fear and it's a valid fear in some cases. Yeah, some people are going to leave. It's not going to be the right fit for them after a couple of years. They're a different person than they were when they started. And I think good managers and good companies recognize that that experience and being okay with that and championing that comes back around and ends up being beneficial in the long run.

Laurie Barth: But the other thing I'd say is there's a lot of loyalty that comes from taking a chance on someone and if you treat them well throughout, as you said, and give them the raises and give them additional opportunities, there's not going to be much reason for them to want to run somewhere else. I've been saying this a lot lately, but there's two reasons that people leave jobs.

Laurie Barth: One of them is because they're leaving a job, they're being pushed out of an environment because they're not happy there. And then the other one is they're not really leaving a job. They're jumping to a new one. There's a pull and an attractiveness of another opportunity that is just different or better in some ways. If you've kept a good relationship with that person, maybe someday they'll come back. They're certainly going to recommend that as a great place for their friends to go.

Laurie Barth: This idea that when you leave a job, it's because the job has done something wrong as is so backwards and antiquated, especially in our industry where people move around a lot. Some of that's money-based. And I know that we're not great about giving raises a lot of the times in certain environments, but it's also because there's so many cool things to try. But your reputation as an employer matters. People talk a lot. Treating people well, especially as they start their career, that's a measurable brownie points.

Joel Hooks: They can potentially be a champion forever. And if they see something that's bright and talented and would fit well in your organization, they'd be like, Oh, you should go work here because they're awesome. Versus, ooh, which can happen. That's the real risk, over time. It's like, Oh, you don't want to work there. That's not a good place.

Laurie Barth: Right. The first impression being the hiring is something everyone forgets. And the last impression being that exit interview and how you reacted when they gave their notice is something people also always forget. Those are the two impactful moments that stay in people's minds over time.

Joel Hooks: Yeah, no doubt. Well, Laurie, it was really great chatting with you this afternoon. I appreciate you taking the time out and I enjoyed it very much.

Laurie Barth: Yeah, thanks so much. This was fun.

Joel Hooks: Cheers.