Your Software Will Crash And Burn - The Primeagen Says So!

a common thing that I noticed with software Engineers especially coming from a more academic background and trying to get into industry is the focus on like this theoretical Perfection of building software I wanted to create this video to talk through why that's not really the thing to focus on when you're trying to work in the industry hi my name is Nick centino and I'm a principal software engineering manager at Microsoft what I meant in the introduction is not that you should avoid trying to write good code I just mean that focusing on Perfection is not going to be the answer so this video I wanted to go look at someone else who's very popular in the industry creates a ton of amazing content and you probably know who it is and that's the primagen he has this video that talks about building software and basically reaching a point in the life cycle where it's eventually going to have to be Rewritten let's go check it out and I'll give you my thoughts as he's going through it code bases survive because there's one engineer that has the foresight to be able to write code that's at like the 90th the the you know the 90th through the 90th percentile of skill and ability okay this one engineer puts a bunch of stuff on Rails uh then quits because he's like peace out I got better I got I got better money somewhere else leaves and then a bunch of you know then a bunch of the people that are remaining just take this and keep running with it and just to call it out he's going to explain it in just a moment but like you don't always get this right there's it's not always that you had someone that was in that 90 to 99th percentile sometimes in a lot of the time it's mostly average developers right the likelihood of getting someone who is in that really top percentile to go work through and create the beginning of a project it's rare ideally you have people like that they can kick these things off but it's not always the case so this is the sort of like best case scenario but let's keep going till it just absolutely goes off the rails and then things do not work any longer right like this is just software engineering 101 if you don't think this is the case wait until you you find out wait till you do it llms is like being able to take code that's generated right out of the you know right out of the median right and so you're not getting your software developed by this person and putting the rails on here you're actually getting the software and putting the railing on by this person which means that your expected Lifetime on your software is going to be like this you're going to be like oh yeah it's working and boom it's going to just it's going to suck it's just going to suck whereas the other one it still crashes and burns like this guy didn't have all the foresight in the world it's going to go it's going to go and then maybe it crash and that's a really good point too right so he was talking about someone who was kicking off this project right laying the foundation being in this really high-end percentile of software engineers and he said this guy or girl right did not have all of the foresight to go make this perfect he just drew it showing you like it might have gone on longer but at some point they couldn't have predicted everything in the future especially we're building software for today there's a lot of requirements and things that are changing there's going to be technology changes there's all sorts of stuff that makes it basically impossible to predict everything that means at some point in the future your version of Ideal might not be ideal anymore therefore you have this drop off so let's keep going and burns but man that distance right here this is the difference between your startup making it and your startup not making it and we'll pause again because this is a very critical piece of information especially if you are going into a startup or small company if you're going into big Tech you may not feel this as much and that's I think just a side effect of some things in big Tech depending on your team and organization moving a little bit slower you do have the entire support of the organization like if one project fails a lot of the time not the end of the world right there's usually many many many big projects going on in big Tech there's lots of sort of like bet being placed on different things to build out of course you might have something that you're working on that is a very large impact and doesn't work right that could have a big impact but because the amount of projects being done across an entire organization is so many generally one project isn't the end of the world now at a small company so the complete opposite you do not have the luxury of working on so many things in parallel and that means if you have a small company and one of your big projects is not going to be able to land or it's going to crash and burn early or you spend too much time trying to build it like I know the graph is talking about this drop off this catastrophic failure of the project but you could have the same type of issue that if you spend far too long trying to build it and make it perfect before it even launches you're going to have a drop off that's like this it's not because the you know the system that you build crashed and burned it's because the company crashed and burned cuz you didn't ship anything so there is an important Balan a strike here let's keep going okay learn to code take your time become good the best way to learn how to code is to create crappy projects that's it it's that easy create a project scale it until it completely fails create another project scale it until it fails you just need to you need to do that like 15 times because then you see I can write a code I can write codes such that it will work for a while you know maybe it works like maybe you could write code that is right for like six months if you could write code that's right for 6 months that is incredible and we'll pause again the very first part that he said once I unpaused last time was the best way to get good at it is to keep writing code and he specifically calls out crappy code right it's going to be code that fails and that's okay one of the best ways that we learn is through our failures so a lot of the time when I have people coming to me and they're saying hey I'm just getting started like you get this all the time right what's the best book to read like what should I start focusing on what's the best language like a lot of that's going to be really just either how you learn like the language the infrastructure the text stack you pick that's going to be very heavily geared towards the area that you just like to develop in but there's no best when it comes to the sort of best way to learn and the best way to get good at building software as Prime is saying here like you need to be able to put in the time you have to try building things you have to end up failing for yourself to see where these things happen and it sucks because we want to turn to other people and say like you've gone through this tell me all the shortcuts but it doesn't really work like that unfortunately sometimes we have to go through these steps and learn for ourselves now one of the really awesome Parts about doing this is that you can try building stuff out following different architectural patterns you might um you'll hear about over abstracting and maybe not even putting enough abstractions in but generally over abstracting like really bad for doing that in my own hobby projects it's spending too much time trying to plan like oh I'm going to make sure that I can prevent this case in the future right so you go through this a couple times where your stuff is failing and you start to over index the other direction and saying okay well if I I might have to switch the database out like I'm going to make sure that everything I do makes it so I can swap out the database and oh the front end could change let me abstract that you abstract so much that instead of even getting getting the thing delivered you have basically just a ton of abstractions hard to navigate code and you might not have even shipped the thing so there is this balance to strike and going through this sort of process of building things seeing them fail or kind of like reach a point where you're like we can't scale it it's such a good exercise for you to try and reflect and say like what were the things that made that happen and throughout your different experiences start to pick up on the patterns that you want to look out for in the future so let's keep going like honestly that's incredible that means you had enough foresight not to over abstract write the right interface and it just works like that's good that means you're that means you're you're improving if you think you can write code that will never need to be Rewritten you're writing quick sort or you're diluted okay and there you have it right um so I wanted to talk about this too because uh like I have a course on refactoring this is probably a good opport to plug that right so I do have this Dome train course on refactoring but something that I talk about in this course is like when you need to consider rewriting versus refactoring and this is incredibly important because we do have refactoring techniques that let us massage the code to be able to get it to a point where we can keep extending it you know trying to bring in flexibility maybe you wrote something that's really brittle and you need to be able to um you know refactor it so it can be testable all these sorts of things we have stuff that we can keep applying to like massage the code and try to get the lifetime to extend with it but generally if your code base is living for long enough you have paying customers right and the requirements and stuff are changing things are just evolving in the system that you're building at some point it's very likely maybe not all of your entire system or all of the different components have to be Rewritten but certainly parts of it likely will and that's just because it it's basically impossible to like I said earlier to for every possibility in the future especially if you have changing customer requirements and you have to end up supporting your customers right so I wanted to to mention the refactor versus rewrite part because there are ways that you can do like incremental rewrites on portions of things there may be situations where based on the technology stack you pick maybe it's become uh you know obsolete in the sense that the the people supporting it are no longer continuing it you might go oh crap we have a bit of an end of life with our Tex stack we need to start considering rewriting these things because we're not going to have support there's outstanding bugs and the infrastructure for it all that kind of stuff so it can and likely will come up where you need to balance these things so I do try to touch on that in the course but I thought the way that Prime talked about it was important too right so I think the way he phrases it to in my opinion is a little bit more extreme than I might phrase it but I do think it's accurate that you should expect that at some point in time code you've written will be Rewritten right it might be obsolete it might be Rewritten along the way it might be refactored and I like to look at refactoring itself as like a bit of a spectrum right where we can do refactoring that's like not changing Behavior that's typical definition but at some point you start to refactor maybe a little bit too heavily where you're technically starting to rewrite different parts of your code so there is a bit of a sliding scale in my opinion but I do think that it's sort of inevitable it's either that your sof will crash and burn or you will be finding ways to start rewriting pieces of it to keep it alive or rewriting the entire thing if you're interested in seeing how on a new project I go about approaching how much to invest upfront versus later on and deferring some of these design decisions you can check out this video next thanks and I'll see you next time