Remote Work And Being A Better Dev - Interview With Eric Roby

So yes, to answer the first question, yes, I am full remote now. >> Cool. Okay. Yeah. Awesome. And then uh what was what was the second did I ask a two-part question? Hi, my name is Nick Cosantino and I'm a principal software engineering manager at Microsoft. In this interview, I was joined by Eric Robbie, who shared his career journey as well as his experience as a software engineer, primarily as a consultant. Now, there's a lot of really helpful tips in this interview, especially because there's focus on remote work as well as how you can handle communication, and there's something in there for junior engineers as well. Now, I really admire Eric. He's an excellent content creator and a very successful course creator as well. This conversation for me was a lot of fun, and I think that there's a lot of knowledge that you can take away from this. So, thanks so much for watching. Sit back, enjoy, and I'll see you next time. Are you fully remote then or in office? >> Yeah, so I'm remote. Um, I used to go in the office. So, my my uh world was also kind of weird with that where we So, I work at a company called Willow Tree, which is a uh pretty big like um consulting company and we like specialize in well, we're kind of changing right now a little bit in some ways, but what we mostly specialized before was uh public facing apps. So a lot of like um you know a lot of people are using like the unique >> a lot of unique users each month and all that kind of stuff. So but we had branches scattered um in different areas of the United States at one point. So we would like go into the office to work remote for like a company and it was just a bunch of like goofy stuff I thought like instead of just being remote here and then like working with your team remote, we would also like go to the office and work remote with your team for a remote client. Okay. >> It was just, you know what I mean? So, a lot of remoteness going on anyway. So, it was ended up being like a really good match to be able to just do it full remote. So, yes, to answer the first question, yes, I am full remote now. >> Cool. Okay. >> Yeah. Awesome. And then, uh what was what was the sec? Did I ask a two-part question? >> No, I don't think so. It was just uh am I remote now? Yeah. >> Oh, no. Okay. I was like, wait a second. into my >> no because that's I mean for a lot of people that's like either been a huge shift like going over the past couple years right going fully remote but was that always the case for you then like >> uh like when you were working at this company it's kind of been set up that way the whole time or was that a shift during the pandemic? >> Yeah, that was a shift during the pandemic. So um I have like about a little over nine years experience like professionally. So I started um so if we like went way back my my father had like his own consulting company back in the early 2000s late 90s. Um so I was kind of in the the coding world then. Um so I was kind of introduced to coding early where I would actually do some remote development for his company. So like when I was like 13, 14 years old, he would have a company where he would go into uh the office and to the client and then I would also help him code a little bit during the day like on summer and things like that. So I was really able to kind of learn one kind of working alone remotely because uh my dad wasn't always there. Um and it kind of got me exposure to um programming in general for enterprise companies. I later on got my uh computer science degree and started working at a company where I did have to go into the office every single day. And um that was a good experience especially when you're when you're newer. Um like I was working with my dad's company for a little bit but working in the office definitely when you're more like on the junior side of things I think is a really beneficial. Um I was able to surround myself with um some awesome people, awesome mentors. I I was lucky to have awesome leadership as well, which really was able to propel my uh career. Um and then my current company, we were in the office um 5 days a week um when we first joined. Um and then during COVID, we all went remote and then we went to like a hybrid uh solution and um now I'm on a uh branch that is remote, but the whole company is not remote. >> So, >> okay. Interesting. And I I like your point um so about juniors getting started and stuff and how it can be beneficial to be in person. Like I'm not I'm not the kind of person that's going to say like hey like a company has to work one way or the other like you know being being fully remote is you know clearly better than being fully in office or the other way. I think there's uh benefits to both, but something I've observed especially with more more junior folks is like if you have if you're very comfortable as a junior and able to reach out and like that like at any point you're like I have a question I want to talk with someone and you're comfortable reaching out to people. >> I think that like getting onboarded remote and stuff getting started remote isn't so bad because like you're getting over those barriers. But if you're hesitant at all and you're like, I don't want to bother people or maybe I should think about this a little bit longer and it's like, you know, 2 3 days before you get any help, like I think for those types of individuals, it can be very challenging to to get like some momentum in the beginning. But is that kind of like what you you've observed as well? But before we move on, this is just a reminder that I do have courses available on dome train if you want to level up in your C programming. If you head over to do train, you can see that I have a course bundle that has my getting started and deep dive courses on C. Between the two of these, that's 11 hours of programming in the C language, taking you from absolutely no programming experience to being able to build basic applications. You'll learn everything about variables, loops, a bit of async programming, and object-oriented programming as well. Make sure to check it out. >> Yeah. So, speaking from just like my personal experience, like you said, like everyone's different. Um, me being in the office when I was newer helped tremendously because like if it's your first time working in enterprise applications, there's a lot of like things that make enterprise applications different than like your side project, right? There's um a lot more scalability happening there. There might be like um code that you've never seen before. Just a lot of things that are different, especially if it's legacy applications, right? I mean, that's like a whole different ballgame. And um I know when I was a junior it helped tremendously being able to sit right next to so right next to me was a staff engineer and then right across from me was my engineering manager and I was lucky enough to that the staff engineer wanted wanted to help me grow, wanted to be there for me. So he would always be able to push me in the right direction and if I ever got stuck he was right there to kind of point to the folder or point to the business logic that was making whatever happened. And I know me personally that helped tremendously because there was things that like I can't think of it off the top of my head but I remember like having like aha moments like puzzles were connecting of like oh I didn't even know this worked with this or you know maybe the first time you see actually like real life dependency injection in code and you're like I don't have to create every object or you know like things like that and like how does this work? Yeah. or like if you're doing like side projects and stuff, you might not like understand certain words like whether it's like the service layer or like what's the domain logic or anything like that. Those things might you might hear it but you don't actually know it until like you're working in a a team atmosphere or a bigger project that can kind of um you know show you what those are. And maybe that's just me. That's just I just know it was beneficial to me. >> No, that that makes sense. Right. And especially on the last part, the like the terminology, if you're working on side projects and you're working solo, like your level of communication that you have to to play with is really like yourself. So, if you're able to like you can kind of keep scraping by or whatever, making a little bit of progress like, and it's not that that's bad, it's just that you don't get a good opportunity to practice like like you're not relaying your thoughts and how you're navigating things to someone else. um unless you're writing about it online or you are collaborating with someone else on your side projects, you kind of get that uh I don't know like this restricted view of communication and it's really just like purely technical for the most part. So not bad just you don't get to practice that. So kind of >> right and I think there's there's like a level of like especially in software engineering there's definitely a level of like you don't know what you don't know and what I mean by that is like if if you don't even know something exists then there's no way for you to even be able to find what you may be looking for right so so there might be like a like a problem that you're facing but if you have >> if you don't even know what the fundamentals of like what that is and it's kind of hard to to explain that but there's definitely like a large amount of like if you don't know then you There's no way you're going to be able to solve that. And you're going to need some kind of like steering in the right direction. >> It's almost like you're you've been programming for a bit and then it's like two-dimensional and then someone like says something and they teach you a concept and now you can see like the world in 3D and you're like oh my god. But like that was dependency injection for me. I'm like once someone was like hey like uh so the pattern that I experienced was you know and I think it's pretty typical if you're doing object-oriented programming you're making objects and right in the constructor you're like what are all the things that this thing needs and you just knew them up right on the fly so you keep doing this and then you reach a point where you start to realize hey I want to test things or you're doing whatever else in software development where you start to realize like this like this seems like it's kind of nasty like I have the name like 50 things that I'm newing up in like these other 50 spots like why is >> what's going on here and then okay so you get into like constructor parameter passing and then you're like this is actually way better except >> now I have this chain of anytime I want to go add a new dependency like I have to start passing it like 20 layers down until it gets to where it needs to go and then someone tells you cuz you end up in this spot where your entry point to your program is now like 2,000 lines long of just like newing up objects >> and you're like okay so I made everything better except this like what's going on and someone says dependency injection and it's like >> like one line of code just makes all of that go away and it's like this is the best thing that's ever happened. Yeah. And it can but it can get like confusing if you have no idea what it is, right? Like dependency injection. Then there's inversion of control and you're like wait is that the same thing or is that different? And you know you just keep going down this like like um like for me like dependency injection was your big aha moment. For me it was caching and like I've always heard of like Reddus and I'm like what the heck is caching though? You know what I mean? Like why would we ever use caching? and then just kind of like ahao moment when we first implemented caching for the first time and I'm like oh my gosh mind blown right and it's >> right but it it took someone to kind of like steer you to expose you to it and then once you see it in action you're like oh man like how can I how can I do things uh any other way now right like this is the thing like >> it's very cool um >> the I was thinking back when you were kind of talking about your experience and saying like you had like a say like a more senior engineer that you can kind of turn to and get guidance I was even thinking for myself going through internships like if I'm being honest with myself I am probably the person that if I was remote probably would have done poorly because I can remember uh you know I worked at startups for my internships in small companies and I can remember being like nervous and just sitting at my desk uh either sometimes it wasn't even asking questions like I need help it would be like I'm finished my work and I remember not not anyone else's fault like I I think I worked with great people but I can remember being so nervous and I'm like I don't know if I want to turn and like even talk to my mentor to be like hey like I'm done like can I get more work? It was just like I don't want to bother people and I'm shy and introverted. >> Um so if I was remote that would have been so much worse. I can't imagine that I could have done any work. >> Yeah. And that that kind of happened with me too. So um I I think if I was new at a or junior at a new company, I would have been reaching out. It's it's almost to the point of like do do you even know what to reach out about? And I think that's kind of it kind of all trinkles down to is this a dumb question? Is what am I really asking? Like you know and >> as you start getting more experience, you know exactly what kind of kind of questions to ask. Um to really be able to solve the problem. You get you know what the root of the problem that you're facing is instead of just being like I don't know what's going on. You know, you're like raising your hand. Can I have help? You know. >> Yeah. like can I have help because I don't even know what I need to be asking. But this is a it's a it's something I've observed a lot especially with with junior engineers and and interns. I've worked with interns my entire career. So, uh like my I was an intern and then as soon as I went into the the professional world as not an intern, I literally had interns like working with me. So, um always been around them >> and it's a pretty I feel like I I kind of bucket that situation into like two types of things. And one is like you have a question that okay you're stuck on something but you're stuck because you don't have enough clarity around what you're even trying to go solve. Like someone's tasked you with something and you're like I actually don't even know what you mean but now I'm off on my own and I just don't know where to start cuz I don't even know what you asked me. And then the second part is like I understand what you asked me but like I don't know like which path to pick or like where do I even where's the jump off point for this? And in the first example, I always tell people like if you don't have clarity, just like as soon as possible ask. Because if you're sitting there trying to problem solve on your own and you don't even have clarity about what's being asked, you're you're kind of just wasting time. You might as well just say like, "Hi, I don't know what you even asked me." Get that out of the way. >> Yeah. The second part is like if you if you don't have a jump off point, I think this is the part you really have to practice because it's like try getting something done, right? You you understand what someone's pardon me, you've asked what someone's asked you. >> You understand what someone's asked you, but you you don't know where to start. So like just start somewhere. Get a little bit going >> and then then you can go to someone. And I I always recommend that people think that person should be asking you, "What have you tried so far?" And if you feel like you can at least answer that and have a conversation, then you've done at least enough to have that and and not like waste someone's time or not ever practice problem solving. But what are your thoughts on that? Does that seem like a fair approach or anything that you might change with that? >> No, I think that's that's a perfect approach. Um the only thing I would also add is uh for for like especially like interns and newer developers also too if you're in a senior position or um or higher just check on them right cuz I I have worked with interns and uh junior engineers before too and you ask them hey is everything going okay right let's just for easy easiness hey is everything okay they're like yeah thumbs up tickets going great, you know, we're working on blah blah blah blah blah. And then later on they're like, hey, Eric, I'm stuck on this part. Like, okay, like, let me let me dive in. And then you realize that they're stuck on, you know, this part because the original 70% that they were working on is in the wrong direction. And you're just, whoa, whoa, how'd you even get here? You know what I mean? Or wait, what? Okay. Oh, okay. So, you just created a new object. Oh, we don't need to create this object already is over here. And we can just add over here. it's already, you know, and I think that that's a big thing, too, is just making sure that, you know, you include everybody that's on your team into conversations into areas where they can grow because I think that's that's the biggest thing. And like when you're when you're a senior or higher, I truly believe like one of the main roles for me on a comp on on a team is to remove roadblocks for the team >> to make sure that the velocity keeps moving to make sure that hey the the the juniors and the the middle level people are able to able to keep creating tickets, keep knocking out tickets, keep committing code, keep checking PRs and not being stuck on something that maybe I can help solve or maybe I could have helped remove the barrier before they even out there. So, I think that that's a that's a good point as well. >> Yeah. And I'm trying to reflect on that a little bit because I' I've experienced that even for myself. Like even though I've said I've worked with interns my whole career, like I think it's easy to get into a pattern where you're like, "Okay, someone's someone's onboarded." Uh you've checked in with them enough where they're they're able to say like, "Yeah, I'm doing okay." And you start to go, "Okay, well then you're okay." They keep doing work then. And then your check-ins become like you might do them periodically, but probably what has to happen and maybe I should shouldn't say like has to, but um what I recommend is like especially in the beginning like be a lot more hands-on so that you can from the start get that person confident at least getting changes through and um you can try to catch some of like >> if you haven't worked with them before it's kind of like someone's gone through an interview, right? you've read their resume, you've talked with them a bit, and you're like, "Okay, seems good." But when they start coding, there's probably going to be a ton of stuff where they're like, "I just don't understand this." And that's totally fine. So, if you can get them through the first little bit, and you are a little bit more hands-on, it takes more work, but you get them through that bit of the the beginning process of pair programming, however that looks >> enough so that you're like, "Okay, like you should be able to kind of touch code in this codebase and not be totally lost." I think you can mitigate a lot of those problems, but it it takes more work. But >> yeah, and when you do that, I think I think there's there's really only wins there. Um, one, um, you would get closer to the the individual. Um, so you you get to learn more about them, know who they are as a human versus a software engineer on the team. And then also they probably increase their confidence, right? they're they they not only learn more about you as well and feel more, you know, integrated into the team, but then they also learn the codebase and learn maybe their role a little bit better. And I think I think that's that's a that's a great point to make. >> Yeah, it's a it's there's no one way to do these things, right? But I think uh it's I think you said it really well that like the more senior you are like the more time you can spend trying to help unblock things is really beneficial. But the the thing so fully agree with that and I think the thing that people have to be a little bit careful of is that >> unblocking people does not necessarily mean solving their problems for them all the time. Um you want to lean into like >> and it depends what the problem is, right? Sometimes you're just like you shouldn't be spending time on this. I can unblock you right away by solving it for you. But a lot of other times it's really about let me show you how you can solve this for yourself and that way you're not relying on like you don't end up as Eric being like I have to go code on behalf of six other people now because >> I am their problem solver like you teach them to problem solve. >> Have you had that kind of challenge in balancing like where people are coming to you and you have to be like man like they keep coming back do I need to like change my approach in in helping them? >> Yeah. Yeah. Yeah. So that's that's a good question. So I have ran into it before and I want to say typically when I do run into it, it is a mix of me helping too much and a mix of um the individual not actually wanting to learn and just get their their ticket done. >> Okay. >> Um and so so most of the time, no. So most of the time I do not run into that. Um, a lot of times when when I'm trying to remove roadblocks to help people move is we go back to the caching solution, right? And say, "Hey, we're having an issue because of performance because we're relying on a third-party dependency that we only that we need to call every single time, but it returns the same data every single time. So maybe we can just cache that solution and we don't have to rely on that third party um dependency every day. We can just do it one call a day and then save it and then we have a TTL that removes it at the end of the the day. Now maybe with that we're like hey we need to structure um how we want the the Reddus tables to look how are we going to integrate Reddus into our application we need to create new code to contact that Reddus and all that kind of stuff. So where I would remove the roadblock in like a situation like that we have a team we are creating tickets on implementing caching maybe I would take the lead or the initiative on setting up Reddus real quick on you know if we're using some cloud infrastructure we can say like Azure AWS setting up Reddus setting it up within our infrastructure hey our application can now connect we have the dependency installed all right now we can kind of delegate maybe some of the code to integrate that now into our application So I just removed the big roadblock of hey we want caching all right now we have it set up now some now we can delegate all the other tasks to get it working while I work on the next big initiative and >> right >> so I think that's one way now there's also definitely a part of it where it's like hey guys maybe we can all work together so you can learn what we're how we're doing this but I think that really depends on the project um the timeline the features all that kind of stuff so when I was mentioning like remove roadblocks I was talking like take initiative of like maybe creating part of a solution that can now start being delegated. >> Yeah, that's that's a really good call out too. I think um like when I think about managing teams and when I have like I've talked about this before uh on social media where like >> an ideal team is not just like a team of like seven of the highest level engineers like it um there's I think on paper that might look good but in practice it's like there's things that that you want to have a spectrum of uh of backgrounds like levels like talent skills you kind of want to have a mix of things going on and one of the reasons is is for what you just called out like being able to be in a position where you can say look like as someone who's a little bit more senior I can take at least some initiative to get this started and put it in the right direction and then I can work with other people on the team to help delegate like uh to the most junior person it's like hey look you can still help with this and it might be something very small bite-size very well understood but like I've set things up where you should be able to do this and you can take a little bit more time to go learning because you you're very new to it so you set them up on it someone who's a little bit more senior you and say, "Hey, like this stuff's in place, but it's up to you now to go build out um sort of like our our core logic that's going to be communicating with the the Reddis cache, right? So, you kind of set them off on something that's a little bit more uh bigger and scarier and you know, just the when you have a spectrum of levels, you can you can delegate different types of work that >> say uh someone who's a very high level engineer, they're like, I could do that. I could go crank out 50 things like that, but like I don't it's like it's not engaging. It's not challenging. And you can kind of get those people set up on more uh forwardlooking things, more complicated challenges. Um but you kind of want a spectrum. Um does that does that resonate or any thoughts on that? >> Yeah. Yeah. Yeah. And no, that that's exactly um what I was getting at. And I think also like when you were talking it kind of made me like also think of like just because maybe I set up or I'm going to quit using I the the senior engineer sets up the the Reddus um you know cache for other people to start delegating but that doesn't mean the other people didn't learn because there was also a point where the senior engineer didn't even know what caching was or didn't even know what Reddus was. Maybe that's like the intro to someone now learning about cache. Maybe the first step is not implementing Reddus itself but just working within Reddus right of of a system that already has it integrated. So I think that's also a great point too that when you start having um a team of more like diverse skill levels maybe the staff or the the senior can start integrating the reddest or the cache and then you know a junior person's like I don't even know what caching is but that now sparks some kind of like you know investigation work or now they're working in cache and now they're like oh so this is how it works and then next time they're now capable of implementing Reddus because they know what caching is right and I think just to kind of add on to what you were saying I think That's a great point. >> Yeah. You get like this this like bleed over of skills and exposure where even the most junior person who's they're tasked with the simplest part, they're like, "Cool." But like I keep hearing you guys talk about this other thing and I'm in the code now. I can kind of see some of it and it's like oh like that's that's kind of neat. It might still be a little bit scary, but at least they can be like, "Hey, like you can start asking questions. You can start just having more exposure to things that you otherwise wouldn't have." So um yeah. No, that's that's cool. Do you find in your in your current role uh and I'm just kind of curious about like given that it's remote, do you find that um like team collaboration and stuff is >> is uh I don't know like I don't want to say at an all-time high. I imagine if there's some remoteness maybe it's not. But how do you find like your team composition and your ability to kind of work with others like just given the the setup for how you guys are set up? >> Yeah. Yeah. Yeah. So I think remote so so for remote to work I believe there's really like two two schools of thought um to for remote to work for everybody on a team um everyone needs to be remote and I think that just helps promote um how we're going to be doing communication. So um if if everyone on the team is remote well then everyone follows the same rules for communication. If only a few people are remote and that's kind of like how my case is, then it's really up to the individual and it's not really up to the team to make sure that the communication is high for the remote people. And I kind of like so I think a like a lot of teams will think we need to include the remote person. Well, I actually think it's the the opposite where the remote person needs to try and include themselves because it's very easy to be hidden. I think it's um you know as a remote world. So I follow a lot of practices that um that I've made just from research and that I believe in where like pretty much anything I want to communicate I usually do it in our um like team Slack channel. So there's usually multiple different Slack. So I I rarely will DM someone like specifically about something unless it's like 100% just about them and no one else can get any learnings from it. So I will try to like promote it into larger channels and tag the person so every everybody else can learn, everyone else can read, everyone can follow along with that um information that's getting set. If we're talking about a ticket or a a feature upcoming, we we'll create a thread and we'll you know kind of recap what's going on throughout the the Slack channel. And I think I kind of forget the original question, but I think um for remote communication to work, it's either everyone needs to be remote or the person that is remote needs to really take um initiative of trying to be extra collaborative. Um because if not, I I kind of feel like you'll start like kind of floating away from the team. And and you'll see that in like Zoom calls. If the Zoom call, everyone's in the room and then there's like one or two remote people and like eight people are in the office. Um, as much as you're trying to include the remote people, there's definitely going to be small talk going on that even might be about the ticket that the remote people can't hear, right? And I think it's really up to the remote person to take initiative and not necessarily the team because they're just being human at the end of the day, right? I think it's not as human to try and make sure that all that you're always in front of a microphone so everyone can hear and all that kind of stuff. And I think it's up to the remote person to really take initiative there. Yeah, that's uh I like your your approach of uh like basically public public chat communication. I say public as in not to the public world, but uh like you know just not an individual. Um so that's really cool. Um I've seen that. It's funny like some of that stuff is like I see it happen and I don't know if people are doing it consciously or not. Like it might have just been and I I find myself doing this. Maybe it was just a convenience thing. I was already talking in the chat and then I'm like, "Oh yeah, I got to ask uh Jim or Bob about some other work and like they're also on this feature crew or team and like I might as well just like I'm talking already, might as well tag them." But that uh like doing it consciously is really awesome because it's like anytime I'm communicating, if someone else could benefit from this, >> they literally just get to learn. They get exposure. Uh uh and it sometimes it's not even for more junior people to learn about something. It's just keeping the team in the loop about what's going on. >> And when more people start doing that, the the visibility of all these pieces just goes way way up. So it's cool. >> Yeah. And I think there's also a level of so like so for like broader communication that works well but one thing that I also try to avoid um and in shorter terms uh like putting people on blast like if you find somewhere where someone can learn tagging them and then making that public also is not like the the best solution even though other people might be able to learn you might be able to communicate with that person directly. and then say something in the channel that doesn't tag that person or make it look like hey they they started this right so I think it's kind of like a strong balance but yeah I think I think um public communication within the team especially as a remote is um definitely a necessity >> and that's a thank you for making that distinction because I think that's a really good call out it's easy and some people don't realize this as well right there because they're they are doing the the teamwide communication and stuff like that but the When you if you and maybe people aren't even thinking this, but if you are going to communicate something that might potentially make someone like kind of stand out as doing something not great, it's probably a good practice to like to reach out to them first. Uh because your intention is hopefully like it's not to be trying to make someone feel upset, right? You just want to hey look like I found an issue or something like let's chat through it. Um you know, you're not you're not there to blame them. You're just there to say like we got to fix it and understand it. So if you can do that part in private and then communicate out whatever learning or actions are being taken to the wider group. Again, you might be be able to say like Jim or Bob is going to go handle this thing um >> that was uncovered or whatever. Like that's >> it's fine. But if you're like, "Hey, like Jim or Bob screwed this up." Like it's like you don't have to you don't have to publicly put the blame out there. It's more just about like visibility uh into the the follow-up actions. But yeah, I I think some people don't realize that um >> yeah, the way people interpret like how they're being talked about and stuff like in especially when you're remote, you're not seeing people's body language and facial expressions, you're like, is this is this guy just being a jerk to me? Like why is why is he doing that? But they might be like, >> you know, their expressions and their tone and stuff, they might not be trying to intend any of that. So >> yeah, exactly. I also think um with being remote um if you use Slack um having you know quick huddles when needed or if you're using Teams um having their uh you know face to face um feature or Zoom all these kind of things it's it's very beneficial to still be in front of people and still being just kind of like we are right now right we we could have technically this podcastish over like text but this is so much better right we get to see facial expressions we get to have real communication. I feel like that's also a huge thing to have in remote. Still still be human first, right? >> Yeah. It's a I feel like it's an undervalued thing and I get it. Like some people are like, "Dude, I just rolled out of bed or like uh I'm going to be I'm going to be totally transparent with you right now. I'm not wearing pants, >> but I can do that, right?" Um I can still be on video and like, you know, but but some people are like, "I don't want to be on camera. I don't want to present myself." And I get that everyone has their their boundaries for that kind of stuff, but um the more people can lean into like >> you know if we can be as present as possible um it can make a huge difference uh for remote teams uh and it there's not always this luxury so I get it but for remote teams if you have the ability to periodically meet in person like if the company supports it like >> that can be such a game changer in terms of people's abilities to work together. Um have you have you run into that kind of thing like or I guess before you guys were in office but um do you have team members that like you've never met like is that kind of a common thing? >> Yeah. So okay so when I joined my company we were around like 400 to 500 people. I want to say we just crossed 5,000. So we um we went public. We um got bought out all that kind of stuff. So, I've been through like a pretty big um transformation that I would say is unique to most people. Um going from three branches in the US to scaling to slightly into Canada and then scaling into Brazil and now we're in India and just kind of like becoming more of a global market from 400 to the I think I truly think we're over 5,000 now. um after we included some of the the other companies and um and then our public company that bought us out, I want to say they're like 50,000 people. So, it's kind of just like there's there's so many people I haven't met, especially if you include our parent now. Um but yeah and I think every time I join a new team there's um a lot of new new faces and we're pretty unique in the standpoint of like so so when I think of like consulting I think of like kind of like two or maybe even three schools of thought of like you are an individual and they are placing you at a company because they need two or three new developers for one year and then after that you're done and then you you go to a new company after that. Um, Willlet Tree kind of flips it on its head a little bit where we do all in-house development. >> So, a company needs a new product built, we'll build it, and then we'll give it back to you. It's more for companies that may not have a strong, you know, technical software engineering level. And we actually do more than that, too. I mean, we're partners with um now with our parent, I want to say we're partners with like, you know, Apple, uh, Google, Microsoft. I think I think we're we're partners with a ton of people. And I think that's also like a school of thought like when you start thinking like Microsoft uses like software engineering consulting companies like yeah like a lot of like almost every company does right and um and I think um what happens is when we start new projects there's always new people to meet there's always new ideas always new companies to work with like we're also very client facing right and I think that's where it really comes into having the I hate using the word soft skills but making sure that you're having obstacles to be able to, you know, integrate with the client, integrate with the new teammates, um being able to have like these kind of conversations, right? And I think it's um it's very important. >> That's a that's a good segue. Soft skills. I also don't like using the word soft skills. It to me it makes it feel like it's a it's like a lesser important thing. I don't know why, but um that's the the word for me doesn't do it. Um and I haven't landed on something I really like. Sometimes they just say people or human skills, but when I say human skills, it almost makes it sound like I'm implying other people aren't human if they don't have those skills. I don't know the I don't know what the good phrase is for it, but uh yeah, >> it's really interesting your your point about Okay, so if you're going to be doing say consulting in this case and working with customers, your your people or human skills or soft skills, whatever you'd like to label them, that skill level needs to be going up. >> Yeah. Right. Because if you're interacting with other people like you know that's it's just going to be requirement. How have you found that that has evolved for you? Like how has your skill level and like your the people skills like how has all that been shaped and shifted uh in your time working with clients and doing kind of like consulting work within a company? >> Yeah. So it has shifted a ton and I think the first level to have a lot of confidence in the soft skills it's because you also have the the technical skills right so a lot of times I think it's nerve-wracking talking about certain things like maybe maybe you're just talking something technical but if you don't have the the technical skills to answer questions that are coming back to you knowing what exactly you're talking about all of a sudden the soft skills kind of drop a little bit because you're you're nervous about the topic that you're getting that's being talked about. The the second point um my soft skills have definitely gotten better. Um the I'd say communication communication has gotten better. I've always been able to like you know talk to people and things like that. I know a lot um some people have like you know nerves with or anxiety with that kind of um thing, but I've always been able to talk to people um talking with clients. So now that I'm at more of a senior level, I talk with more of the client also um with their technical direction. And talking with a client is really a cool opportunity because in some ways that can also be your users, right? And I think a lot of times like you can be developing features or developing a software without actually communicating with the users because that's somebody else's maybe role. Um, and I think it's really cool and really fascinating, um, you know, showing demos to the client, being able to talk to the users, being able to understand more of their business domain, how how excited they are about seeing this application come to life. And it's it's a really cool opportunity and just being more involved with that flow, process after process, product after product, I think always will increase your um, soft skills because once you start doing it, it just becomes natural, right? And you can start being more authentic. I think in the very beginning it's hard I think no matter what you're doing it's hard to be authentic at first and I know that sounds like it sounds like kind of weird to say out loud but like I know like when I started doing um some like online videos and I there's no way my first couple videos were authentic because I was like really trying to memorize like what I wanted to say. I'm staring at a camera which is not authentic on my side but you're trying to show authenticity to the other people, right? Um, and I think just all of this in general, the more you do it, just the better and better you become at it. >> Yeah, there's a like couple of things that I really liked uh as you're kind of navigating that. The the one is that and I hadn't really thought about this, but I think it makes a lot of sense and I was trying to think of my own examples for >> your soft skills and I like to think that I have some level of soft skills. Um, they they almost can get reduced when you're less confident about the thing. So the even so I've been programming for 21 years. I've been in industry for for 12 years and I haven't had a team switch earlier this year now. I've been managing people for uh whatever it is now like 12 years. Um and even even with that and building up communication and soft skills, I have found that being on a new team and feeling less confident about some of the technical things when I have to go explain things, I can tell that like I'm focused uh it's almost like I'm trying to play catchup with like how do I explain this thing properly? And then I can feel like my soft skills like like slowly coming down until I'm like am I even communicating clearly. So I hadn't really thought about it that way, but >> it's interesting. Yeah, you have to you're you're kind of compensating, right? Because >> if I flip that around if someone I'm trying to think of a topic that I would feel very confident talking about. I like building plug-in systems when I'm designing software. So someone was like, I want to talk to about you with uh want to talk about plug-in systems with you. >> I'd be like, sure. like uh I am and this is an area where like I don't want to say I'm an expert but I have a lot of opinions and if people disagree with them like I want to hear and like I'm not even trying to defend my opinions. It's just like I'm happy to talk about all this stuff. So my soft skills in that situation I feel like would be very elevated because I'm not I'm not worried about any other part except immediate conversation. So interesting way to frame that. >> Yeah. Yeah. Yeah. For sure. And that no that's that's that's a really good point. Um and I've noticed that just where I've joined new products or new business domains like I've been on you know a like a business where it's like hey I know what you guys do or I know what you do. This is like now I can easily communicate what we're trying to build. Maybe even throw out like ideas or maybe you know like AI is a big thing right now right? So, how can we integrate maybe, you know, um a chatbot into this kind of application you have or whatever world you're living in? Then there's been products where it's like I have no idea what you're doing, you know, it's like this is like and now I'm getting with the client beforehand trying to structure their their application or talk about architecture and I'm like to to be fair, I don't >> like I don't even understand how this goes with this. How can I create a table or a SQL database for something that I genuinely have no idea like I have no idea how these connect, you know? And it's really just like all right now my soft skills are definitely dwindling. At times you're just like this is kind of embarrassing because I really have no idea. You know you know I agree with your point completely on that. >> It's a it's very it's I don't know if there's other industries quite like this but with software engineering it's so fascinating to me that you can be like you can build up all of your you know software engineering skills over time and then someone drops you into a domain that's different. Like I don't know. I've never I'm trying to think of something. I've never worked in like farming right? So if someone was like, "Yeah, we need something built for farming and agriculture." You might be like, "Okay, I have all of these technical skills, but like the domain is very new to me." And it's like, "Wait a second, like if I don't understand it, like you need to you need to invest some time to understand the domain." And I think that that that goes a long way too. So >> yeah, exactly. the the other thing that you had mentioned and I want to touch on this because I don't I genuinely feel like a lot of software engineers in their entire career don't get a lot of exposure to this and it's it is talking with customers. So we were talking about soft skills and that kind of thing and why that's valuable. But the other aspect of working more closely with customers is that you understand like different timelines and constraints. It's almost like um if you go if you kind of think about software engineering as a bit of a spectrum in in this context of I'm building either stuff at school or side projects there's almost no constraints right with school it's like you might have a deadline but whatever it's kind of a the constraints are pretty minimum but side projects it's like you just kind of build whatever you want right um and the school side I I think what I wanted to hit on is like it's a it's a lot more theoretical a lot of the time but then if you go the exact exact opposite end of the spectrum. It's like software engineering in practice has tons of constraints, tons and sometimes those constraints are very tight deadlines. Uh your priorities are changing. So sometimes you have to be ready for hey we're building this thing but by the way like >> switch gears like you're not building that anymore. How uh what are your thoughts on how being close to customers not just on the soft skill side but from how you approach building things how has that helped you as a software engineer like focus on what is truly important at that point in time? >> Yeah. So it it made me think of like a story that actually happened like last year. So, I'm not sure how much I'm allowed to disclose. Um, but I worked on a fast food ice cream place that gets millions of users and they released an iOS and Android app. Well, for people to download the apps, we were giving away free ice cream cones, right? And so, we would send out >> Yeah. Yeah. Right. So, you get a free ice cream cone, you download the app. It worked great because it shot to number one in the um iTunes store or the app store, but and I was I was the backend engineer on that. Um, >> cool. >> But what we didn't run into, so we were trying to get people to download the app to buy ice cream cones, right? So, we were doing different promotion um emails because we're like, hey, we don't want people to just flood um the restaurant and blow up our application because we don't have like unlimited capacity, right? So, we sent out like a promotion email at like 9:00 a.m. Eastern and then we sent one at like noon Eastern and then like 300 p.m. Eastern being like, "All right, now Pacific time is going to be different and all this kind of stuff." Well, in theory, it makes sense, but in practice, everybody wants an ice cream cone at the exact same time, and that's, you know, after dinner at 6 p.m. or whatever, right? So, it doesn't matter when you send this email, they look at the email. >> Yeah. They look at the email and they're like, "Okay, cool. I'll just hold this until 6:00 p.m. or 7:00 p.m. And then so then we got like a huge flood of um people trying to buy ice cream at 7:00 p.m. Eastern and then 700 p.m. the next time zone and then 7:00 p.m. the next time zone and our application was we were on Azure and our containers were filling up. So we were trying to do like vertical scaling at the same time and it was just cuz our horizontal scaling was completely maxed out. our application was breaking and like all right we need a new plan right and that was like an example of like we probably should have talked with like we we briefly we talked with the client on that but maybe we all should have like talk to a user talked to like more of understanding how this can impact what's going on right so I think when you talk with the user and talk with the client more often you really learn what is important right and knowing what feature to work on because I think it's really fun or really cool to work on a feature that you think is really cool, but if no one's going to use it, it's almost like it should we be working on that, right? What do the users actually want? And there's a saying that I'm not sure if I invented or not. I post it on LinkedIn all the time and it's if you have no users, you have product. >> What? >> I said, "Yeah, just take credit for it. It's okay." >> Yeah. Like I've been saying it now for so long. I'm like, I don't know if it's mine. I think it is, but but it's if you have no users, you have no product, right? And like if you create a new feature that's really cool, but no one uses it, like well, does a feature really exist, right? And um >> yeah, >> and it's it's kind of like um the bear in the woods kind of theory, right? And um >> that's exactly what I was thinking. Yeah. >> Yeah. So, it's it's kind of like that world. So, um working with the user really gives you an idea, gives you like the narrow focus that you need to have a successful product. Yeah, I I like that a lot. I think um my experience uh so my experience is a little bit different now that I'm at Microsoft. Uh I work I've worked on two platform teams since I've been at Microsoft. So the with a platform team, your users are still other engineering teams. So, it's not like I I can't be like, "Oh, we don't have users," but you have to think about things a little bit differently because there's your your users, which are other engineers that you can just, you know, I don't want to say turn to cuz if we're remote, you can't just turn to them, but um you have other engineers that are within the or you can reach out to and have conversations with, but we still have like end users outside the company. But it's kind of platform teams. I worked in digital forensics for 8 years before and that was very much like um you know building a product that truly end users and customers would use like police officers and and law enforcement that kind of thing. So um I did not a couple things I'll touch on here. I didn't have direct access to users. Um now what was very interesting is that the way that the company was set up the feedback loop from users was very close to the engineers which I think really helped. So tech support was always really engaged with us or like sales people would be coming to us and being able to outline problems that users were going through. So we always had like a really good um I feel like a good connection to users. So we had that which I think was beneficial. the company did something that I thought I've never seen this before and I thought it was kind of like a genius move but as the company was scaling they were hiring in basically customers. So they would hire in customers that had other skill sets. So for example uh someone who's uh worked in digital forensics but also in sales. >> So now they have a saleserson that like has digital forensic experience. So now the sales team has this like connection like very close to users or we had product owners or call them like a project manager or a product manager depending on the role um that were also like forensic users at some point in the past. So they started to embed these experts in the teams as you know they had these like hybrid roles. I thought that was a super cool thing. But um the other thing that I'll mention and this is probably more applicable uh for a lot of people is if you have like a a product call them everyone there's so many PM type roles but uh like a when I say product manager it's someone who is basically representing the customer like so that's the role that I think of in this case they're helping prioritize like what things we should be delivering to customers so I'm going to also say product owner in this case but what I think worked really well for us is like we actually put that that emphasis and that importance on that person. So it wasn't just like it's almost like the conversations were like hey like what what do the users want? like we would talk to that person like that was literally their job because it is and I think if you if you step back from that too much and you're kind of just like yeah like as a team we don't really know and you you're not like leaning into that person being like dude you have to be talking to the customers like you you're kind of missing out. So I was very fortunate that our product owners were doing that and when we were stuck on something and we're like which direction should we go we would turn to them and say like what do the users want >> and they either knew like they could think through it or they were like good good point like let me let me go take some action and I'll follow up but it was like we have a user proxy right here. >> Yeah. >> And like we we we do too in that situation. we we have a person who is very very very connected with the client, connected with the um users that know the direction of the product and the software engineer kind of comes in um kind of on how to create it and then create demos and things like that. So no and I and I think that's such an important role too, right? Because you need almost like that proxy person that can gather feedback, gather users, gather client feedback, everything to really make sure that all the resources the company is, you know, using is actually benefiting, you know, most people, right? It's almost like the 8020 rule, just being making sure that, you know, 80% of what you're creating is actually benefiting, you know, majority of people. >> Yeah, that totally makes sense. Uh, and I I want to I'm doing a little time check here because I know we want to get wrapping up, but I I think another thing that we didn't get to touch on and I want to spend a little bit of time if you still got time is you had briefly mentioned to me before we got recording about uh some of your in terms of social media and your journey. It looks a little bit different in terms of how you started creating content and what kind of launched you off. Um, so you had mentioned that you got into course creation and do you want to talk a little little bit about your courses and where people can find them and that kind of stuff? >> Yeah, so co co was a weird year, right? Um I um we me and my uh wife were were in our house. Um, I was working remote at the time and every night we were just um binge watching Survivor and I don't know if anyone's watched Survivor, but they're all like on Paramount and I think we watched like 40 seasons of it during co but at one point I was sitting there and my cousin um was trying to get into computer science and he was texting me questions um about um just different things of how do you build products? he was trying to learn Python at the po at the time just being able to be there help him throughout because he wasn't in person um at school he was so he was in college wasn't in person and trying to learn everything remote so I was there guiding him and talking with him and seeing the new almost like someone that's trying to break into the field seeing how they're thinking how they're trying to learn and it being co so after work every day we had nothing going on but survivor. Um I was like I'm I'm going to try and create a course on this. So I started creating a Python course and then um created fast API course and fast API is a uh framework for Python and um so it kind of got me into that realm and I started creating courses on Udemy and the courses ended up doing fairly well. So then I was like, "All right, cool. I'm I'm going to try and get into YouTube a little bit." And so I started kind of like everything that didn't make sense to go in the course, maybe like oneoff things like how do I implement, you know, Reddus with fast API, how do I implement Reddus with Python or something like that, it it didn't fit in the course of learning Python, but it's something that people wanted. So started kind of creating content um of oneoff stuff on YouTube. So now I'm full um video and then I got into LinkedIn soon after that. So, all my stuff is on Udemy, YouTube, and LinkedIn. All under uh Eric Roby or Coding with Robi. Um, and it's it's been a blast just being able to share knowledge, help people, and uh meet awesome people like Nick right here. So, >> cool. No, it's awesome. It's a it's definitely you kind of said it uh before we started recording, but it's a it's almost like a little bit of an inverse journey, right? I think a lot of people take to social media first, start sharing, and then they go, I'm going to start making courses. Um, and it's it's just really cool that you kind of you literally just saw a need and you were like, I can help with this, and it kind of stemmed from helping someone in the first place. And >> probably the thought process was like, if I do this for this person, I can help other people. So, >> so cool that you kind of just leaned into that and it it took off. So, that's that's awesome. >> Yeah. And it it was a super fun journey because like I and I'm sure you can kind of back this up. When you first get into really any kind of public stuff, whe that's building courses, making YouTube videos, making LinkedIn, you really have no idea what you're doing in the beginning, right? Like when I first started making YouTube, like trying to figure out lighting, trying to figure out um microphones, >> what people even want to talk about, how you're going to record, how you're going to edit, all this kind of stuff. It's it's quite overwhelming. And I I think um for me at least, I got in it at a good time during COVID because I think a lot of people were looking for the internet for resources and um I I had a lot of free time because we weren't doing anything. Um, that was a good time for me to really kind of dive in and um, you should have saw my wife's face when I just kept buying lights and buying microphones and it it was just a funny experience because like I started off I started off cheap and I bought like a really cheap light and a really cheap microphone. I think a lot of people start with this this kind of journey, right? >> I did exactly this by the way, so keep going. Yep. >> Yeah. So, I bought like a really cheap uh mic and a really cheap light and I'm like, you know what? this this is what I'm gonna try. And then I was like, "Man, I kind of sound bad." So, so I bought another mic and I bought a different light and my wife's like, "Wait, you already have a a mic and a light?" I'm like, "Yeah, but this one's better." And then, you know, six months go by and then I buy uh like I'm not using it right now. This is like a web camera. But then I bought like a like a a mirrorless camera and with a with like a lens. And she's like, "Why are you buying that?" I'm like, "Ah, just to just to look better, I think." then you know then you buy a nicer mic and now I have like you know all of the like like if you saw behind what I'm looking at right now there's like three mics there's a key light there's a whole bunch of stuff and uh it it's it's a it's funny to kind of go through that journey and being able to kind of >> it's not just like one day you wake up and you you know you you have a a 100 thousand students on Udemy couple thousand subscribers on YouTube couple thousand subscribers on LinkedIn it's it's definitely a long journey process that you're just kind of figuring stuff out as you go and you just keep creating and you you get a lot of >> Yeah. >> And what's what's interesting too about public posting public is um you you kind of have to have thick skin. You you kind of have to have two things. You have to be kind of delusional thinking that you you can actually like make content that people want to because there's so much noise already, right? And you're like, how am I going to >> Yep. >> And I'm speaking delusional from my standpoint. I'm like, yeah, I'll be able to do this. And then like reflecting I'm like my chances were really small. And then um and then um on the flip side, just being able to post public content and letting other people love your content and then also letting people hate your content and um being able to have thick skin just to kind of brush off um the noise of negative comments from the positive comments of people consuming your content. And I know that was pretty hard. Um, like I like like for example on on Udemy I I think I'm at like 10,000 some reviews and and I have fairly good >> Yay. Thanks. Yeah. So it's about 10%. So 100,000 students, 10,000 plus reviews and you you you get a ton of five stars and you know four stars and you're like yeah this is great and then you get a one star. you're like, "This is worthless." Or you get a one star of whatever and at first it starts really like hitting you. You're like, "How? How?" And you're like, "20 hours of content is worth a one star." Like really? And then you just kind of have to like put that behind you. And you'll see that in LinkedIn comments, you'll see that on YouTube, you'll see that everywhere. And I think um you know, the people who create public content, they really kind of put themselves out there. >> Yeah. The So, thank you for kind of for sharing that. I think that's it's important for people to hear that >> like it it doesn't happen overnight. Like it takes a long time. It takes consistency and it is an evolution like you said, right? >> Uh so same thing on my side. I got camera in front of me with a big light on it. I got two big lights up in the corner. Um did the whole microphone thing. I've had a terrible journey with just like audio equipment. But like all this stuff is over like the past 18 months, right? It's not like I woke up day one and said I'm buying all this stuff. It's going to be top end. I def like even I had lights that were on my wall that when the camera was going they would like strobe like not on purpose but the the way the camera was picking them up they were strobing and I'm like I I can't do this. Like I can't got to get return my cheap Amazon lights. Um >> but all this stuff, right? Um and I think people give up for a couple reasons. One is they start getting the negative comments and they're like I can't deal with that, >> right? They don't have the thick skin to deal with it. And the other thing is that because it takes a long time, they give up on that too. They're like, I don't have the consistency. It's going to take too much effort. Why am I doing this? That's actually I gave up the first time over 10 years ago. I started started blogging and I was like, why am I doing this? Like it's too much work. And so that's why I started again to try and say like you should have just stuck with this. >> Yeah. And and it is a ton of work. I think that's also another uh thing is and and you you you do it like on a you do it on a different scale than I do. You you knock out like two or three YouTube videos a week. You you're posting multiple times a day. You're you're going like like way more than I the capacity that I could do. And um so kudos to you. And I I think what's downplayed is like let's say it's like a 20-minute YouTube video and it's about a certain topic. It takes the individual 20 minutes to watch if they w if they watch the whole thing and then 20 seconds to leave a comment, right? But on the other side there there was um from from the the creator for a 20-minute video. I mean, that takes hours, hours to create. And um and it is it does hit the creator harder than I think a lot of I'm going to say majority of anyone thinks it does. Um because of how much time and effort they put into pretty much doing something for free, right? There's always an idea behind it, but it's it's a lot of it's for free. And um just being able to just >> my dollar a day from YouTube is Yeah, my dollar a day from YouTube is not um it's not sort of making me a millionaire or anything like that. So, >> Right. Right. And that's that's kind of where I am too. Like YouTube doesn't do well. Um my my courses do do well, but um it's more of just like how do you just keep believing in yourself where you it only takes like a couple like people to really be like I love your content to kind of give you that motivation and only one person to kind of ruin it. And you just have to be able to have thick skin to kind of like get past that. And I mean, I remember my first dollar on YouTube and I was like, "Holy crap." And I'm like talking to my wife. I'm like, "I just made a dollar on YouTube and it only took me 150 hours." Like, you know, like like >> Yeah. It's funny when I tell my wife that kind of thing. It's like I exact same thing. I get super excited and there's been times where I'm like, "Oh man, like my if you look at the trend, I'm not I'm not making a dollar anymore. I'm making like a$125 and I'm like this is it's like a 25% improvement. This is so cool. And she's looking at me like so you lock yourself in that little cave and record videos and you're telling me you make a$125 a day and you're excited and I'm like >> yes. >> Yes I am. >> It's it's cool. Like I it's it's really cool to hear like your your kind of journey through that. So thanks for sharing that as well. It's uh it's you know it's extra on top of the software engineering work. It's great that you're able to kind of share back the information and stuff that you've learned because other people can benefit from it. So I will uh I I'll double check with you offline to get links and stuff from you so I can make sure I can post uh in the description and the comments and stuff and people can check out all of your stuff wherever it is. Um but Eric, thank you so much for this conversation. Um anything else that you want to mention before we sign off? Any >> parting words of wisdom for the audience? uh not necessarily wisdom, but um kind of just like a overall just shout out to you, Nick. Uh I think a like dev leader at Devleer um you you're able to just knock out some awesome content and um I mean the the YouTube videos you create on a weekly basis have so much information in them. These podcasts that you do, um I mean this is just with me, but you have so many other people um that you're able to share wisdom with. Um, you're also creating courses, you have blogs, dude, you do everything. And um, you know, shout out to you to just be able to consistently be just in front of people and um, kind of sharing your wisdom, especially from your platform as a uh, you know, an engineering manager at Microsoft. You you have a lot of wisdom to share and a lot of just that title alone kind of, you know, pulls in a lot of, you know, authority and trust. So, just keep it up. If you're watching, Nick, keep it up. He's an awesome guy. And uh that that's my that's my uh ending clause. >> Well, thank you so much for that because like you said a few moments ago, it only takes a couple of people to to give you some some positive feedback for you to be like, "Hell yeah, like I got to keep going." So, thank you. That'll be my my encouragement for the next month at least. So, >> sweet. >> Awesome. Okay. Thanks, Eric. And for folks that are watching, if you enjoyed this, do do what you got to do. The comment, the like, the subscribe. We'll see you next time. Take care. >> Yep. See you.