Pair Up Or Go Solo? Effective Learning Tips For Software Engineers

Transcript is auto-generated and may contain errors.

Hey folks, I'm on the highway driving to the office. I'm just doing two shorter videos back to back. Um, so the last one was on if you especially for interviews if you need to understand the inner workings of methods that you're using in a framework. So I was trying to elaborate on that and uh this question today is from the same person. they sent it in on Instagram and kind of talking about um if you're building like projects and someone's doing the front end and someone's doing the back end like is this a good um kind of approach for learning? Now, to be totally transparent, uh I don't have the question right in front of me and I might have missed like a more specific part of that, but I'm just going to talk about building projects where people have kind of like segmented what they're working on and uh how that can how that can be helpful and things to look out for like a learning perspective.

So, uh, if that sounds interesting, just a friendly reminder that if you want your questions answered, send them in to Devleer on social media or leave them below in the comments. Comments, your information is public. If you send it in in a message, then I can keep you anonymous if you want to write more information. So, uh, with that said, the framing here is really around if you're trying to get through, you know, trying to build projects, trying to learn, build up experience. um we we have this term that's like a full stack developer, right? So you're able to work on um the user experience, the front end side of an application that people are interacting with, right? If you're thinking about um web applications, that's going to be like the website and what's kind of happening in the browser, right?

And then um the other side of that is kind of like the server generally and that could be things like doing processing that could be uh interacting with the database to save and uh retrieve data. So generally we'll have we'll hear terms like full stack and then people will split that into like front end and backend development. Okay. Um you could make arguments too that like let's pick a different thing al together making video games right you might have uh teams of people that are working on the front end so like the user interface in the video game right they are designing where things are laid out how the um the actual player will navigate um using that stuff if we're talking about mobile sorry in the back end for that would be like the game engine itself um for mobile applications. You might have, you know, the front end being, you could even have this in multiple parts.

You could have a front end and back end on the phone itself, but you could also have a back end that's a server that's doing processing and storing and retrieving data. So, um, there's a lot to cover and even from what I was just walking through, those could look very different across all of those domains or different tech stacks, right? There's like in software development there is just so much stuff and you won't ever know all of it and that's okay because you don't need to know all of it to be a great software developer. So if you're trying to build stuff to learn if we have a couple people working together and they split the work up into front end and back end is this a good approach? Is this a problem? Like what are we what are we trading off here? Um I think it depends on your goals, right?

So the typical software engineering answer is it depends. Uh and the other flavor of that is like context is everything, right? So I think it depends on what your goals are. Um, to give you an example, uh, when I'm building Brand Ghost, which is a, uh, sort of a SAS business that I'm building on the side, it helps me with all of my content posting, scheduling, content creation, um, that I build exactly this way, right? So, I work like almost exclusively in the back end, right? So, it's an ASP.NET core server. I do all of the database interactions. I do any like scheduled jobs and processing all of the APIs that the front end can hit. I do all that stuff. Um the other engineers almost exclusively work on the front end and that means that they can move very effectively through that and I can move very effectively through the back end.

So, what's interesting here is if I were to talk about the amount of efficiency in our setup versus the amount of learning, um, in our setup, I would argue my learning is probably minimized. It's not that I'm not learning things. I'm incorporating new technologies or trying different things out um because I'm building things that either I've uh only built once or twice before in different ways, maybe never before, but so I'm still having some opportunities to pull in some stuff that's new and learn about it. But overall, I'm working in stuff I'm extremely familiar with, right? I'm working in SQL. I'm working in ASP.NET Core. I'm using C. I know all these things. Um so that's all good from an effectiveness perspective but um learning is is more minimized now you could say for the front end guys actually they're using some stuff that is kind of new to them.

So in in general though their learning is again probably less compared to something they're completely uncomfortable with. But I think they are still learning a bunch. It's great that there's two of them on it and their effectiveness like they are quite effective in the front end. One in particular I would say is um I don't know from like a a styling kind of perspective branding I feel like he's got a better eye for it. Um, and the other developer I would say from the tech stack itself is more familiar and um, got more of a knack for like how to uh, either from a user workflow and from like a code uh, design kind of perspective. I think he's got that pretty good. So, they can be very effective. So, our setup in general is more optimized for us being effective to produce things. Now, if you wanted to, you could still go, if you're trying to learn, you could still go set up things that way.

And the reason why you might still want to do that is like for me, I've been programming with these things for many, many years. You might not have done that. You might be brand new to them and you're like, "Well, I want to go build I'm just going to make this up. I want to go build stuff in the front end. I think it would be really cool to learn about these frameworks, get exposure to it, but like in order to have that, we probably need like a server that's going to be able to save and retrieve the data. I don't I don't know how to build that too now. It's overwhelming." So just to make the overwhelming part go away, if you had someone working with you tackling that stuff, that could be a great opportunity to let you focus on the stuff you want to learn.

Right? That's one example. The um sorry, like I said, I'm on a diff or maybe I didn't say that in this video. I'm on a different highway today, so I'm just trying to make sure I know where my exits and stuff are. The um the other nice thing too is like I didn't mention this for the previous example but you almost by default because you have to integrate these things you get exposure to different things right so when we're talking about in our example front end and backend stuff I what's a good way to say this like for me in the back end I'm like oh I have to think about cashing I have to do this and that and they're in some situations like hey by the way the front end like it will not be requesting as regularly as you think because it already has caching.

So, it's not that I don't need to cache, but I get to learn about how the front-end tech stack is handling that kind of stuff, how it keeps a local cache because I'm not aware of it, right? Or the opposite times where I'm assuming it does and it's not. So, uh or you know how how authentication's going to work on the APIs. Like there's there's so many so many little things that I get exposed to just by virtue of like having to integrate. So that might be another reason why like it's still not zero learning and that could be really helpful. Um if you wanted to get like completely wild with it, you could like reverse the roles, right? But this is the thing. It's like what's your goal? Is your goal just to like try and learn something completely new? Cuz if it's just to learn something completely new, I would say like yeah, jump into the deep end, right?

And if you're working with someone else and you have support, like I think that could be really cool. But it's going to be completely new. So it's just it's just about what your goal is, right? So if we would have been building brand ghost um actually I'll give you another example after, but we were building brand ghost and we said, "Hey, like this is for fun and like we just want to try and learn as much as we can." Maybe we would have swapped. They put me in the front end because they can support me, but then I have to go like figure everything out and then they can go build in the back end and they're also very capable in the backend stuff. So they might not learn as much but maybe they pick something that's not C and ASP.NET Core, right?

If you're trying to maximize just exposure to learning different things, you know, getting into the deep end and then having people to go build stuff with, I think can be really helpful. Um, it's nice now we have LLMs and stuff when you're stuck like instead of just being like, I can't find the answer online. I'm stuck now. I'm losing motivation. Um, if you're building in a team, you can go ask people like you can debug with them, right? Like, hey, I'm trying this out. It's not working. They can throw in some ideas, but you can do the same thing with an LLM now, which is awesome. So, it unlocks some some types of debugging like that, which is great. Uh, what else to say about this? Um, oh, I was going to say an example of another project that I've done. This is a few years back.

I've mentioned it in a couple videos. I think I was building a an like a an app with a friend and with it was mostly just for fun. And honestly, I went into it being like, I'm going to try to learn as much as I can. So, I picked something that was familiar. So I was going to build in C and ASP.NET Core, but it was going to be a mobile app. So it was built in Zamarind. So I get iOS and Android. So I was using a framework that I wasn't familiar with. Um, was there something before Zamarind? I can't remember. I know like Maui is the new thing, but there was I feel like there was something before Zamron or I used Zamarind before. My brain is not working. So, I've done some crossplatform.net stuff on phones. Was itnet? I just can't remember. Maybe it was.

Anyway, doesn't matter. Point is, I picked um something that was common and everything else I tried to change. So, I was using Firebase. Uh I was using uh Zamarind, which I, you know, had no experience with. There was a couple other things that we like mixed in. And I was like, I'm picking these things because I don't know them. It's not that I have no experience with databases, but I hadn't used Firebase before, I think. And that was another thing. So Firebase had uh data stores, it had authentication, but the data store after trying it out, I was like this isn't really a good fit. And so I I switched to So I picked yet another technology. So MongoDB, I had basically no experience using MongoDB. So I started building with that. But that whole thing was really centered around being a learning opportunity. and I learned tons.

Um, I didn't learn any of those things like I was an expert in them, but I was, you know, spending a lot of time building in them and I felt very comfortable. So, that was super cool to go through that process. So, I I think you can get a ton of benefit from splitting stuff like that. Um, the other argument though is that you could say, well, if you're going to like what's the opposite of splitting it up? It's either well I guess two things. One do it all yourself or if you're going to partner with someone or a couple people then everyone goes full stack. Um I think you could have success with everyone going full stack as long as you have areas um that people can kind of stick to a little bit more. It's not that people It's kind of a weird one.

It's not that people you know it's bad to be comfortable in more areas of the code. It's more that like if everyone's trying to make similar types of changes, you're kind of like stepping on each other's toes sometimes. So if you can go like full front end backend like like uh refer to it like a vertical slice, right? So you're building a feature, you can do the front end all the way through the back end terms of data storage and stuff like that. If you're able to do that, that's great. But you want to make sure that like not everyone is like doing that at the same time in the same spot. So something to think about. But that's more of like a I don't know like a team dynamic and figuring that kind of stuff out. But again depends what you want. Do you want to get that exposure?

Like do you want to be able to say on your resume like I have full stack experience building stuff, right? What about even because we're talking about it like I was saying backend on like you know the server but like what about the if you're doing like a cloud deployment like what about your CI/CD pipelines? What about your your cloud infrastructure? Right. So I should mention in brand ghost we actually like that's something all of us share none of us I would say like compared to like the frameworks and the languages and stuff we have some expertise across those but for the cloud infrastructure I would say none of us are experts we all we all know how they work we all use them we've all been using them which is great but in terms of expertise I and say like no one's like a guru and they're like man I do this like in my sleep and I've been doing it for 15 years.

Um so we all share that and again that's a really good one where I find I'm still learning lots. There's stuff that I'm there like in Azure cuz that's what we're using. Some stuff I'm very comfortable in Azure and other stuff I'm like oh man like I hope Azure has a thing that can do this. I have to go learn about it and see like um one of the just a real example one of them is a database migration. We have to move our database between subscriptions and I'm like I don't want to have any downtime. So like is that built in? I would like to not like dump the database and then reimpport it. I don't um because then you're going to have potentially downtime. I don't want to do like write replicas.

I just like I don't want to do like dual writing and stuff um in code and I don't even know if in Azure I can set up like with the SQL databases that one's like a primary and it writes to the replicas. I just like I don't know but I think and I have to look into it. This is a great chat GPT question. I said hey chat GPT here's what I want to do. I said, "Does Azure have something like this that minimizes downtime or has no downtime?" And it basically walked through those scenarios. And I think it said there's a service called AMS, Azure, I don't know, migration service or something. I don't know what it stands for, but um this is one of those things like I asked Chad GPT and like walked away from like so I didn't forget. I have to go back to it.

But I think there is something that will work like that. But anyway, that's me getting exposed to things that I have to go learn about. So, I don't think there's a right or a wrong answer in how you want to approach this. I just think that uh the things I would be trying to balance are your effectiveness. So, are you just trying to be very effective in a group and otherwise like how are you maximizing learning? if we translate this. So I I think that answers the question in terms of like I don't know learning getting ready for you know interviews and making sure you're building up skills. Uh when it comes to actual software engineering teams it's interesting because I still have to find a middle ground. Most of the time it leans harder towards like effectiveness, right? People have built up skills in areas they're effective there.

it makes a lot of sense that they're working on the things that they're really good at. However, there's always learning opportunities. There's always growth. There's always derisking, right? If only one person for each like area of expertise, if only one person knew, that's kind of scary, right? That person leaves, they win the lottery and walk away and now no one knows about it. You don't want to be in that spot. So, um, sometimes there's situations where we're like, "Hey, we'll go a little slower on purpose, but longterm it's going to help us." So, we might have someone working in a spot. It's a little bit peripheral, maybe, especially because they're interested. That's like another kind of win. So, you go a little slower, but there's a benefit because they are interested and there's another benefit because you're de-risking with spreading the learning.

So, as an engineering manager, those are like a a layer of things I have to try and balance, which if you're under a lot of pressure, like that kind of stuff falls apart, unfortunately. Right? So, if everything feels like it's on fire, you keep throwing your experts at the fires, right? There's a fire over here, this expert knows that area. Like, get them on it. There's a fire over there. That other expert knows it. Put them on it. The problem with that kind of thing, again, from a it's it's all about learning, right? But from a team's ability to learn and handle this stuff, if you keep putting the experts on the fires that they know about, all of a sudden, you're just like creating more and more silos, right? Only that expert can solve those problems. Why? Because no one else on the team is ever exposed to them.

So sometimes like if you can it's it's a weird thing but if you can find those fires to put out that aren't like that big and you can kind of put someone else into it kind of sucks because you're like ah like there's a fire we got to put it out but you go a little slower. Someone gets to ramp up. Maybe they make a couple mistakes that aren't the end of the world and they come out with like a tremendous learning from it. and you try to sprinkle these things in so that your team is able to overall get better. Um, you know, it's like when I'm on call, I am absolutely not the best person to go solve problems. Like I'm not in the code, you know, I don't know all the details, but that's okay because I get exposure to this stuff. I learn about it.

Um, and then next time I will be better. Now, let's find a parking spot. Let's find a good parking spot where no one's going to hit my door. There's one. Go to the friendly corner. Okay, but I think that's it, folks. I'm just going to back up. If you want to end the video now, I guess you can do that. But maybe there's a secret at the end. Maybe. Probably not, though. Um, am I even in the line? No. This guy can't even can't even park a car. Good thing I don't have my Insta 360 on cuz you'd all be judging me. Okay, parked. That's two videos out of the way. See you folks next time. Take care.