Practice ANTI-PATTERNS As A Software Engineer?!

today I wanted to talk about what I consider my number one tip for software developers that want to get better at what they're doing now a lot of the time I hear people asking me like what book should I be reading like what courses should I be taking online to be better as a software engineer and a lot of the time like I don't refer to specific courses or specific books that they should read because I have a different thing that I think people should be doing to get them better at software engineering and today actually this example comes from Milan yovanovic who's also a YouTuber if you're watching my channel odds are you're already subscribed to his he's really big on YouTube and he shared something on LinkedIn that I wanted to go over so I'm going to start by sharing that reading through it and then giving some of my perspective on that alright so Milan goes on to say side projects made me a better software engineer I tried to spend 30 to 45 minutes daily hacking away at my side project and I focus on a few specific things software architecture and new libraries and this is the key part that I wanted to talk about right after which he says sometimes I would try to do everything wrong on purpose and this sounds kind of ridiculous but he says software architecture I didn't need new libraries I will never use unnecessary complexity and over engineering this wasn't a waste of time because I was on a mission so I wanted to stop there and kind of reflect on these points and I think one of the key things that I wanted to get across is that to start I think that and you probably if you've seen my other videos like I always say that I think the best way to get better at software development is truly to spend time writing code so a lot of the time you'll hear me talk about things like I don't think like lead code problems are necessarily the best thing to be doing I don't think that just like strictly watching YouTube videos and doing nothing else or just reading books or articles and not actually practice encoding are the way forward I think that you should be focused on trying to build projects but one of the things that I I don't think I focused a lot on that Milan here says in his in his LinkedIn post which is is like I'm doing I'm doing you know like air quotes like bad things on purpose right like I'm over engineering I'm looking at things that I probably will never use and I think that this is really interesting because I've never actually I guess called it out for my own projects but this is something that I absolutely do absolutely have done for many years and I I do think that combining this point with uh you know this emphasis on just kind of focusing on building projects I think that this point about kind of doing the wrong things again using air quotes is not necessarily the wrong things maybe not best practices I think that this is super important because it it almost teaches you like the hard way right and I'm saying the hard way because and I should use air quotes again the hard way it's not actually that it's bad or the wrong thing to do or that it's necessarily hard but I think sometimes we have to learn about like over engineering things or or building things from scratch to truly learn how things work so I'll give you some examples in my own projects where you know I've built like logging infrastructure from the ground up I've built uh TCP messaging from the ground up I've built uh you know uh object serialization to and from Json uh from the ground up like why there's tons of libraries that do this kind of stuff there's so many opportunities for us to leverage code from people who are truly experts in these areas to be able to move forward and make progress on our projects but the point of working on these side projects for me historically has been that it's a playground for learning so I think that there's a fundamental difference between if I were trying to work on projects that I like need to be shipping to customers they're going to be you know paying the bills that kind of stuff uh that's where I would be trying to you know say like best practices right I want to be trying to not write everything from scratch I want to look for popular well-maintained nuget packages to do difficult things that I'm not an expert in I think that would be the right decision in that case but when it comes to some of my own hobby projects where I'm trying to explore and learn I definitely agree with this uh this approach from Milan here um about you know just you're on a mission to go learn about these things and I think that when you start practicing by uh you know sort of following these patterns that might seem like anti-patterns and software development you can actually learn a ton so let's go back to his post and read the rest of what he had to say so my theory was that I would learn valuable lessons and build an instinct of what bad engineering looks like and this is what happened I learned to spot these anti-patterns when they showed up in real projects this helped me make better decisions and improve the quality of the software I built will this work for you I can't say but I'd love to hear your thoughts so yeah I mean it's really hard to tell people like oh like just go do this and you're absolutely gonna have the same experiences that I have um I I certainly couldn't sit here and tell you like this is absolutely what you must do because I think that if you're if you're not truly set on that as a mission like I'm gonna go try these things to learn about them even if it's not really the best practice that you might be potentially reinforcing bad habits but I think for me again I'll just restate it that this has worked really well for me um and I guess one other example I wanted to share that um was uh probably if I look back at some of my code like one of I don't want to say like the worst architectural decision I've ever made but it was a pattern that I wanted to try out that when I look at the the structure of my my solution that I built it's like it feels quite chaotic so for a long time I was quite obsessed with trying to have interfaces for every C sharp class I have and I actually went as far as trying to ensure that I had like an API project with only interfaces in it for every project that I had and this way I like essentially forced myself to always separate um concrete implementations from interfaces of things and when I took this pattern to an extreme and I guess like maybe that's a good way to put it if you see some of my other content or see me talking about things you'll find that sometimes when I'm reflecting on my own experiences I'm talking about essentially taking patterns to an extreme but fully acknowledging that like I'm doing that for a reason it's not what I suggest but when I took this pattern to an extreme just to kind of elaborate um I ended up having like a solution with hundreds of projects I had interfaces and situations where I would only ever have a concrete class because it was like a data transfer object a dto um and that did not warrant an interface like it would never need a different implementation so what ended up happening was that I end up having tons of uh what feels like duplicated code because I'd have an interface for a dto or an interface for a simple class that would never have a different implementation and even when it came time like one of my arguments is like I like having interfaces for unit testing and mocking but there were situations where the classes were so simple that having the interfaces like it wasn't even a good argument even though I fully support that perspective of having interfaces for testability so anyway going through that in one of my personal projects really allowed me to see like when you take something like that pattern to an extreme it becomes completely unwieldy so okay cool does that mean that it was the wrong thing to do does that mean that I should never have interfaces for my classes or I should never attempt to try and break out projects with interfaces no um it just taught me that there's probably a sweet spot where if I reflect on what I was trying to accomplish I didn't have to go as far and on that note I would just say that when I follow this pattern as Milan was saying in his LinkedIn post like I I think that what I notice is that there's always it always feels like there's a sweet spot for taking patterns and designs and architectures to a certain point because when you basically follow it like um religiously right and blindly and you're just like this is the pattern I must do this this is the law you put your you find yourself in situations where like it doesn't feel good but I said it was law so I have to do it and almost all the time um it feels like some pattern or design just starts to break down because it's truly ill-suited in that situation so um I I do think that personally that um again to reflect on this entire post like my my sort of suggestion for people of I think you should be spending time building your own projects I think that absolutely still stands as is one of my top tips for people just to get better and build confidence and and build experience outside of work but the other thing that I would love to tack onto that and I'm going to start trying to do a better job of it thanks to this post is really like you should try to explore um you know different patterns and take things to an extreme just to try it out but do it intentionally do it with the intent of learning where the boundaries of these things are so that you can know how to apply them better in in real projects so I just wanted to share that for today thanks for watching of course if you're if you're not already subscribed to Milan ivanovic's channel uh absolutely do that I'm sure you are if you found my channel so uh he has great content and uh thanks for watching and we'll see you next time