JAMEY:  Hello, everyone. Thanks for tuning in. You're listening to Episode 106 of Greater Than Code. I'm Jamey Hampton and I'm here with my friend and fellow panelist, John K Sawers.

JOHN:  Thank you, Jamey and I'm here to induce our guest, Laurie Barth. Laurie is a software engineer who started as a mathematician. Depending on the day, she can be found using any number of technologies to solve from different languages to frameworks to other support groups. She currently works as a developer and consultant with Ten Mile Square Technologies in the DC Metro area.

In 2017, a local first-year conference was soliciting speakers to talk about Legacy system replacement. As a female engineer, Laurie wanted to give more diverse speakers on the stage and decided to submit a talk based on the large and varied legacy systems that she had worked with over the years. From there, she was bit by the speaking bug. Now, Laurie travels around, speaking about a variety of technical challenges she has faced in her career. In her free time, she involves herself in local technology groups, including facilitating the Girls Who Code Club, then she sits back with a cupcake and plays board games with her close friends.

Sounds great. Welcome to the show, Laurie.

LAURIE:  Thanks. So happy to be here.

JOHN:  So, you know what our first question is going to be because it's always our first question and that is what is your superpower and how did you acquire it?

LAURIE:  I was talking to multiple people about it and something popped into my head which is the fact that one of the partners at my company is actually mentioned before what he thinks my superpower is, kind of unprovoked, which is that I have no problem being a time suck, which sounds really terrible but I think it's actually kind of a positive thing for a variety of reasons. But basically, it means I'm not afraid to take up senior engineers time to ask questions I'm not afraid to voice my opinion when I think it's relevant and people should listen to it.

I have no problem being a time suck and I think the reason I acquired that is my personality type is generally really results-oriented and I like being efficient and I found pretty early on that the fastest way for me to solve the problems I was being asked to solve was to go up to the desk of my coworker, ask them a question, get the answer, go back and that gave me the kind of building blocks I needed for the larger problem I was trying to solve and that was by far, the most efficient way to do it. It doesn't mean I don't Google, it doesn't mean sometimes people don't know the answer but being willing to ask those questions or have those opinions was oftentimes, more beneficial than it was a negative and what does happens to you a few times, you kind of continue on that path forever, so unafraid of being a time suck is probably my superpower.

JAMEY:  How much do you recommend other people to acquire the superpower? Just like start being a time suck and see how great it is? I agree, it sounds mean, like I said time suck like you said it but it sounds mean.

LAURIE:  Yeah, it sounds mean. Time suck, resource suck, willing to recognize that your needs are worth your coworkers taking time out of their day to support. I think that's really what it comes down to. The idea that you're progressing, you're solving problems, you're getting more involved, answering questions, all of that only comes from you getting more knowledge and having more experiences and the best way to do that is to work and benefit from the people around you. It's good for them and it's good for you and I think recognizing that it's mutually beneficial is really important.

I think in this industry a lot of the time, we have this kind of fear that because we're technologists and a lot of us are self-taught and we can find everything we need to find on the internet, that we should just do that. But we forget that it's a time suck. That in of itself is taking away resources from your company and your project, for you to go through the top 10 answers and hopefully find one that meets your needs or solves your problem, when if you go ask someone who you work with, who has all of the context of the problem that you're solving, it's probably a much more efficient use of not just your time but the team's time and the company's time is an extension of that. I think recognizing those pros and cons and kind of the give and take in all of that is important and beneficial.

JAMEY:  I love that.

JOHN:  Yeah.

JAMEY:  That's great. Do you think that's also like an impostor syndrome thing because when you were talking about using time looking through these answers on Google, I think the thing that popped into my mind was not necessarily like if I ask someone, I'll be taking their time but if I ask someone, then they'll know that I didn't know.

LAURIE:  I think that's definitely an aspect of it but I think the problem is bigger than that because I think that there are people who are okay with asking the question but feel like they should be able to solve the problem themselves. I think recognizing that it's not that you can't, it's that it's not the most efficient use of everybody's time to have you solve them in that manner. But I do think impostor syndrome in this case is absolutely prevalent. I actually said I wasn't going to say this but I think it's relevant. It always ends up being relevant.

My undergraduate degree is in mathematics. I was one of very few women in that program as you can guess and I think a lot of that came from the fact that I went to an all-female high school. I loved math going into high school and no one ever told me that math was for boys. I knew it was for boys but all the people in my class were women and so, it was never weird. When I got to college, I was set on that path that it didn't affects me and so, the idea that I didn't know something was just inherent, "I'm a student. I don't know things. Math is hard," instead of, "I don't want the boys to know that the girl doesn't know the answer," which on the flip side, when I went to some of my computer science courses -- that was my minor in college -- I definitely had that fear that everyone was going to think I was a girl who didn't know something because I didn't have the base knowledge in that area. It's real and it's prevalent but I think it extends far beyond that and it becomes a much wider problem even after you get over the impostor syndrome of it all.

JOHN:  Yes. It's definitely something I've noticed junior developer struggling with, that sort of feeling like, "I can do this. I can get through the thing myself. I don't want to bother so-and-so senior person. They're so busy. They're doing more important work than I am," and when I've been in coaching or mentoring relationships with them, I have to say literally, it is their job to make you better at this and the way they do that is by you asking them questions. Even if the company isn't structured around specifically saying that those senior people need to be mentoring you and helping you out, technically even beyond that, it's what the team needs. Like you were saying, the team needs for you to go ask them that question so that you get the answer in 20 minutes, instead of an hour and a half.

LAURIE:  Absolutely. I won't deny as someone who's been that kind of mid to senior level resource that it's really hard to context-switch when someone comes up and asks you a question and so, I would caution people who are going to take my advice because I do want people to take my advice, if your immediate reaction from someone you're asking is a little bit of a sigh and a turn and an 'okay,' it has nothing to do with you. It has to do with the fact that we are all constantly solving Rubik's Cube in our own head and moving yourself away from that and context-switching can be super hard in our industry. Give them about five seconds to recalibrate and then they'll be good to help and figure out what you need and answer your question, so don't get discouraged by that.

I would caution people who answer those questions to recognize how hard that first-gut punch reaction is to someone who's getting up the courage to ask that question and to really, really try and recognize. They're going to read into it as a lot more than what it is, which is just like the kind of context switch and get my brain around this change. Both sides can stand to learn something from it, especially because even if you are a mid/senior level person, there's someone more senior than you that you're asking questions of. There's a domain expert in another area that you're asking questions of and it affects all of us regardless of whether you do it five times a day or once a week.

JOHN:  Yeah, I think that's a great point. I know there were a couple of topics that you had thought about bringing up here and I think one of them was around the specific skills that we look for when we hire technical people and how those skills may not be the skills that are best to help them succeed at whatever they're doing.

LAURIE:  I kind of ended up in a rant about interviewing but that's not the intention.

JAMEY:  I would have to talk about this because I'm actually, a fairly newly hiring manager and so, this is something that's been on my mind a lot lately too.

LAURIE:  We've been interviewing a lot. I would love to talk about it. In fact, there was a thread on Twitter just the other night that kind of blew up, specifically about this topic and there were a lot of answers I saw that every row in that message and more and kind of everything I think we all know inherently but becomes really hard in practice. In general, I've been doing that a lot lately and I find that even in my head when I know exactly what I want us to do and how I want us to do it, it's a lot harder in practice. It's a lot more time consuming in practice. When you don't have designated hours to give up to recruiting beyond a certain point and you're trying to juggle your engineering and management and projects and clients, customers or whatever, it becomes that much harder to recognize that your general view on these issues are affected by the person-to-person interviews that you're currently conducting and kind of the meta-problem versus the micro-problem, the short term versus long term gains, are really hard.

JOHN:  One of the things that always bit me when we're doing hiring is that hiring and interviewing is always an add on to the rest of what you're doing. It's never, "Lets carve out half your sprint, just to deal with this stuff." It's, "Now, go interview all these people and read all these resumes and get everything else done."

LAURIE:  I think some of that is based on the fact that we hire when we need bodies. The people who are currently on the team are already overloaded and we're at a point where it's a runaway train, so to speak -- the more time you take to hire, the more time it takes to get a new body in -- but then you still have to ramp them up and so, you're losing all of this velocity which is not a term I really love but you're losing a lot of your engineering time, energy, resources.

What I think kind of gets to the root of that is obviously, we're trying to make money for a company and the company needs money to survive but if we could get more proactive about resources, if we could get better at understanding when we're going to need more engineering power, then we could get ahead of the problem and do something like carve out time in a sprint to designate two or three people who can really get deep into the interview process.

Because in the end, we're only hurting ourselves because we want to hire people efficiently but we also want the people that we hire to be efficient hires in the sense that this is the right fit for us and for them, they're going to be here for a long time, the investment we put into them is worth it and I think we have a lot of fear about that already. The thing that I saw in this Twitter thread that was happening a couple weeks ago or even this week was people kept pointing out -- and I wholeheartedly agree with this -- the technical hiring process is built to keep out false positives and in reality, it creates a huge number of false negatives, which makes it deeply inefficient for everyone.

JAMEY:  Can you go into that more? What do you mean by creating false negatives?

LAURIE:  We are far more likely to turn down applicants who would be a really good fit for our company in service of not wasting time and money on a hire who's going to burn out or be a failure within 30 to 60 days. We are more likely to take a bunch of people out of our process who if we got them in the door and sat them down at a computer and integrated them into our team, it would be hugely beneficial to us and not bring them on for the fear that they're going to fail, that they're not going to be the right fit. I think that happens in higher numbers than it does the original fear we're trying to get over, which is that we're going to have these kind of bad fits come into our company which again, is a resource suck but so is recruiting and so is going through 20 candidates when 10 of them are a good fit and deciding that only two of them are a good fit because we're so afraid that these other eight aren't quite high-enough, stratospheric good fits that we're willing to invest the resources in them. It's just probably a really convoluted way of saying it, so I should probably figure out a better way to say that.

JAMEY:  No, that makes sense.

JOHN:  Yeah, I think it's also a diversity issue because the people that show up as sort of super obviously good hires are the white males who got a CS degree and all the other people just get preemptively dropped out of the barrel because they don't look super perfect on paper.

LAURIE:  I think that happens even when you get them in the door. The way we ask questions, I think is super relevant. We were having a really extensive conversation in my company the other day, actually where we wanted to make sure that they knew the type of technologies that they would be working on. It was a position where there really was some requirement about the tech stack you were familiar with. But the problem that we had is that when you ask questions about that specific technology, you're really just asking, "When you worked with this technology, do you happen to work with this one keyword and can you give me the textbook definition of what it means?" and you're not asking, "Here's a question that's somewhat nebulous and open-ended but I'm giving you the opportunity to show me what you know about this technology that I need you to have worked with."

Figuring out how to ask those questions is really hard but it's important and it comes down to not asking questions about, "What is a directive in Angular?" but asking a question like, "If I wanted a deeply reusable component that's going to show up on multiple pages that has some really funky UI display set going on with it, what are certain patterns I could use? Or how would you solve that problem?"

But all of that comes down to yet another problem, which is the person who's giving that initial screen before you brought them in and use those resources is probably someone who doesn't have the technical ability to understand a more open-ended, vague question, "Are you willing to use the resources to do those initial phone screens? Or are you trying to automate that process away a little bit?" in which case, you end up with a right answer that they're checking against kind of the dictionary definitions, so to speak.

JOHN:  Yeah, I think that sort of syntax and keyword based evaluations are highly problematic. I remember back in the day, I went in for a job and they sat me down with a written test about Java syntax. Had I been more self-aware at the time, I would have just walked out but of course, I bombed the test because it was just minutiae and 'did you happen to remember what order these things go in?' I never went any further with that job because it was just such a silly way of evaluating my developing skill.

LAURIE:  Yeah. One of the things I think we've found time and time again and we've all discussed is you end up with people who look like you or who look like whoever does the hiring. I actually had this experience just a couple of weeks ago because I've made it through a hiring process of people who don't really look like me and then, once I got to the other side, when I'm hiring people, I see people who look like me and say, "I'm successful here, so of course they would be successful here."

I think it's important to distill down what makes you a successful employee if you're involved in the hiring process but also, what makes everyone around you a successful employee. I think for a long time, we had this sense that being able to write code from scratch is what makes you successful because for a long time, that's what you had to do -- the code didn't exist: library, services, all of these other external resources weren't the main part of development and these days, that's such a big component that we haven't made the ship.

Instead of can you sit at a blank screen or a whiteboard or any number of other things and write an algorithm, what we really need to know is how quickly can you understand this large chunk of code that already exists, figure out what it does and change this one thing that I need you to change. Or how quickly can you take the services and libraries that already exist and make them work in code that we already have. Our false positives that we talked about before, everyone's afraid of the person who can't put the algorithm on the whiteboard but that's not really indicative of the types of skills we see a need for right now.

JAMEY:  That's a great point but how do you test or can you understand our code and add something to it?

LAURIE:  I love to see in-person interviews that involve in existing piece of code, instead of a blank screen and it doesn't have to be complicated frankly. It could be a to-do app that is already a work in frontend or backend and say, "This is a ticket. This is a bug. Can you help us walk through how you might solve this?" and it has to be simple. It can't be a giant codebase. But I think it gives you a really clear indicative picture of the logic they use, the steps that they walk through, the type of thinking and problem solving that a candidate comes with, instead of the rote-memorization or computer science algorithm questions we often see.

JOHN:  One of the things I've been working on with my team is and this is based on ideas I picked up from Jennifer Tu and Pete Holiday who both had workshops and talks at RailsConf in the spring this year. I believe Pete's talk was called 'The Code-Free Code Interview.' One of the things that they talked about there was asking questions about values. What you do is rather than making the candidate guess at what answer you're looking for. You say, "Our value is X. Tell me about the time where you're able to demonstrate that value," and so that question allows them to demonstrate their understanding of it and how they would do that and that can include things like, "I would like you to submit a review of this pull request." Like here's some code to read through what comments would you leave, what questions would you have and that way you can test things like how compassionately do they communicate, how well do they express their technical reservations.

You're doing two things. First, you're actually having them look at code but secondly, you're also saying, "This is the value we'd like you to express while you're doing it," so that can be really handy so we've been working with my team on actually, what our values are and what things we would be hiring for and how do we ask the questions of people coming in so that we can get them to demonstrate those values.

LAURIE:  I think one of the meta-problems that happens is if you're hiring a mid to senior level person, you're assuming that they can talk a good game, so to speak and so, you're afraid of the fact that they can't sit down at an editor and actually write code and so, you test for that. But I think that's a symptom of the problem that we seem to all be trying to hire mid to senior level engineers which has many, many reasons for that problem but I think, kind of the simplest one is, if you can't hire juniors or aren't willing to hire juniors, you're either have a very specific business case that requires that or in the past, when you have done so, you have lost them or they have not progressed, which are both problems of the company itself.

If you're hiring juniors and you don't feel like they're progressing fast enough, you can do something about that and in fact, you should and that should tell you something about the way your engineering department is run or your company, if you're all engineers. But if you're losing them, that also tells you something. If we didn't feel the need to always be hiring mid to senior engineers, I feel like we could interview a lot more on, not just at potential but the way people think, instead of being so concerned that they won't be able to pick up the syntax of our particular tech stack immediately and run with it because we don't have the resources or time to waste to give them even a little bit of time to do that.

To be fair, we do the same thing with hiring senior engineers if they're not in the explicit tech stack we want. We won't hire them even though says all the time, coding is about learning and everything changes so fast and if you work in JavaScript, it won't be here in five to 10 years. The idea that we keep hiring specialists in certain areas kind of across the board, instead of taking generalists who have the ability to learn whatever syntax has was put in front of them. Also, it says something about the way we run our companies and our teams, instead of just about our hiring process. I think when you whittle down to what your hiring process needs are, you're going to find many more kind of systemic issues that you should be looking at.

JOHN:  Right. If you're hiring process demands senior people because there's no possible way that any of the other senior people could mentor juniors, then that's a problem with your company.

JAMEY:  I'm wondering how a lot of this advice might be different for different-sized of companies as well because a few things that you've mentioned, when you're giving this advice, you're picturing I guess, a slightly larger companies than I was maybe picturing when we first started talking. You mentioned at one time, to put two or three people on this for a sprint and I'm like, "That's my entire engineering team." I'm wondering, particularly for smaller teams, I think I see this fit more in smaller teams. It makes sense to me but I wonder if that's a shared anxiety or that is actually, a riskier thing for teams of that size in your opinion.

LAURIE:  I actually work for a small company and the company before this was a small company and when I say small, like under 30 people in both cases. I think the reason I said two to three people is my instinct. I'm not sure if it's a positive or a negative instinct because some of the giant conglomerates are the ones who are going to need to spearhead change in this area, for it to kind of affect everybody else because I think, as long as we have people studying for the stereotypical coding interviews, we're going to see this problem and it's going to affect people who want to be engineers and it's going to keep them out of the talent pool in general, especially companies that are able to hire a large amount of junior people straight out of school or straight out of boot camp. You want them to not get the door slammed in their face.

I think for smaller companies, it is a bigger fear because the resources it takes to ramp someone up aren't felt so much more personally by teams and by companies as a whole but I also think that small companies have the ability to release that people in a way that other companies don't. They have the ability to have a large number of their teams meet the people who are coming on. They get to know the candidate’s personality and the way that they talk and communicate and think and they can figure out pretty quickly, at least in my experience.

Whether or not this is someone they want to work with and someone they think can grow within their own company and they don't necessarily need to use the kind of typical engineering crutch in the same way that other places do but I do agree that they are likely to be more invested in the problem of getting the wrong fit candidate. I think that doesn't necessarily mean that they need to follow the tactics of the larger companies. I think in fact, they're likely to be more successful if they chart their own course in this particular way because their needs are different, their fears are different, their risks are different.

JAMEY:  Yeah, that's really thoughtful and I totally agree about having the majority of your team. I have a majority of my team meet pretty much all of my candidates, which is a give and take because it's really nice to be able to do and I feel really confident in our hires because of it but then, also I'm taking away everyone's 'velocity' when I am interviewing people. I am asking a lot of my team as a whole and they're doing interviews but then, not just I feel confident but we all feel confident about bringing someone you want, which is a really good feeling when you're bringing someone on and everyone feels really pumped about it. I've been at other places where people feel nervous about it on someone's first day.

JOHN:  Yeah and with a small team, a personality mismatch is going to be really devastating because you're going to be all working so closely together. I can see why you want everyone to be really happy about it.

LAURIE:  Absolutely and I think for me, one of the things that's lost in this kind of stereotypical interview process is it becomes about the technology first and the person second. You go through this whole process and you finally got these people who can kind of meet your technology needs and then, you decide if they're a fit for your company and your team. That seems so backwards to me because it seems like if you could figure out really early on in the process, "Do we think this person would fit well with us?" and not in the kind of diversity stereotypical way, like not, "Do they look like us? Do they act like us?" It's, "We think they're excited about the work that we do. Do we think that they could grow with the type of work we expect them to do?" and then from there say, "Based on our initial requirement and the amount of time we think we have to get them to the full-fledged members of this team, what are our needs?"

I think we don't do that often enough. We kind of go in the opposite direction and say, "If we were to add to our team, we kind of need this level of engineering prowess immediately," and the reality is even if you hire your absolute best candidate who meets everything, you're looking at a month, two months, sometimes six months for them to really ramp up and know what they're working on, which is one of those other things that I wish we could test for, the idea that there are people who learn through context clues and pattern matching incredibly quickly and we need them in software engineering. We need them badly. We don't often get them because they're not the same people who are good at rote memorization because they never have to memorize anything because they can always figure it out on the fly from that. I'm not saying I'm one of these people ever. Nope, I'm not that person. Nope.

JAMEY:  People that get very nervous in interviews and I'll be like, "You can use Google," and they'll be like, "Oh..." and I'll be like, "You can really use Google, though." It's not me just telling you it's okay. Really, it's okay. I use Google when I'm working.

LAURIE:  The thing I find fascinating is you tell candidates they can use Google and they're more likely to go to the docs to get a definition for a specific function call, for example to figure out the syntax for it, than they are to do what they would do normally, which is find someone's code to solve the exact problem and tweak it because they think it's cheating. I think a lot of hiring managers think it's cheating. In my mind, how is it cheating if that's the way you actually solve the problem if you're given it during the workday.

The way I solve problems is I get a chunk of code that's working, double check that it's working in my system and then, slightly shift it piece by piece by piece by piece until it does what I want it to do. Then if I have to clean it up or make other changes or change variable names and all that, I do that. But the worst part is getting something to work in the first place, so why not start with something that works.

We have these concepts, in technology in general, I actually heard someone say it in relation to a kind of devops thing. I was talking about Kubernetes with someone and I said, "I really like Helm," and they said, "Helm is like training wheels for people who don't know how to use Kubernetes." My jaw kind of dropped at the idea that simple is considered a bad thing because it doesn't prove how smart you are. It doesn't prove that you know how to do something that someone else can't do and we do hire in the same way. We want a bunch other people who are so much smarter than everyone else. I want the person who does it fast, who does it smart, who's efficient and who makes it simple for everyone else to look at and understand later. When did that become a negative thing in our industry and how do we change it?

JAMEY:  It's so true. The myth of the 10X engineer.

JOHN:  Yup.

JAMEY:  I'm a 10X engineer because it takes me 10 times longer than [inaudible]. That's not true.

LAURIE:  Hey, it can be true and your way to make it more efficient is, as we said in the beginning, to ask questions instead of googling them. I think we're told time and time again within our industry, outside of our industry, unless I'm in Washington DC, in which case I introduce myself as a software engineer and no one cares because I don't work in politics. But outside of this area, I introduce myself as a software engineer and people kind of are impressed. They're like, "Oh, wow. You must be so smart."

I think that it feels nice to hear. It feels nice for all of us to be this kind of genius gods to other people not in our industry but I think, it's detrimental because it reinforces things that people in this industry tell themselves about the fact that not everyone can be them. In fact, we see it a lot with people coming out of boot camps or self-taught or career-switchers, of course they can't do this because they don't have the computer science fundamentals, which are critical at every turn.

I have a master's degree in computer science. First of all, one of my bosses didn't even know I had it until two years after I started working for him, which shows how much we read resumes in this industry but it also means that I have that background, I have a background in mathematics, I don't work in big data, I don't work in data science. Sometimes, when we're talking about the graph nature of NoSQL databases, my background comes in handy. I've been on some hardware projects where my math background has come in handy but I do a lot of web development.

I would say that the communication abilities I have from being a political science major end up being more relevant in a lot of cases, than the idea that I know what's happening deep down at some machine-learning level or register keys or whatever it is. I don't think we're doing ourselves any favors by continuing to perpetuate the myth that if you don't understand what's happening six layers below, you can't do something efficiently at the top level.

JOHN:  Yeah. That's something I always do when people give me that exact response. "Oh, you must be so smart. You're writing software," or, "You must be so good at math," or whatever and I say, "I don't even have to count to 10. The computer does that for me." At my level of web development, I do know mathematics. There are other areas of tech where like you said, it does come in handy but for me, never needed it and so, I try and communicate that when people give me that. "No, no, seriously. Like anyone, you can just sit down and do it. It's not that hard," because I want to bring more people in the industry but there is that pervasive perception that it's about smartness and there's still plenty of people in the industry who care really only about how smart they look when they're doing their thing.

JAMEY:  I don't think anyone can code but I don't think it's about smartness. I think it's about patience. I know people who don't have the patience for it and they hate it because they don't have the patience for it. I think that recognizing that you're a person that is like, "I'm miserable doing this because I don't have the patience to debug it," and I had friends in school who dropped out of computer science because of that. At first, they were like, "You could do it. You're smart," and then I was like, "Oh, yeah. You could do it but why would you if you hate it."

JOHN:  Yeah, actually you have a point.

LAURIE:  That's so funny to me. I think my father would say multiple times over that I'm one of the least patient people he's ever met and yet, I enjoy it because once I get into the debugging nature of it, I really love puzzles and so to me, it feels like I'm constantly making forward progress and I'm constantly getting closer and closer into the solution but I think for other people who don't see those kind of intermediate benchmarks, absolutely. You're right. Not everyone can code but I think where we go wrong is deciding what we think makes the building blocks of a strong coder.

JAMEY:  I have a friend in college who dropped out of computer science program in freshman year because imagine at the first computer science class you ever take and you spent like eight hours debugging. It was in Java and it was like a semicolon. He was so mad that he spent all this time looking for a semicolon and I was like, "I'm sorry that you're mad but I think that that's just something that happens sometimes," and he literally dropped out of the program over this one incident and then he went into real languages and now, he speaks like eight languages.

It was so interesting to me because it never dawned on me that the part of his brain that wanted to learn code, really just wanted to learn regular languages and not have to do the debugging part and it was super cool to watch him fail at one thing and then wildly succeed at something kind of similar.

LAURIE:  It's so interesting that we tend to think of computer science as kind of the same part of your brain that does hard sciences and that may be true but I think, it's similar to the part of your brain that does languages, music and math, which has a lot of creativity involved in it, especially for frontend engineers which I think we have such a dearth of right now. We need people who have been in the shoes of the customers and the people who use the systems. We need people with arts and kind of visual capabilities. We need people who can communicate really, really well because UX is hard and people with empathy because of accessibility and kind of all of these skill sets and yet, we're still looking for what used to be purely backend engineers or looking at their requirements and skill sets to hire frontend engineers.

I'm not trying to kind of make a divide between frontend and backend. I consider myself to do both but we're taking requirements and applying them in places that they don't belong. I think that's true kind of throughout the industry because at this point, there are so many different verticals of technology. It's truly insane.

JOHN:  I think jumping into non-computer science skills that are good on software teams these days is a great topic and you mentioned being interested in talking about but first, we need to have a message from our sponsor.

JAMEY:  Greater Than Code is sponsored by Crickstart, which is a company that makes organic snacks with cricket powder and they don't even taste like crickets. I promise. They have protein bars and they're really great. The cricket powder is made from organically-farmed free range crickets. They have other plant based stuff in there too. [inaudible], chocolate, dates, everything is organic. It tastes really great. It doesn't have that chalky taste that you often get in protein bars.

I've actually have had straight crickets before, so when I said that it doesn't taste like crickets, I'm not even lying. I know about this. They also make crackers. They're pretty great. You can have them with snacks. They sent us all this cricket stuff in the email and I was very excited to get this box from our sponsor and eat all this cricket food.

JOHN:  They have shakes and crackers. The crackers are super tasty. I really like the olive flavor.

JAMEY:  And they're very nutritional. Crickets are really high in protein like bugs is the wave of the future and all that. They're very nutritional and there can be a burst of energy. The protein bar is one of my favorites, so that's what I'm thinking about and it says there's over 40 crickets in every Crickstart bar and over 100 in every bag of crackers. If you want to eat a 100 crickets, I would recommend this rather than just eating 100 tickets.

Also, if you would like to try them, you can visit Crickstart.com and if you use the promotional code: GreaterThanCode -- all one word. You'll get 20% off your order.

JOHN:  Thank you, Jamey. I think one of the interesting things about our industry is that we can bring people in from lots of different other industries and skill sets and use that way of thinking to influence how we work. Some people have had some really interesting talks on that. I know Betsy Haibel had a talk about how set design can inform software architecture. That was on a Tech Done Right episode. I'll post a link to that. There was what we can learn about diversity from liberal arts, which was a talk by Liz Certa a couple years ago --

LAURIE:  Go, liberal arts!

JOHN:  Yeah. I think a lot of the issues that we've been discussing here today, the strengths that you get from liberal arts education or from working in other fields are strengths that make you better developers because as you said, communication and empathy and the thinking through impacts of your changes and things like that that you really get good at, maybe doing work in other fields and then, when you come to technology, you can realize how that can be really effective in this context. Are there examples or other thoughts you have on what sorts of skills we can bring in?

LAURIE:  Yeah, definitely. One of the ones that I never really thought about until I came across someone who had this skill set was theater. Someone will make [inaudible]. She's a dev relations person and it kind of ties into the whole time suck thing that I said earlier. I did musical theater when I was a kid for many, many years but the idea of unabashedly being okay with taking up space sometimes and not being afraid of feeling like you're grabbing attention that you don't necessarily deserve and all of that like, "Your kids are great at that." They often have a kind of deep level of empathy but also, observational intelligence of people's emotional range and communication that I think can be really helpful.

I joke a lot of the times that theater people have kind of fake so many emotions that they can always tell when the person they're talking to is feeling one of them and kind of adjust accordingly. I don't know if that's true for everyone but I think that's a skill we could all benefit from but the tech industry, in general doesn't have a whole lot of those people. That would be one. I'm not sure if others come to mind [inaudible].

JAMEY:  We mentioned empathy earlier and I think about that a lot like it's just so important in every sense of everything you do like talking to your coworkers and collaborating on projects. If you have to talk to clients, absolutely but even if you don't, having the ability to put yourself in the shoes of your user and be like, "Is the thing that we're making useful to this person?" Because it's very easy to get sucked into. I think in some companies, it's fine because that's true like it is your product for other tech people like you.

If you work at like Slack, then maybe your users [inaudible] to you and you have an understanding of what their needs are because you use Slack and you have opinions on it. I work in agriculture and my users are farmers and it took me a really long time to be like, "I don't know what it's like to be a farmer but I have to figure out, to some extent what it's like to be a farmer." I think that there's a real skill not just of being able to do that and put your mind to like, "I'm going to try and think like this user, this demographic," or whatever but there's some people, I think it wouldn't necessarily even occur to them to do that and that's where empathy is such a quintessential thing that I've heard you talk about moral lately but I think that... I don't know, just like maybe the most important thing at all and I think that's undervalued.

LAURIE:  That actually came up in a talk that I did -- actually, in one of my first talks ever -- which was we often kind of decide for ourselves whether our project was successful or not and our success criteria are so often based on how sleek is the code, how efficient is it, that it do its job. Especially with the number of Legacy systems that are getting replaced these days, our success criteria should always be, "Did it make life easier or at least, status quo for users?" Because they had to get their system replaced, it was on life support basically. But the idea that you're making all of these changes within that and say, "This will be better for them. If they don't understand it and they can't use it, it's not," and empathy goes straight to that and being able to kind of put yourself in your customer shoes.

But to kind of go back to the other skill sets that are important, I was thinking about with the musical theater example which is kind of funny. We talk so often about how coders need to be good at learning constantly and I think that's true. We need teachers and we need a lot of them because as the amount of knowledge that you need to learn, it's like a science problem. There's always more science getting discovered, so what it takes to learn up to modern day science is always growing. That's true in computer science as well. Though in some ways, I think some of my older coworkers always joke with me that I need to know so much less than they need to know because I get to work in like little boxes of services and things that didn't used to exist.

But the idea that we need teachers who can help mentor and grow the industry away from completely self-learners and completely people who are drawn to this themselves, because once you're bitten by the bug and once you understand a certain level of what you need to work on, you can grow yourself but there's different ways to get started. I think recognizing that we need learners but we also need teachers is kind of important.

JAMEY:  I have a question about learning. Do you think learning all the time is a skill or a mindset or both?

LAURIE:  I think learning all the time is the ability to not feel done even when you feel done. It's actually funny. My company that we mentioned before -- Ten Mile Square -- we work on so many different projects that I joke all the time, that I constantly feel done. I come from a software engineering background before coming to my position right now and in the past year, I've had to do hardware. I've done devops. I've done software in completely different technologies. I've done communication and assessments. I've done this wide breadth of stuff that totally out of my comfort zone.

I got really frustrated at one point this year and I kind of said, "I'm sick of always feeling like I don't know anything. I'm sick of never getting to rely on this backbone of knowledge that I have," because frankly, when you know software engineering, switching between languages and framework is hard but you're at least working off the same skeleton, so to speak but switching to devops or hardware is completely different worlds. The ability to see things as temporary states is really important.

Constantly learning means knowing that every bit of frustration is just on the path to get you to the next, "Yahoo moment. I did it. I'm a genius," and that everything is at a temporary state. We're somewhat negative in that way as people, especially people who work in tech. It's, "This won't work. This won't work. This won't work," and this flitting second of like, "Yay, this works," but recognizing that all of those moments were temporary states and they will eventually come to an end and then, you'll be in the new one and recognizing your positive temporary states and kind of keeping those in the back of your mind as, "That's what's coming up for me," like it will always be there at the end of the road. It'll just may take a while.

JOHN:  I gave a talk on this earlier in the year called 'Everything Is Broken, and It's OK,' where I talked about this this very thing where it's like as soon as you get that 'yes, it works,' you immediately jump on to the next thing that doesn't work. You don't have a lot of time in that 'Oh, my God. Everything is working' moment to feel that joy before you jump on to the other thing that doesn't work and the next thing and the next thing and the next thing.

One of the things I talked about was paying more attention to those moments when you get them and writing them down and reviewing them at the end of the day and doing things that can increase their profile and your consciousness so that when you think about you're overall week, you can look back and you can say, "I had five of these really great moments and I can ignore the rest of it because that's just the crap you go through to get to those moments," rather than when you look back on your week and you say, "Ninety percent of my time was just spent staring at that debugger and wondering what the hell was going on." It's very demoralizing and very easy to get yourself burnout from that.

JAMEY:  I feel like I get particularly demoralized with bigger projects because there's so much and when you first start of it -- at least I wouldn't say 'you.' When I first started a bigger projects, at least I very often feel like overwhelmed like, "How is this going to work. We have to figure out architecture like. How can we possibly do this? It seems impossible. I don't know how to do it. I don't know how it should be," etcetera, etcetera, etcetera. I feel like the third of every project I work on is like living in this perpetually anxiety state about that.

When I try to remember it, it's like, "Remember the last time how do a project?" and you felt like you're in this perpetual anxiety state that it was impossible and then like, "Have I ever had a project where I'm like, 'I actually couldn't figure it out, so I quit and move to the woods that I said, I was going to do.'" No, that's never actually happened to me. It probably won't happen to me this time, realistically even though I feel that way about it right now. I actually really have to remind myself of that a lot because I'm very overwhelmed when I'm in that anxiety state.

LAURIE:  I think that kind of speaks to the problem that we're bad at remembering all that we've learned and all that we've done before. We remember the bad stuff to a certain extent. I've talked to a lot of people about the concept of a developer journal that I keep and I think it's really helpful where I keep notes about kind of, "This site help me solve this problem," or, "This pseudo code or this was the resource that I needed." It's very efficient because the next time I come across it, which always happens, I don't have to say, "I saw that one time before. Where was that?"

I think we could do the same for kind of emotional well-being, so to speak the idea that you can write down, "This was a really big victory for me and I remember learning this and doing this," and the next time you come across that piece of technology, you already learned it and you should recognize that even though you have to learn X, Y, Z and other things or do X, Y, Z or other things for this new project, you feel positive about all of the kind of blood, sweat and tears you've already put in, so to speak and don't discount that as being irrelevant or easy because it's easy now but it wasn't then.

JOHN:  Yeah. If I'm remembering how difficult things were at the beginning can be really, really helpful because then, you can look back and say, "It used to be really hard for me to figure out how all these Rails models are going to be related to one another but now, I just sort of do it my sleep." Then you can be like, "Oh, yeah. I got good at that over the last 10 years. How about that?"

LAURIE:  My constant example is when I was in college, I had a really hard time doing the algorithm for Huffman coding and I'm still afraid to go back to it. I'm sure I could do it now but just in my head, I'm like, "Evil algorithm that I don't want to touch, that was really confusing when I was first using Python and I didn't understand the concept of libraries in Python," and all that.

JAMEY:  I think the baggage about stuff that we've worked on the past is super real. At my previous company, I did a project with Bluetooth printing that was a disaster. I learned a lot from it but in my new company, they're like, "We're going to do this printing project. Didn't you work on something like this at your old company? You could do it because you've already done something like this and you kind of know about it," which is a very reasonable way for them to feel but I was like, "I absolutely cannot be the person does this because I'm feeling very negative about it. I'm already feeling very negative about this project that you just mentioned to me because you mentioned to me in this context of this baggage I already have."

It's hard because on the one hand. Part of me wants to be like, "That's silly and you don't have to feel that way about it because you did learn stuff and you do have background in this." But then another part of me is like, "That kind of baggage is really real. If this is going to cause me to feel negative about myself and my job and my life in the same way that it did before and someone else can do it, maybe someone else should just do it." Because when I tell about the efficiency is like, what's more efficient, having someone who has a little bit more experience in this or having someone who's fresh and not angry about it?

JOHN:  Yeah, that's going to be a big impact.

LAURIE:  Just thinking about the baggage that I have has made me realize how true that statement is. There's about 10 different things someone could come and ask me to work on right now and I'd be a deer in the headlights. I'm like, "Please, no. I've been there. Don't make me cry. please."

JAMEY:  I was kind of trying to push through it at first and then I'm like, "I should have to push through this," like there's other people on my team for a reason.

JOHN:  At the end of every show, we go into what we call reflections, which is just the takeaways or interesting ideas that each of us have encountered as we've gone through this conversation.

LAURIE:  I would say, I love talking to people who have seen a lot of other people speak. John mentioned a number of different talks and kind of link to them in this chat that we have, that I want to go back and watch, that kind of relate to things that I have experienced or that I'm really interested in and I love the idea that within a community, even if it feels like at a meta-level, we have all of these views that I don't necessarily agree with. When you kind of get down and talk to people, there's all of these different people working on similar problems and kind of trying to make our industry, not just accessible but livable and enjoyable and exciting. I like the direction that kind of all these conversations are going and I like talking to people who feel that way. I'm not sure how much of a takeaway that was. Really, I just want to watch all the talks you link to.

JAMEY:  That's a call to action.

JOHN:  Yeah.

LAURIE:  There you go.

JAMEY:  I want to watch all the talks of all time.

JAMEY:  I think our conversation about hiring at the beginning of the show was really interesting and insightful and helpful for me. As I mentioned, I'm a hiring manager now and I've been making a lot of decisions about how we interview and what kind of questions we asked and what kind of stuff we put value on. I have been thoughtful about it. I feel pretty good about my process but I definitely always want to be improving it. I think that what you said about false positives and false negatives was really helpful for me to reflect on, even if it's not a change in the interview process, like a change in how we think about evaluating people that we've already talked to. When you are on the fence about somebody, how you approach that fence as a team, I guess is something that I kind of want to rethink.

I also love the idea of having a code sample to have them fix or add or do something like work with in some way. I think it's a great idea that I never thought about and I want to consider and that's something that I might implement in my process. I think being one of the people that gets to have some say in how you do the interview process in your company is kind of powerful. It's definitely powerful because I'm affecting the people that I interview and stuff about their career and livelihood, which is a lot of responsibility that I do think about.

I also think that if you want hiring practices to be different, then doing them different and every single person that touches my hiring process is going to see what it's like and have an opinion about it and maybe, even if we don't end up hiring them or they end up not wanting to work with us, they'll take that feeling about the process I set up with them and take it to other companies and judge other processes by my standard in a way. If they liked it, maybe they'll take it to their company and say, "Maybe, we should do this in our own hiring." It could kick off some sort of chain reaction and anyone who has any say into that, can participate in that chain reaction in a way that's cool. It's important to me.

JOHN:  For my reflection, I want to go back to what you mentioned, Laurie at the beginning of the episode, where your superpower is being a time suck. It relates I think to something that came up later in the discussion too, where you mentioned the ability to take up space and demand the attention that you need. I think that's a really powerful thing that I think a lot of people can learn but I think, particularly junior developers can learn.

For me, who someone who mentors a lot of junior developers, finding ways to communicate to them that they deserve to be here, that they deserve to take up space, that they can they can own their need to have an answer from me or from whoever they're working with, is a really powerful thing that I would love it if more of them can do and I want to figure out how to make that happen.

LAURIE:  Everyone's going to have my superpower now. I love it.

JAMEY:  I'm glad that you want to share it and you're not possessive of it.

LAURIE:  Nah, that's cool. I think we can all be time suck, so there will be no time left and we'll just nap all the time.

JAMEY:  Sweet. Good plan. Laurie, this was a really great conversation. We really appreciate you coming on the show. We had a great time and a great episode with you, so thank you so much. Thank you everyone for listening and if you'd like to continue having conversations like this, you can support us on Patreon. I believe it's Patreon.com/GreaterThanCode. Even if you only pledge a dollar a month, you can join our Slack community. It's really great there and we're always kind of having chats like this all the time.