The Backend DotNet Developer Roadmap

Transcript is auto-generated and may contain errors.

Hey folks, I'm just driving to the office. First full week of the year, which is exciting. Hopefully some people are back in the office already. We're going to go to a submitted question. This one is from a net developer and um I had a bunch of questions come in, which is great. I sent out a newsletter on my uh my main newsletter, which is Devleer Weekly, and um kind of uh posed this question to everyone. if you know if you're focused on New Year's resolutions as a developer, what things are you focused on? What can I try to help with? If I made a video and code commute is of course uh the the way that I do that for everyone. So this net developer is um you know they're they're saying I want to get into or getting prepared for backend development withnet.

So they kind of listed out a whole bunch of different uh focus areas um within sort of the net ecosystem and things to focus on and said like hey is this the right does this feel like the right set of things and um so I don't have the list in front of me as I'm driving because that would be uh ridiculous but I had a look before I started recording and I think they touch on a lot of important things so uh for your reference this is things like uh obviously you highlevel C language fundamentals. I think that uh this kind of thing for any area that you're working in just like practice practice practice right like do you need to know every single language feature in in C like absolutely not uh they called out asyn8 for example though and yes like I think

understanding that is really important um I don't know exactly this person's experience level if you are just getting started async8 might seem like a little bit confusing especially if you're trying to really understand the details of it. Um, but having working knowledge of it and understanding like like what is going on with Async I think is important especially because you're going to be encountering these APIs and you know libraries and things where they're using async. If you don't know what's going on uh that's going to make it really confusing to navigate. So async I think is very important. Um they talk about uh logging, they talk about middleware. So for back-end development, if you're building a web server out, being able to have middleware layered in uh rate limiting, uh also very important. Um on the topic of rate limiting though, this is like a class of of things that we need to think about when we're building web servers, right?

So I'm going to I'm just going through a highle summary of the different things. I'm going to circle back on a bunch of this stuff. I'm just trying to make sure I can say them all out loud so I don't forget the bulk of them. They talk about uh queuing. They talk about uh sort of like job frameworks. So for example, a request comes in. Imagine that you have to um you know someone's uploaded a document somewhere. Now you have to go do some work on that document. Okay. So if you're thinking about a web request like should you sit there and and do all the processing while uh that client is waiting for a response or do you build out your logic such that you can return to the client right away maybe giving it like a job ID um and then that way the response is very fast and as needed the client can go uh look up the job result.

uh maybe you have a separate polling ap or um websocket or like server sent events kind of API for them to work with to get uh real-time updates like how do you build this stuff because yes uh you know super high level you have a web request server can sit there and go do a bunch of stuff um depends on what you're trying to build and the sort of the use cases around it so I think they're thinking about the right pieces in that regard. Um, for logging, they called out something like Sarah log. Uh, I will try when I circle back to touch on packages and things like that because I think that um, this is important to try and think about as you're trying to explore this space more. And then they they also mentioned databases, right? So, I definitely think uh, if you're getting into back-end development, having an understanding of databases is very important.

very popular one uh open- source very performant Postgress right so it's a SQL database um yeah Postgress is very very popular and especially if you're if you're like oh man like I got to try to build stuff with like AI and like I keep hearing about vector DBs and I don't even know what that is but like Postgress has um a vector database uh extension for it uh PG vector I think is what it's called um Postgress can also act like a document database I've not used it that way but uh it has some functionality for that kind of stuff. So Postgress is like if you're like I don't even know where to start like someone pick for me. Postgress there you go done. Um I like when I build stuff personally I don't know why my like my automatic habit is just to go to to MySQL.

I don't know why. Zero reason it's just kind of like out of habit. Uh the software that I'm building right now outside of work called Brand Ghost like we use both a Postgress database and a MySQL database. Um, ideally like I should probably just migrate everything over to Postgress. Um, I'm just in absolutely no rush to do that and really only started using Postgress cuz I wanted the the vector capabilities and uh the hosting that I have for MySQL does not have uh the vector capabilities that I wanted. So anyway, like there you go. Like I'm using two different databases in a in a software solution. So, um, this person touched on a lot of important things. I think like I think they're off to a good start. Um, now I want to spend the rest of this drive kind of talking about different aspects of that.

Uh, I want to make sure I spend some time thinking about like like how do you go get better at these things? Um, and maybe kind of uh elaborate on some of the some of the points. Okay. So, super high level, they called out like they're going to be building ASP.NET Core apps. Sounds great. Um, I think that the way to to navigate this is to build them, right? Uh, yes, there's blog articles. Yes, there's YouTube videos. Yes, you can ask Chad GPT. Yeah, you should probably do all of those things, but I think that um the most important part is that you're actually building a web server. And so then the question is, well, what should I build or like uh how many projects do I have to build before like I, you know, I'm qualified? And like that's not a that's not a question that has like a, you know, one right answer kind of thing.

Um, so I would recommend that if you're trying to explore and practice different parts of working with ASP.NEX on net core that your couple of options are either build a few different things, right? So, you I'm just going to give you a couple random examples, right? Like build a calendar app, build a um build a to-do list, uh like build a couple of simple things so you can build out some different API surfaces, right? And like what does the front end look like? If you're trying to do back-end development and focus just on practicing these technologies, who cares, right? Uh do I think that that's a good strategy long term? No. Uh I think you should be thinking about these things if you want to be, you know, better at developing software.

But if you're trying to practice the backend stuff, like you could think about you could even build a dummy page for it or you could just like use Postman or whatever your favorite tool is and think about, okay, if I had a page and I wanted to show calendar entries, how would I get those, right? Oh, like how do I think about paging for this? Right? So if you're building out a few different web servers like this, you might get exposed to a different API surface that makes you think and practice through different scenarios. Okay, so that's one thing. The other way that you could do it is if you're taking just one application, you could take the same type of approach where you're building out features and different features require, you know, different characteristics for your your API surface. One of the things that I like about um I I'll kind of touch on both pros and cons.

If you're doing a bunch of them, a bunch of little shallow applications, um, that might give you some good breadth of different topics without having to come up with a really convoluted system. The things that you're building, to be honest, they don't really matter. You're not trying to sell these things. So, even if you're like, I'm going to build a calendar app that lets me process documents, like, sure, go like, go do it when it doesn't actually matter. Um, but sometimes conceptually you might be like, I want to um I want I want to focus on my calendar app or I want to focus on my to-do list app or whatever it is. And it just makes it easier for you to rationalize. Um, so I like different apps give you a different surface area. Maybe it's easier to think through. You could do one kind of Uber app.

Um, and one of the things that I like about that is that, uh, if you can get past this mental barrier of like this is a really weird app, like who would use this? One of the nice things is that you're you're going to have a a more and more complicated codebase that you're working in. And there's other unique, interesting challenges that you can practice through doing that, right? Okay, I've seen this pattern come up five times now. Hm, maybe I should do something about that. Right? I have five different APIs that all do this one thing. Or I've built, you know, this similar type of API three times, but now that I'm doing it the fourth time, I just realized that like there's maybe a better way to do that. Like, okay, do you want to talk about versioning your APIs? Like, do you like are you just going to go blast them away?

There's just unique interesting opportunities to practice actually working in a codebase. So, tying that back to one of this person's other points around fundamentals, I think that just literally building is such a good way to practice that kind of stuff. And then what I would recommend is like as you're getting stuck, so you're like, "Okay, I've built it three ways, fourth time. I think there's a better way. I'm going to try it out." You might go, I don't know now, though. Like, now that I'm seeing this new way, you're kind of unlocking some different ways of thinking about it. Maybe that's when you go check a tutorial out, a YouTube video, you go ask ChatGpt, Gemini, whatever you want. Like, hey, like I'm building this thing, like, give me some uh, you know, give me five different approaches with pros and cons and uh, and a simple explanation, right?

Maybe that's when you start exploring these things. Um, but I I do recommend that like getting a little bit lost in the sauce and trying to to kind of get a little bit stuck and get your way out is like it's such a good way to practice and learn this stuff. Okay, it feels very slow. You're going to be like, "Oh man, like I see these people online that say they're releasing like 10 apps in a weekend and like I can't even finish my my stupid calendar app." And it's like I don't know, man. Like for some of the people that say they're cranking things out that have never actually programmed before, do they like what's your goal? Are you trying to to rush to the finish line of like how do I go sell things as fast as possible or are you trying to say like I want to build a career as a software developer building systems and actually understand what's up?

Both of those paths can I mean they can start very differently and converge. So, I'm not saying they're mutually exclusive, but personally, I would rather spend time learning the stuff and applying it uh versus trying to to rush ahead and then trying to catch up in your understanding. That's my personal take. This channel is all about my experiences and and my perspective. Uh and I try to balance it out, right? So, just being transparent with you, okay? So, practice, practice, practice. Um either across a few different apps or an Uber app. But let's talk about now like okay well now you got to introduce logging right you want logging in your application you want middleware um like you you start going okay well do I am I building my own logger like the answer is probably not although depending on how much you want to dive into like understanding mechanics behind things why not you could go build your own logger But that's going to teach you very different things, right?

Like I think that it's important that when you're playing around practicing building software to try and learn that you acknowledge that you are trying to learn and you acknowledge what your goals are with doing it. So if you're like, I know that I need logging in my web application. I know that's good practice. I should try integrating that. Okay, that's one goal is to go integrate logging. But what's the second goal maybe, right? Is like how do I go familiarize myself with popular packages? That's probably what I'll be using. Um, or maybe you're like, I want to really understand how, you know, how logging works. So maybe you do a deep dive and you go build your own logger. And you're like, oh, this is so simple. I just open up a file and keep appending. And then, you know, then you're like, wait a second.

Like, how do I roll over logs? How do I uh like what's log retention look like? How do I uh optimize for performance? Like how do I have different syncs for where I'm logging to? Like then you start to go, oh crap, like there's so much I can do here and you can keep going down that rabbit hole to learn and play or you back out and you go, yeah, no, like that was cool. I'm going to go use Sarah log. I'm going to go use log fnet. I'm going to go use whatever. Okay. So, um, Serogg is a very very popular structured logging uh, library. I use Serogg. I really like it. Um, Sarah log has different what what's called syncs where you can log to different destinations. So, you can do like a rolling file appender do console, you can do uh, you know, app insights uh, graphana uh, through Loki like so you can do all all this stuff.

You can have multiple syncs um all through Sarah log. Uh I think it's great. Really like using it. It's not the only library though. So one of the things that I want to touch on, it's not specific to logging. This is going to be applicable across your job framework that you're going to go pick across uh when you're writing. I forgot this person mentioned testing. Apologies. Testing's like incredibly important. Uh so like what testing framework are you going to go use? Right? There's so many options available to us which is great. But what I encourage you to do and this is good software engineering practice in general is like pros and cons analysis. If you don't give a and you're just trying to get the answer quick and get to the finish line faster like I will tell you xunit sarog you're going to you

like you know uh man what's the I like using quartz so I would just tell you quartz for your job framework but there's uh I can't think of the other one there's ticker Q like there's there's there's different things so like instead of just going on the internet and being Like, okay, like what is the what's the popular YouTuber say? Um, like why are they saying that? Like, why are they saying like, "Hey, you should move from XUnit over to TUnit, right? Everyone's been using XUnit for years and years and years. Like, why T-Unit all of a sudden? Is it just because YouTubers are trying to get attention to their channel? Maybe." But if you read a little bit more, T-Unit behaves differently. it's not using reflection like it's using source generators more. Okay, so some really interesting things. Um, so like going and understanding the pros and cons and the trade-offs I think is incredibly important.

Now at the end of the day based on what we're building right now with these, you know, kind of learner apps to go explore things doesn't really matter. Like you're not going to pick wrong. It's not like, you know, you picked um, you know, you already started and you heard me say uh, MySQL and Postgress earlier and you're like, "Ah, shit." Like, I started using SQLite because I didn't want to go run a server for my database. There's nothing wrong with that at all, right? Like it's that's not a wrong decision. You have a database. It's SQL based. You're going to go work with a database. It would be really interesting to see later if you can swap out the database and how it performs. But like you're not going to make the wrong decision going through this. So all of these are just opportunities to practice.

And that's why I wanted to say one such opportunity for practice is actually looking at pros and cons of packages. Right? I'm going to make this up and I don't have stats on it, but I was giving an example between XUnit and Tunit. Okay? So XUnit has been around for ages. T-Unit's much newer. Um what if I'm just again making it up. What if we looked at the XUnit repository and it's like it hasn't had a commit to it in 3 years but um but everyone's using it. Like you might go, "Hey, I don't know, man. Like it doesn't seem like it's being maintained. Maybe I should go to TUnit." or the inverse. Maybe XUnit's been around for forever and it's getting commits constantly and you heard that popular YouTuber say T-Unit and you look at the T-Unit repository and you're like, man, there hasn't been a commit here in like, you know, a year and it's only a year and a half old.

Like, was this just noise? Now, neither of those things are true, by the way. I'm just giving you an example. like you might want to go make decisions based on your analysis. So I think you should practice that. Um testing wise it's a very man so I have so much to say on testing. Um where to even start? So I think one thing that I would like to encourage people to think through when it comes to testing because there's a couple things. Um, one is that there isn't like only one way to test stuff. So you'll hear like I I would say like going back years now like you know pure unit tests like you need this kind of stuff you have to have it. that's entirely shifted to people being like, "Oh, you should never mock anything." And like, you know, if you have a if it's not like a functional test, like it's wrong.

And like the reality is in software engineering and especially with social media layered in, you're always going to get polarizing opposites. Okay? So, just so you understand this a little bit better when you're trying to read things online, the stuff that performs the best, that gets the most engagement, that gets the most eyes on it, which is what people are striving for when they publish material online, is polarizing. The stuff that gets the least amount of engagement and discussion is the stuff that sits in the middle. It's not exciting. You don't get people debating things. You don't get conversation. Um, you don't get people that are championing it or arguing against it. You get people that are like, "Yeah, kind kind of makes sense." Somewhere in the middle, probably where, you know, most truths lie. So, you will often see that's completely polarizing.

And the challenge is that if you're only seeing the polarizing from one side, you might be very biased to thinking that is the way that it goes and that's how it has to be. So I really want to encourage you to especially like when it comes to testing and stuff like that, there isn't like one way. Okay, so that's point number one. Uh you know I I would say in software engineering in general like always try to look at different sides to things. Oh my god. How do we get in here? Please. Thank you very much. Person that's in front of me is uh not very confident with merging. So, they pull ahead a little bit and then there's lots of room, but they don't know how to to merge in. I guess they don't know the size of their vehicle and stuff like that, which is okay.

Um, so yeah, not just one way to test and um what was the other thing I wanted to say? Oh, I I think I I wanted to say that there's different perspectives on that that are polarizing. And then the next part is like the reality is for testing like oh this sorry one of the the pieces of feedback that I often hear from people uh especially when testing is more of an afterthought because you're newer to building software and a lot of the time you know we build stuff and we go oh finally it works and then someone's like yeah but you should test it and you're like h what does that mean like how does that work? uh when you haven't built software that um that you intended to test and testing is an afterthought. You'll often find um that it feels like you almost have to rewrite all of your software to make it testable.

Okay? And that's not a guarantee or a rule. I'm just saying like it's it's a pretty common thing and it's because when you're trying to think about how to make things testable, the more that you practice and have experience writing tests, the more times you'll see like, oh, I really want to like exercise this part of the code, but like to do that, I have to go like exercise like 40 other classes just to get to this little bit. So then you're like, okay, like do I go rewrite all of this stuff? Do I cheat and like expose this one little thing for test even though no one else should see it? And like you you start to have to come up with compromises. So you'll see lots of these things. And I just want to encourage you that if you're newer to this and you want to practice uh with testing and get better at it is like write more tests more frequently.

And then think about the challenges that you're encountering when you're trying to write tests and then how would like the next time you go to build stuff, how would you go build it differently or could you go look at your code and refactor it so that it can be tested more effectively? And if you have more complicated systems and you're like, "Oh, I really want to refactor it." Can you do that safely without tests? Right? Like, so you have to like testing is a whole thing. And I think that the more time you spend doing it, the more um the more of these situations you'll learn about, you can actually like improve significantly. But in the beginning especially, I think a lot of people get frustrated with testing because it feels like an afterthought and then it feels like you have to go rewrite everything and then you're like, well, I don't want to write tests then because anytime I have to write tests, it's doubling my work.

Like it should not have to. You'll learn patterns and practices so that you can write code that is testable. Do you need to test every single thing? I'm not going to tell you that. I don't think that makes sense personally. If you want to, that's fine. But I think having code that you write where the maj most of the time it is highly testable I think is important. um database stuff. We touched on some different um some different database buzzwords, right? So, you know, some uh some different providers that you can use in different database engines. Most I actually don't have stats on this. I'm assuming most .NET developers use Entity Framework Core. Uh it is what's called an OM, an object relational mapper. And the idea behind that is that you don't have to think about writing SQL queries. I do think that it's really important as a backend engineer that you spend time writing some SQL understanding it because I think that that's just really beneficial for understanding how these things work.

But a lot of developers inn net ecosystems will use entity framework core and the the primary reason for that or one of them is that you can think about you know your data access uh in like a C native way right you're not you're not writing SQL me personally this goes back to like different ways to doing things right me personally I actually don't like that I actually prefer that when I'm thinking about accessing data that I do want to think about it with the the database technology in mind. So I I personally like using repository patterns and I like having my queries. So it's not that there's you know only one right way. There's preferences but I'm not going to sit here and tell you oh Entity Framework Core is bad or the way that I'm doing it is the only way to do it.

They're just different ways. And if I were working in a team and the preference was like we should use Entity Framework Core, I think that's fine. I'm not going to go die on that hill. It's just not my personal choice. So I I would recommend uh exploring Entity Framework Core, understanding how that works. I would not replace your learning of how uh SQL works and you know practicing queries and things like that. uh I wouldn't replace that. I would do both. Um but when it comes time to like writing C code that integrates with your database, I would say it's fine to focus on just entity framework core. Uh as long as you're not ignoring learning about SQL. Uh yeah, databases, there's a lot um a lot to be said about databases. Um, one of the one of the things that's not even .NET related at all is like how do you structure your data in a database, right?

So, as a regardless like this person wants to be a backend uh developer, they you know they're talking about the at stack. But like regardless of your of your stack, if you're a back-end developer, you're almost guaranteed to be working with a database at some level. Um, and if that's the case, I think that, you know, getting exposure to databases is good. I think understanding how you write schemas, uh, is very important. Like what happens if you need like it's going to happen. Your schema is going to have to change at some point. Um, because I hate to break it to you. I don't care how much planning you do up front probably can't predict everything in the future and at some point you might go a we should record this other field or how we're recording this field already isn't quite right we need

to record it in a different way if your schema needs to change how do you approach that what does that look like right so I think understanding some of these sort of fundamentals for databases I think is important how do indexes work how do you optimize queries right there is so much on databases alone that aren't .NET specific. What I think is very interesting though is that if you're going down the entity framework core path, like you should probably understand some of those considerations at the SQL level and how they translate in Entity Framework Core, right? So, for example, an index allows you to not have to do what's called a full table scan. I'm going to oversimplify this. And so, it's a way more optimized way to look up information. Okay? Instead of going through every single record one by one, uh you have a more optimized way of doing that.

Okay? So, how do you get an index in entity framework core? Right? you just made your records like which one's the index? Can you have multiple indices? Can you do compound indices? Like how do you do that? And if you're not familiar with the SQL concepts, you might not even know that this is a thing. So I I encourage you to kind of look at uh both sides of this. But as I pull into work here, I think this person was on the right track uh for the person that wrote this in. I think your list is a very good starting point. Um, I just encourage you to kind of like, you know, practice the things that you're talking about. I think that it's important that you kind of, uh, look at variations of things. Oh man, this guy's flying in here.

And then that will give you this opportunity to kind of do like a pros and cons analysis along the way cuz uh when you're building real software and real systems, that's going to be a big part of what you're doing. So, thank you so much for writing that one in. I hope that was helpful. Uh and a friendly reminder for folks. Uh if you got questions, leave them in the comments. You can go to codecommute.com, submit questions anonymously. You can message Devleer on social media. And this one was inspired from a newsletter article I sent out at devleader weekly which is just at weekly.devleer.ca. It's a, as you might guess, a weekly newsletter. If you don't want to subscribe to it, that's totally cool cuz I get it. We don't want more email spam. That's fine. You can go check it out though. I put it out every weekend.

And if you want to see what topics I live stream about on Mondays uh on my other YouTube channel, which is the Dev Leader Podcast, um you can check that out. And thanks so much. I'll see you in the next one.