Why most new developers struggle: The missing skills you need

Ryan Burgess
Welcome to a brand new episode of the front end happy hour. We recently did an episode about what graduates from boot camps are missing when they enter in the industry, which sparked a good idea of having a discussion around the types of gaps that we see when people are first learning or they're earlier in their career, they're just trying to figure out their journey in programming. So to help with this discussion, we've asked Brian Holt and Dan DiGangi to share some insights into what they've seen while teaching classes and workshops. This will not only be helpful information for someone starting out, but also for senior folks that are looking to mentor or to teach others. Brian and Dan, I know you've been on episodes in the past, but let's give brief introductions of who you are, what you do, and what your favorite Happy Hour beverages.

Brian Holt
I've been on this podcast a fair few times at this point, for some reason, they keep coming back. I'm not sure if it's Stockholm Syndrome or I don't know if you can have Stockholm Syndrome towards the podcast, but if you can, I do. My name is Brian Holt. I change job titles like a girl changes clothes, and presently, the job title I have is staff Products Manager at NEON, typically a beer. If I'm ordering a cocktail, it's probably Manhattan or an old fashioned. Name is Dan deganji,

Dan DiGangi
Dan DiGangi, Ryan. So I work at a active campaign right now in a company called postmark they acquired a couple years ago as an engineering manager on, like, six years in, I think it is now. So it's getting there. And let's see I did like, what? 20 year tour of duty, and I'll throw this one. I have the JavaScript logo tattooed on my leg and my Pikachu avatar on my back, which I always love to tell people, and don't judge me too hard on the drink. So I do like white claw, and mango is my favorite, but they came out with peach, and it's so good,

Brian Holt
I am judging you. Just that's what this face is.

Ryan Burgess
I don't feel like I can judge him enough, because I think I've only tried white claw like one time and never have tried it again. So that might tell you I wasn't a fan. But hey, you know, I'm not judging you, Dan, because I just can't give enough of my opinion on it. All right? And it's Jem and myself for regular panelists. Jem, you want to give your intro? Jem, young,

Jem Young
engineering manager at Netflix, and yeah, we can judge you, Dan, there's a there's a lot of drinks in the world, and you chose the worst one. So yeah, they were judging.

Ryan Burgess
There might be worse than that out there, though. Jem, I you know, I feel like there's some really poor choices out there. Okay, fine, all right, that's fair.

Dan DiGangi
I'll get Ken Wheeler in here. He'll back me up.

Ryan Burgess
Ken's not here to help you, man, I'm sorry, and I'm the host of frontend happy hour. Ryan Burgess, this episode is sponsored by Wix studio devs. This one's for you. I've got 30 seconds to tell you about Wix studio, the web platform for agencies and enterprises. So here are a few things you can do in 30 seconds or less on studio, integrate, extend and write custom scripts in a VS code based IDE leverage zero setup, Dev, test and production environments ship faster with an AI code assistant and work with Wix headless APIs on any tech stack. Time's up, but the list keeps on going. Step into Wix studio and see for yourself. Let's dive in. I would love to just start off by asking, like, what are some of the common gaps in knowledge or skills that you have seen in junior developers, Brian and Dan, you've both been doing a lot of teaching recently. Jem and myself have done I've done one workshop and that that is it, but we've done teaching as well here and there. So I think it'd be interesting to just really know what are some of the common gaps that people see when they're first learning,

Brian Holt
something that I encounter frequently when teaching and with some of like the more junior candidates that I've interviewed over the years, I like to call it LinkedIn. Itis, and I can say that as a former LinkedIn developer, where they'll go and they'll try and figure out what's the most popular thing at the moment. And like, I can't blame anyone for, like, they're trying to get jobs, and they assume, if I have the hottest skill, I can get a job. The issue with with just going out and, like, looking at Hacker News and seeing, like, what's on the front page today, and I'm gonna go learn all that stuff a lot of time, it just doesn't stand up for that long. Like, if you had done it, like, six months ago, you probably would have picked up, like, llama one and some other like flashes in the pans. And the tech, like, will move fast enough that, like, it's quickly outdated. And then it also just encourages people to go. And not get very deep on any topic, and be very shallow across many, many, many topics. And so they'll they'll say, like, I'm a Ruby developer, and then they'll hop into an interview, and they'll get, you know, a senior Ruby engineer in there that will just grill them. And they'll see that this person has no depth in the top, like they've just read the docs a couple of times and set up rails, and that was about it. That is certainly the most dangerous one in terms of, like, losing out on job interviews that I've seen, and that's kind of evergreen, that's, that's been my entire career, that that's, that's happened, I would definitely

Dan DiGangi
agree with the depth, I think, like, the great, uh, real world example is, you go to someone's like, GitHub, and it's just like a tutorial that, like, like, here's a component in React and rendering, and it's just like that that's not really taking it anywhere. So I definitely agree you see that a lot. I would say I agree with you, Brian. The only thing is, I do think there is the side of like, you should focus and specialize in at a level and like, get into it. But I do think it is worth early on trying to expose yourself at some level, like, maybe not like end to end, like an architect or anything, but at least having some of those conversations, looking into some of that tech, I think it's can be hard to start to connect some of the dots if you haven't been exposed outside of the one thing that you work on. And it makes me kind of think of another, which is, you always say, like, go build things, especially if you're new to the industry, is, I see a mix of, like, not everyone, because they get a job, will go, continue to build things. And maybe it's like, well, I have a job, work life balance, but you should still continue to build on the side to like, you know, and also read reading books. Like, I really find a lot, and I don't buy, like, the React book, maybe the TypeScript one, even though I'm terrible at it. But like, around, like, software architecture, software design, like those things. Like, that's the stuff I don't see happening as often, especially once somebody locks down that first job.

Ryan Burgess
That makes a lot of sense, because you do have to keep learning. Like, I mean, we all are doing that. Then we're very senior engineers on this podcast, and we've constantly been learning new concepts all the time. So that is a good point. There is the work life balance, though too. Is like, some people are like, I'm not doing this my entire life. And so there is that, like, weird balance. Maybe they just need to listen to a podcast about people talking about it, and maybe that will help inform them. I'm not

Brian Holt
sure. Worst idea worth that, worst piece of advice that we've ever given on this podcast. That's not true. I've given plenty of worse advice in this podcast. I don't think my point in yours Dan are necessarily at odds with each other. One of the things I like to say is that one of your most limited resources is it depends on how you want to polite of company, and I typically call it fucks, how many fucks you can give at a time. But if you if you're in more professional contact, I'd call it Stoke, like, how stoked you are about something. It's a very precious thing that, like, if you open your computer and you're like, really excited to go work on something, if you tend to engage with it more deeply, you'll write more with it. You'll spend more time with it. Because, like, when you're hacking on your personal time. You're competing with Netflix, video games, family time, sleep, like all the above, right? And so generally, the advice I give to people is like, go where your stoke is the highest, right? Like, where you get really excited, because you'll tend to come back to that. You'll tend to get deeper into those topics. And so sometimes that'll be, like, I really want to figure out how to, like, stand up an LLM or, like, if that's getting you going, then by all means, like, chase it. You're going to learn a bunch of interest, interesting stuff anyway. And if you're just sitting there and grinding yourself through, you know, react, because that's what you feel like is going to get you a job, and that's the only thing. And you're not very excited about it. You're just torturing yourself, right? And you're probably not getting, you know, you're probably gonna stick with it very long. You probably like, Netflix is eventually gonna win out, right?

Jem Young
Yeah, kind of what you're saying is, what I see missing sometimes is curiosity, and that's kind of what you're getting at Brian, like, you want people to be curious, like, oh, how does this work? Why does this work? Versus, I did this tutorial, I watched this YouTube, I took this front end Master's course. I'm qualified or but like, we know on the other side of things, like with our user experience, like we know you don't know that much actually, and not being diminutive, just like you just don't have the experience. And that's something you have to have the software engineer. But what you can bring as a new developer is just being curious. You're like, hey, yeah, I don't know how WebSockets work. And I looked into them because I thought they were really cool. They were interesting, not related to my job at all, versus the checklist new, new developers, just like I did this tutorial, I did this like you're saying I did Ruby, and now I'm a Ruby person, because I know to do that, like, well, you know how to use tools. Cool, that's not what we're looking for. We're looking for someone that knows how to build the tools. And that's probably a big difference, is, I hate to say it, people kind of differentiate themselves pretty early on in terms of their success in software engineering. The people that are curious will do well and move on to, you know. Level, senior, Principal, etc. And the people that don't will probably eventually get the senior just through time, but they'll always be wondering, like, why am I not getting to this next level? It's because, well, you're doing for a paycheck versus you're doing because you enjoy it and you're curious. I don't know how to make that curiosity in built, but that's something I do see in new developers, is like, I did so and so and so I'm qualified. When it's like, well, you'll never be qualified to your junior engineer, but there are other signals we can get. And I think curiosity is one of those that you know I'd want to see if I'm talking to a junior developer. Just for

Ryan Burgess
the record, I don't think I've ever done a tutorial on something new and felt like, Yeah, I know this. Like, never, like, even if it's like, I got it working, but it's like, how do I apply that to gem asking me to go create something now, with that same technology, it's not, it just doesn't pan out as well. You learn some concepts. Don't get me wrong. Go do tutorials. You'll learn from them. But yeah, I don't think it's like, oh yeah, I've got that skill set in the bag. Now that's just not how it works. You

Dan DiGangi
also get, like, that laser vision, because you learn the one way the tutorial teaches, right? And that's what you go and like, I know JavaScript, but like, people read the use effect docs, and they apply that to every possible thing they could with state management. And that's that's it. And like, they still, you know, you make mistakes, you learn, but you have to be really careful about getting to myopic, laser focused, and you got to pull back and be like, Why did I learn that concept? How does what I had built help me here? Where does it apply to the next problem I need to solve? There's so many ways to do things in development, and it's great to start with one, but you got to bridge and break out outside of that and learn the bigger picture of what you need to build.

Brian Holt
So another

Ryan Burgess
part of learning how to program any language that you're doing is understanding a lot of the concepts there. They can be challenging. I'm sure you all see this when you're teaching too. Is that, you know, there are some challenging concepts, and I'd be curious like, what are the most challenging practices for developers to grasp when they're transitioning from learning to working in a professional environment. Maybe it is even just like in that early stages of learning, like, what are some of the hardest concepts they're trying to learn? One of the most

Brian Holt
elusive ones is write code to maintain it and not don't write code because it's like, don't optimize for writing code, optimize for maintaining code. That's what I'm trying to say. I think that's one heart, because that's largely experiential based, like, what it means to maintain code, and two, when you're at least, when I was junior. So maybe I won't project too hard, but I'm definitely projecting on all of you that as a junior developer, you want kind of one like, show off, right? Like you want to say, like, look what, look what. I can do. Like, I can write this, like, crazy, map, filter, reduce, with all the latest functions and like, end up with this, like, beautifully elegant, terse code that is just nonsensical to try and read, right? We've all done it. I'm looking at all of you. Dan, I haven't seen your code, but I've seen Ryan and gems So, and I'm including myself in this. Involve my pictures up here, and I can see myself, and I'm judging myself. Lens, yeah, so like learning to write things. Write more. Comment correctly, not comment when you don't need it. When to, you know, pull on a module to have it do something for you. When to write it yourself. Like some of these things end up being really tough.

Ryan Burgess
I think that gets back to maybe even gems. Point on the Curiosity aspect Brian is that we're spelling out that you don't have the experience when you first start out, and so you don't know all those edge cases that you should be looking for. And so I think that's a really good point to go back to. Jem saying the curiosity aspect is get comfortable like asking questions, and even in that instance of like, should I create a component to do you know, a date picker, or should I use something that already exists? And I think you can try and outline the pros and cons of both, that both are right. I mean, there's not a right answer, it's they're both right depending on the scenario. And so I think, like, also leaning to a peer to say, like, here's what I'm thinking. But how does this get maintained? Is this worth the squeeze of me building a brand new thing that, you know, there's something that's already exists, like, I think those types of conversations are really important, and to practice those as much as possible, because you were starting to gain that experience, just leaning on someone else who hopefully has the experience and has gone down that road before.

Dan DiGangi
Made me think I was thinking about practices, right? If you're like in school, boot camp, whatever it is, you get an assignment, it goes, you just start going and coding. And I don't I noticed with so I taught at a couple boot camps recently, after I went through my layoff and at work, as well as there, I see a common thing of, like, just trying to get into like, a preparation mode. Of like, here's the thing I need to go do, here's my plan around it, what I think it's going to take, even, like, trying to have some idea of, like, an estimate go into a senior development. Versus anyone in general, but typically, senior is getting that review so that you don't go do all those changes just for someone to throw it right back in your face, right? Like, you know, we always talk about like, you need to have good like, this is more of a genre, like reactive patterns, but I like to think like mitigating so we don't have to be reactive. And it's kind of the same thing in the code process, right? Is gonna develop it. I'm gonna plan as best I can so I have a lot less iterations potentially, and I'm getting ahead of what could come out of it. And I found that that can be really difficult, plus the practice of getting feedback in general can be a really difficult practice. Some people take things very personally, which is understandable, but getting used to taking feedback is it's a hard practice in the beginning to do, especially if you're alone. Of those like John was saying, curious, very confident, might find that you take things a little hard because you're really proud and confident in where your skills are. You know,

Jem Young
right? What I find challenging or and speaking for myself, what I found challenging early career, and I still see it, is understanding why we do things, and understanding computer science is a science, and a lot of the patterns that we use and have invented have been developed over the past, like, 30 years. That's why they're called Design Patterns. When I first encountered them, I thought they're limiting. It's like, why are you why are you going to tell me how to do that? I can build this, use this function. It's fine, because I didn't understand things like scalability or like Brian was saying, we write, we should write code to be read, not to be just for the sake of writing it, and that's what patterns and things like that help you with. But as a junior developer, you're like, this is this like writing a singleton using a singleton pattern? It's like, way more complicated than it needs to be. I could just write this function. It does this thing because I didn't understand that other people had to use the code that I was writing. And I think that's something important to to develop. You just have to take a lot for on faith as a junior developer, on why we do things, why there are processes in place, why we write tests. Because you just don't have the experience to know when things go wrong, or experience reading other people's code, to know why we do these things. But that's something I've seen push back against. It's like, Oh, why do we need to learn these things? I can code just fine. My code doesn't have any bugs. And it's like, you know, we all chuckle at that, because it's like, it does and it will, and you're going to break something big one day, and this is why we follow these patterns. But that's just not something you you can inherently know. You just have to take in on faith and trust the people, the senior engineers, hopefully mentoring you that you're doing the right thing, even though you don't really know why.

Dan DiGangi
If you if anyone needs confirmation, if you go to, should I write tests.com? I have a very long explanation, and it just says, Yes,

Ryan Burgess
I love that. It's like, it's like the carousel whatnot, for many years ago, is like, should I use a carousel? And it's like, no, and it gives you all the good reasons why you shouldn't. It might even be in a carousel. I don't know if the site still exists, but it might have even been in a carousel, which is hilarious, going back to

Brian Holt
gem original point of being furious, as well as Dan's prior point to that. I really love junior developers, and frankly, just developers in general that are very upfront about when they don't know things and just like to gems, point of like, they start, like, going into these practices. I love when a junior developer comes like, I don't understand this. Can you please explain it to me, as opposed to just being like, Oh yeah, I definitely know that. And it's very counterintuitive, because again, the junior developer wants to show up to work and like, feel like they're, you know, not the bottom of the total, I don't know whatever Right? Like, it attacks your ego to sometimes admit that, like, lack and especially it's like, I'll tell you, it doesn't get easier, right? When you go into a meeting, when you probably know should know something you don't. I will share with you a blessed truth that I have found over my many years in the field, is that everybody's an idiot. We're all very dumb, and we all have huge gaps in knowledge. And pick your favorite, uh, engineering, uh, hero that you have, and I guarantee you, you probably have some subject that you could pin them on, that they just don't know, right? Like, I'm thinking of like Dr hip, who created SQLI, if you could probably go to hit and start talking about the the fine grained patterns that you employ and react, it's probably not his thing. Maybe it is. I'm assuming it's not. But especially, like, when we move from our silos to silos, like they just, you don't they don't know things, right? But those are those people are frequently the very the first types to say, like, I don't understand this. Please explain it to me, right? So just having that curiosity, as Jem put it earlier, which I quite liked to go back and say, like, this doesn't make any sense to me, and I want it to make sense to me. Please explain it to me. I

Ryan Burgess
also think, Brian, it's like a superpower too, right? Like, as a junior engineer, you have this superpower that people aren't going to expect, that, you know everything. So leverage that, like ask the questions you know, feel dumb, asking them, sure, whatever, but like people aren't having that expectation of you, and so use that as much as possible to learn quickly.

Brian Holt
I'm in my second week in neon. This is my fourth database company that I've worked at, and I'm still asking dumb questions about databases, right? So I. Just embrace that. It's a lifelong process to learn all these things.

Dan DiGangi
So yeah, like be willing to ask the question. Say you don't understand something. Work with someone Well, part of it's their communication skills, right, to be able to explain it. But I'll always say, because I see this a lot, and I see it with senior engineers too, is they jump to the question, or they don't put back in the due diligence to try and go understand it. Like, don't be one of those developers. Like, take some time, reflect, do some research. You know, you got to balance the line of the time you spend. But people will get very feisty if you're always just coming back and you haven't put your piece of the effort. And it's like, Well, why don't? Why is it always my 100% contribution? And then it's just you asking the thing, and you never actually go and act on it or look into it like it's a really big tip. Start building that muscle now, because when you go higher. So I always tell people, this is, you know, when you start right, you're a ticket taker. And a lot of times, here's a set of requirements, a thing you got to do. But the higher you go, it move. You get less information with a bigger problem to solve, right? Like it goes from here's the requirements to here's the problem and the expectations work backwards. And if you haven't built that muscle early on, you can have a hard time problem solving through that if you don't know how to put that time in, behind it, under it.

Ryan Burgess
Well, Said, I mean, that's an expectation of someone more senior. Is like, as a manager, I don't have to spell that out, right? I'm like, here's the problem. I trust your judgment. I'm here to help, but I'm not going to spell that out for you. I don't want to. I don't want to be a micromanager. And so it's like varying degrees of skills with someone who's maybe more junior, you might have to set aside some time to explain more deeply, but the more someone can build up that problem solving on their own, you know, the quicker they're going to grow and have better understanding. So I think that's a really good call up. Dan, you mentioned something earlier about feedback and how difficult it can be to get feedback, and I don't disagree. I think that's something that we all struggle with a little bit. I think it's super powerful to get feedback, and so you kind of have to get to get over that for get better accepting some of the feedback. But I'm curious, for someone who's new, like a junior developer, how do they navigate some things like code reviews or get better at at receiving feedback and get, you know, get better at it in general.

Dan DiGangi
So I always suggest, and actually, it's funny, I started thinking a lot more about it in covid times, which is like, I actually was really worried about the newer folks to the industry during covid Because there is something to be said about being in person and in an office and interacting and learning from each other. I would try to get much more out loud time earlier on, a lot of people like you just go to a GitHub or whatever review, and it's very cold text messages, Slack style, where people can just be very blunt, or to the point you might kind of come off as, like, what do they like me? Is it back? Like, that kind of thing. So I like to tell people, interface, build relationships. Do the out loud. Eventually you probably will move to GitHub, where you can have a little less formal or, you know, like, out loud time, but spend that time with someone and you kind of just, you gotta just kind of try and drop the ego it hurts like I was much more, like, I took it very personal, like 10 years ago, and I got level set and reset by people significantly better than me, and just realized, like, one maybe not as good as I think, but that means I just need to Learn and I need to realize, to not take that personally, that it's a hard process, and some people are going to be better at it, and others are going to struggle with it. But just I would say is, like, be willing to take a step back and be like, okay, is this really that big of a deal? Is it actually, you know, it's not a personal thing. Just like, what are the affirmations? Like saying those things out loud, saying those questions intro and retrospectively yourself. It'll help make that go down easier.

Ryan Burgess
Fair enough.

Jem Young
I'll caveat that with I don't disagree with you. Dan, the thing is, I think I've had the privilege of working with a lot of smart people who also were respectful as well, and were were looking out for me, like, I don't think I'd be in the place where I'd be if I wasn't for people like Brian and Ryan have worked with in the past that, like, helped me be better, and I knew that they wanted me to be better. However, I've also worked with people that were not looking out for me and cared more about being right than actually, like coaching somebody, and that's so it's tricky balance, because I've gotten feedback that I don't think was well intentioned at all. It was just they were just a jerk and like they're just throwing their weight around the boss, somebody less experienced. So it's kind of a catch 22 on the on the feedback. Yeah, everybody has a perspective, and you should listen to it, but also try to understand their intent behind it is this type of person that is always shooting off their mouth at everybody. If so, I'm probably not going to value their feedback as highly, because they're they're not actually looking out for me. But there are people that take the time to explain in our patients, those are the people you should absolutely listen to, because there's a million things a senior engineer could be doing. And. If they're taking the time to give you feedback on like, hey, you know that meeting you didn't really show up as well, or your manager's doing that? Like, definitely listen to them. Because I hate to use the old adage, feedback as a gift, but it is because people don't have to do it. If people don't care about you, they're not going to give you feedback. Generally, if they're assuming they're not being a jerk. So if people are doing that, take the time to listen, because they're trying to help you be better. How

Dan DiGangi
as someone newer and try and understand people, like, how do you identify those differences in those individuals? Because if you're new, like you're you're more open to just take it from anywhere. It's like, how could somebody identify that or understand that? That's the case one way or the other.

Ryan Burgess
I'll maybe chime in on that. I think that one thing I remember when I was, like, earlier in my career, my, like, my first job, doing programming, it was, obviously, it was, I've said this before on the podcast. It was flash development at the time, and I'll never forget the one engineer on the team that I was working on, he would sit down with me and spend a lot of dedicated time, like, maybe not paired programming, but like sitting down and working with me to share a concept or talk through it. And that to me, just for him, stepping away from his work, not giving me just like a, you know, quick, here's a link. Go read this document that will answer your questions. He took the time to sit with me and make sure that I understood it, that to me, was someone that I was like, wow, that was super helpful. I got better understanding. So I think what I'm unpacking here is like, there are people who will just give you quick answers or tell you it's wrong, and then there's the person who will say it's wrong, but take the time to help you understand it. And I think those are the people you want to spend more time with. That would be one way that I would look at it. You learn to discern

Brian Holt
fairly quickly who's giving you good advice and who's giving you not like someone's giving you good advice or good feedback. It's usually pretty precise and actionable in the sense actionable. God, listen the pm in the room. I hate myself when I hear neighbor. Know, man,

Jem Young
you say synergy, I'm leaving.

Ryan Burgess
Yeah, that one is, like, you're shut off. We no longer talk anymore. I'm

Brian Holt
not in biz dev guys. But like, it's pretty clear of, like, you did this, this could be improved this way. And like, there you go. And sometimes it can come across terse, but it if you come away knowing, like, what you did wrong and how you could do better. And like, you're like, oh, okay, that makes sense, even if the person's a jerk. I've gotten really good advice from lots of jerks, but if you can follow that thread, and then there's other people's like, Hey, this is the sex, and you suck, right? And it's like, it's not specific. You don't really know what they're they're trying to tell you, and they're just kind of putting you down. You learn it's like, I don't really need this person. So just learning to listen to all the advice and ignoring some to most of it, depending on where you are, in and of itself, is a really important skill that you'll need your entire career.

Jem Young
Yeah, and to add on, it is hard to discern who's giving you good advice and who just you know likes to talk and boss people around. One of the ways, besides the ways that Ryan and Brian had mentioned, is, are they how much time are they actually investing with you, or is it just they do drive by comments on your PRs, but never actually talk to you about like, hey, what you can be doing better. Here's what I've observed. You can judge a person by how they spend their time, because it's the only currency we actually have in life. And if someone's willing to sit down with you and be like, Hey, I've seen this pattern in some of your code reviews, reviews, even if they're maybe a little brusque about it, they're still taking the time to do that for you, which means something. But if they're just like, always shooting you down in meetings or shooting other people down. You know, they're just doing that to everybody. They're not really providing you direct value. And then the other way I assess people is, are they again? Are they curious? Do they ask questions like, Hey, why did you do that? Or, Hey, why are you asking this question? So curiosity says a lot about a person and someone who's just again, I'll just say a jerk, for lack of a better term, they're not gonna ask questions. They're just gonna be like, you did it wrong. You're wrong and you're bad and you're dumb, and I can't believe we hired you, and I talked to a lot of people who are in those situations, and unfortunately, there's not much you can do other than maybe have a conversation with your manager, but the manager should have caught that already. But as an industry, we kind of let jerks get by because they're probably really good coders, unfortunately, so kind of like Brian saying you have to be adaptable. You're going to run into people like this in your career. It's just going to happen. You can either try to take their advice as it's as it is, even if it's not well received, and say, like, we know what they actually do. Know what they're talking about a little bit, even though I maybe disagree with it. Or you try to find people who can provide a more balanced perspective in those sort of scenarios who are like, hey, this person said So such and such. They might be like, yeah, they're right, or yeah, they're sort of right. But maybe here's a better way to approach it. But. But, yeah, it's just experience. I think learning who to listen to. That's

Ryan Burgess
like you said, Jim, feedback is a gift. I think that even when you receive a gift that you don't like or that isn't that great of a gift, you still kind of take a second with it, right? You still open that package, you still look at it. And I think same thing with feedback is, even when it's harsh or just not great feedback, the delivery wasn't great, whatever it is, the person's a jerk, I still like to try and take a step back and go. There's got to be something though, that I can pull from that. And it's also okay to say, Nah, I'm not accepting this gift. I don't care, you know, and that's okay too. But I think taking the time to reflect and just realize, like, yeah, maybe there's some merit to there's something here that's being said that I could do better at, and just looking at it that way, trying to get something from that feedback,

Dan DiGangi
learning to say no is another skill, especially product. One of my favorite things is telling

Ryan Burgess
product No, yes, say it to Brian, right now, it's like, yes, actually, yes. But then again, you know what? Though, Brian, that's actually a good point. Hearing no is not a bad thing, even from your perspective as a PM, I know that you'll say that that's okay, like it's you'd rather hear no than I'm gonna do it all and not deliver. Yeah,

Brian Holt
yeah, no. I like no because, I mean, someone's thoroughly thought through what they're actually, you know, doing and thinking about, and they've come to the conclusion this is either not not a good fit, or we don't have enough space, or it's not prioritized correctly as a as a PM. And, I mean, you get, you get all shapes and sizes the PMs like that, all like, I'm a very collaborative type in the sense of like, I want our work to be reflective of what we're all doing together, as opposed to just being like the dictator that says, like, we're doing this, this and this. So know as well, for superpower, from your perspective, that, like, it shows that you've considered what you're doing and you think that you have either something better or there, or, you know, something like that, or and it's, it's good to hear from other people as well, and to incorporate that like I was just thinking like a big moment in my life, is what I realized is, like, I am not my work, right? And I have a whole ass person that exists outside of my job. And so it made it a lot easier to take this feedback of like, you know, like I'm this isn't a direct tack on me. This is just me improving and learning that made all this feedback much more welcome in my life, because it was just like, This is how I get better at my trade. But it's not necessarily an attack on who I am that's

Ryan Burgess
good to remember that one. That is definitely a good lesson to remember. And then actually, on the say no aspect, I think I just was like, Oh, this is a good piece of advice that I think is really helpful is also, when you're asked, like, an estimate or to do something, don't just answer, like, take some time to go do that. I think that that's a mistake. I see a lot of engineers, doesn't matter what level they'll make that where it's like, Brian the pm has asked me to do this. Yeah, I'll have that done for next week. Don't do that. Like, take some time and, like, look at the what you're having to do, and think through what the level of effort is, and you know what, what is it actually going to take to do that? I've made that mistake so many times where I'm like, yeah, yeah, it's not hard. And then I uncover, like, six things that I didn't account for, and nobody wants to, like, under deliver that's never great. So I think it's to the no part is also saying, like, let me get back to you on that. Like, I think that can be a really helpful tool. Everyone

Brian Holt
sucks at us. Estimation, it's a universally terrible and hard thing to do your PMS who already know that are they also they're also new as well. So just be aware of that when you when people start asking to estimate tasks, like everyone knows, like this is an impossible task in front of them. Along those lines, my best advice for you is to give them kind of the range and feel like, if it's really easy, then this is what it's going to be. And if we run into that, like this hard edge case, because, like, all that stuff is floating around in your head, or should be right? That's if you're considering it. And like, average case, I think we're going to be here. And then usually your TPM engine manager, PM, whoever, whoever's managing all that kind of stuff, can usually build some like, buffer into the schedule for that. But if I was going back and talking to brand new developer, Brian and I was giving him advice on how to estimate software. I would start by saying, like, all of the essence that you're about to give are way too low and you need to double to sometimes triple the amount that you think those are. I think over time you start getting better at estimating it. I probably didn't play them by like, 10 to 15% now, but I gave outrageous estimates when I was a junior developer, you're

Ryan Burgess
overzealous. Why were you the opposite dad?

Dan DiGangi
No, I misled it. No, no, yeah, I was over aggressive, and that bit me way more times than I care to admit to. And then also, yeah, put me in a rush mode, because I'm like, Well, I said this, that's what I made the expectation, and now I look like. An idiot.

Ryan Burgess
I mean, this kind of what we're highlighting a lot here too, which is really funny, we kind of started the conversation talking about some of the technical skills missing. But a lot of what we've been talking about too, is just some of these non technical skills, right? Like time management, you know, being curious all these things, what are some of the other skills that just are overlooked? I think, especially as junior developers, I think that's true is like, at least when I look back on my own career, it's like, I think I just needed to be technical. I needed to be the most technical, and I was going to be the best there is to be on whatever project. It had to be technical. And I don't think that that's necessarily true, that I don't think you can ever be the most technical, because, like Brian said, there will be someone who knows a deep, deep concept has, you know, been the Doctor of, you know, some database that's out there, but they don't know every technical detail in something that's like a front end JavaScript library, like, there's just no way to do that. And so I guess where I'm headed is like, what are some of the like, critical skills that are non technical, that are often missing in in the junior developer? Speaker 1 I know I was like evil little laugh

Jem Young
being I'm just gonna say, Be curious again, learning how to learn. It's been called out early in the episode that nobody knows everything, and it doesn't matter how smart you are. You could be a savant at software engineering, but there's just things you won't know. You won't know, the bespoke systems of the company, the processes, a particular tech stack, the language, whatever. You're always going to be learning something new. So learning how to learn and learning how to ask the right questions to get to the knowledge that you need fast is a skill that will pay off dividends in the long run, and it's something you can flex really early on as a junior engineer, because you just don't know that much. So you're going to be doing this a lot, and the more you're comfortable with doing that and being curious, understanding your own ignorance, and learning how to how to learn, the better off you'll be starting from zero all the way to principal or CTO or whatever level you want to achieve. It's something that pays, pays off through

Brian Holt
and through. So I think the the most difficult engineering job I had was was at LinkedIn, when I was doing kind of like web core engineering for LinkedIn learning in terms of just raw difficulty of the stuff I had to do. I still think I could take a high school student that codes fairly well, or maybe, like a, you know, maybe a junior and an undergrad program and teach them to do about 90% of the job that I was doing, and I think that's applicable to most software engineering jobs, maybe 90 cents, percent aggressive, but at least 80% right that most of the job is not about being technical, and could be done by interns, could be done by junior engineers, and Then that last 15 to 25% whatever you want to call it, ends up being that experience that we just talked about, and learning how to apply it. So in other words, going back to Ryan's point is, it's not about being technical. It's not really the point here. A lot of these jobs could be done by anybody. What becomes more and more differentiating at the at the higher tiers is sure that 15 to 25% is interesting and different and different. But I think what makes people climb the ranks and get promoted and become CTOs or CPOs or VPS, Avengers, or whatever you want to end up being, is communication skills and learning how to get to the point, derive the heart of the matter, figure out what customers want. Coordinate across teams, coordinate with your team, learning how to write a good email, learning how to send a good Slack message, learning how to talk to a customer, to figure out what they need. And like all and like, learning to communicate with your manager. Like this is what I'm doing. Here's where I am, here's where I'm about to be. Is this? Am I working on the right things? All of that communication skill is what's going to differentiate you, and it's how some people that in your cohort of people that getting hired the same time are going to rise really quickly. I don't think many of them will be much better at coding than you are, but some of them are gonna be way better communicating. Communicators than you are. Like that is what's frequently valued in terms of, like, promotion packets and hiring and all those kind of things. It's it's the most critical thing. And a bunch of people still never learned that I did most of the CS degree before dropping out. And the thing that the class that I referenced the most from my undergrad is still and it's by far, is my technical writing class, like I write emails and all that kind of stuff, and now I write specs as I'm a product manager. And I just think about that class constantly. And I hated that class, to be fair. Right? Like I did not like the class, did not like the professor, but unfortunately, it became extremely important my career. I

Dan DiGangi
feel annoying to harp on communication, so I'm just gonna say, agreed on that one. Maybe I would give all right to I know Ryan, I've been looking at the questions in the background, which is the side of relationship building it should be, hopefully, it's an obvious one to a lot of people, but is kind of get to know people and talk to them and understand what makes them tick, right? If you think the communication angle, not everybody is a good communicator, or they just have a different style, it's great if you can communicate, but can you adapt communication be with the different styles, especially, right? It's different talking to us in the room than it is Well, Brian, then product or CTOs or ELT or whatever, right? Like, that's huge. So I won't bark extra on the communication relationship side, I want to call it wine, and I hopefully this isn't like going too shotgun, wide outside of the question, but I think it's really important. So you have to get to know your product and customer. It is so crucial. And so it's cool with the job I just came into ActiveCampaign is it's, uh, so it's email, transactional and delivery, so it's the under the hood piece. So my my customers are developers, and it's API driven. So I'm like, Oh, I know those guys. I'm one of those guys. I know what I want to see in an API, and what I found that I was struggling with is because it came so full force, I didn't do as good a job the first couple of months, like spending the time to get to know the product. So like super tactical advice is it takes a long time to get to know the system, the product, the customer. But what I always tell people to do is every week, just like you could do this with technical. Take a piece of it, focus on that, spend the time on it, get to know that piece. And I don't even mean the technical, eventually you go there, but understand the pieces, how they do start to connect. And then you can start taking yourself down another layer. You just take it like a piece at a time. Instead of trying to a jack of all trades, learn the whole thing at once. It's compartmentalizing, and you're going to be a lot more effective, and you're going to see more pieces. And what this leads me to is you can contribute in other ways besides this, which comes to visibility. And this is something that I think juniors miss out on a lot, is bringing visibility to themselves in the organization, their contributions, putting themselves out there, or just being passive and only waiting for what comes to them not speaking up. These are some big ones I think that really need to be called out on the non technical side. Well,

Ryan Burgess
that's actually a lot of helpful advice in this episode. I think this is a good time for us to dive into pics in each episode of Front End Happy Hour podcast, we like to share things that we found interesting and want to share with all of you. Sometimes they're products that we've purchased, TV shows we've watched, or, who knows, sometimes Jem shares us ridiculously expensive things that ecoins Valley, silicon, yeah, Dan, what kind of picks do you have for us for this episode?

Dan DiGangi
So I've been going through a lot of stress at work and in general, like my life personalized, been kind of with the willy side with work. So one of my engineers on my team suggested a spoken waking up like Sam Harris. So it's spirituality, not religious, but around meditation, mindfulness. And I've been reading it like hardcore and it's been really, really helpful. So easily, one of my favorite things I picked up recently,

Ryan Burgess
what's been your biggest takeaway from it.

Dan DiGangi
It's funny. It's, I mean, it's funny. I know meditation has like proven scientific benefits, but I don't know if it's this is interesting, or is you ever like you read something, but it's you read something or hear something from two people, and the other person said it one way. And now let's say I hear from you, Ryan, and just by reframing and re saying it in different ways. It's like, that clicked for me. And I don't know it's just the way that the author, Sam Harris writes. It's been clicking. And I'm just like, Yeah, I just, I really got to get going on this

Ryan Burgess
awesome. No, it's fair point. I think I have definitely heard of the book and haven't read it yet. So that's I might have to check that one out. Jim, what do you have for this episode? Uh,

Jem Young
I have two picks. One is a book pick. It was recommended by a partner manager. It's called Scaling people tactics for management and company building by Claire's HUGHES JOHNSON. I'm not a big fan of leadership books. I tend to read. I tend to read to escape and not think more about my job, which I spend far too much of my day doing. However, I realized in talking to the people I trust, I've kind of hit this point in my career where I just need other perspectives on how I should behave and how to scale myself. And this book like, kind of hit just the right notes. I'm still in the middle of it, but even even what said, what like, even in the early chapters, I've gotten a lot about just perspective on management and leadership that I really hadn't considered. Probably the biggest one that I've really taken to heart is the difference between management and leadership and how they are two different things. But as leaders, we have to do both, and we have to shift from one to the other, depending on the person, the situation in time. But even putting that mindset. On has really helped me. Whereas there's times when I'm like, being a manager sucks. It just does. Versus no the management part sucks. The leadership part is great. How do I get more the leadership part and take care of the management part? So it's been a really helpful book for me so far, and probably one of my rare non fiction book recommendations. The other pick is a music pick. Since Stacy's not here, I'm going to pick Max Richter. His album in a landscape comes out, actually in about eight days or so. But there's some release on the tracks. The track movement before all flowers is just phenomenal, probably one of the most beautiful tracks I've ever heard. I have it on repeat. And Max Richter, I'm a big fan of of his work, so check out that that track. I think you're gonna like it. Sorry, I don't have the eloquence describe music the way Stacy does.

Ryan Burgess
But, all right, Brian, what picks you have for us?

Brian Holt
I got a few. One of them is, I am presently homeless. I selling my house. I don't have my next house yet, so I'm literally living in a friend's house at the moment. So I'm in Minnesota, and I went to the Minnesota State Fair, that was extremely fun. So one of my picks is you should definitely go to your state or county fair, but definitely just the Minnesota State Fair is very, very fun. One of them is a game I started playing on Steam work for them on my Steam deck called dungeons and degenerate gamblers. It's very fun. If you've ever played is, I don't know if I'm saying it correctly, baltro that everyone really likes. It's another one that's very fun. If you haven't played that. This is like a, I would call it even a step further than that. It's basically like a, you play blackjack with people, but you get like, tarot cards and Pokemon cards and Yu Gi Oh, cards in there. It's very funny. You get like, bus passes and library cards, and it's, it's just ends up being extra ridiculous. Oh, and then I have a technical pick that I've discovered recently, and I thought was very cool. It's a company called Electric SQL. And they take, they take Postgres, and they make it available inside of your browser, and then they can sync it to your back end Postgres. You can read write to a local copy of your Postgres, and then it syncs it back to your database. So all of your queries are happening like at the speed of localhost, which is pretty compelling. So I'm still playing with it. One of the founders was one of the creators of Gatsby Kyle, so that's kind of what caught my eye about it. So yeah, it's been pretty fun to play with so far. That's not sequel light. It is not, it is Postgres,

Ryan Burgess
yeah, well, I'm gonna follow suit with I guess Brian didn't keep going with the book picks, but I'm gonna pick a book. It was actually picked on an episode. I think I can't remember how long ago we'd done this. There's a few episodes ago when we were talking about taking a break, our guest, Jennifer had shared the book ikigai, the Japanese secret to a long and happy life. And I think it just, it may even fit a little bit down with your pick, but it's just being thoughtful about what you're doing in life, and looking for the purpose, and just thinking about longevity, and it looks at a lot of cultures on like how people have lived long, healthy lives, and like what has helped them to do that. I think it was such a great read, especially being on a break right now from work. It's just, it's a different perspective and thinking. And I really thoroughly enjoyed it. And so I'm thankful that Jennifer suggested it, and that's what stemmed me to go read it. So thank you, Jennifer for that, and I highly recommend that as my pick this episode. Brian, Dan as always, big pleasure having you both on. This is an awesome conversation. I think just hearing some of those insights into you know, what's impacting people earlier in their career, I think is always really helpful. So thank you both Brian and Dan. Where can people get in touch with you

Brian Holt
still hold PC on Twitter. If you haven't caught up with me already, you probably

Dan DiGangi
don't want to Dan deganji on Twitter, even though I'd love to leave that someday, but it's the only place you can find a dev community. It's so unfair. Yeah, yeah. It's

Ryan Burgess
so spread out too. Is like, people are like, Oh, jump to threads, or blue sky, or whatever else is out there. And it's like, but now it's just spread out across the board. It's like, I think most people are going back to Twitter, all right. Well, thank you all for listening to our episode. You can find front end happy hour at front end, HH on Twitter and @frontendhh on YouTube. Any last words?

Brian Holt
Why do you keep inviting me back?

Ryan Burgess
I never learned Brian. I never I think

Brian Holt
that that's true. I.