 I've got a few ideas which have been brooding in my brain for the last six months, working on a number of projects with the team that I'm on at NodeSource. This talk is actually not even for you, it's a practice run for me, giving a big spiel to my team. So please bear with me and I hope that it doesn't go too long. I literally just wrote it like while we're doing this and so also forgive the styles because like the CSS for this is that I just wrote that so okay so let's make this full-screen okay so one of the big things which is interesting about the NodeJS community is that it really strives to help you do modular development it's a very different mindset to what you get when you're working with other communities. So people are quite startled by this at first you know they see something like a Node modules tree or they see NPM installing the entire universe just so that you can uppercase the string you know it's pretty it's pretty mad but there's a lot of benefits to this and you know people people love this shit you know because it obeys this whole idea of you know Unix philosophy you know do one thing well single responsibility and there's a thing that the Node culture of extreme modularity so you know the idea is that we're building apps up out of like lots of little pieces it's like you know plugging together Lego blocks and some examples of this where this is like working really well in the community is the level DB community so they've got a modular database so rather than having something like my sequel or Postgres or pouch DB even where it comes with all of the features that you could possibly need it gives you nothing and you just have to add them so it doesn't have select statements it doesn't have anything but in the process you learn a lot about databases I probably talked about this a hundred times but I love level DB modular database works really well there's a similar movement by some guys doing the single stack geo which is kind of like a modular version of 3js I recommend people look into this it's it's a very awesome project and there's lots of good stuff there allows you to you know do anything without any of the constraints of that are baked into 3js there's and out of that has also come the single I think it's called side yes which a lot of the stuff which was originally built for the stack geo stuff ends up being just useful for doing mathematics so they've created this side yes thing but yeah yeah and npm is the enabler here it allows enables us to build applications out of modules you know if you don't have the dependency hell that you end up with in other systems because it allows you to have multiple versions of the same module working at the same time I've got a thing which enables you to do this even more crazily so you can build your entire app out of like little small pieces and no npm that shouldn't be capitalized I'm sorry but npm has their banking on people wanting to build private modules and this thing on npm so when you build things library first but this is all introduction I'm sorry you know it makes things easier to write helps you isolate the problem and you you're generally working with a clean slate you don't have all the crap that's in your application to work with you know you know results in high quality code better documentation better tests it's all like focused but it's not all rosy all these things which I mentioned before don't come for free and I've found that like when I get an idea I'm gonna build a module for that it takes me at least six hours to build a module because you know you build it once and then you think of all these edge cases then you're gonna write documentation that tests you know you'll release the first version it's always wrong you've got to release a new version so even even just for a small module it takes many hours you know and something I've discovered is that there's much of these are out of order but anyway building applications is a very different thing to building libraries so and the problem is that applications usually don't decompose into this decompose compose probably use it interchangeably compose into this sort of tree structure which you get in NPM where you've got sort of one thing which has one responsibility and another thing which has another sort of sub-responsibility with a real world application you have a whole bunch of stuff which is all messy it's disgusting you know this piece needs to know about this thing and you only learned about that at the last minute when the client actually used the website for the first time two years after you started the project so you know it's hard to build apps in that structure a tree structure is awesome but it's it's it's very difficult to actually achieve it in a library at least on the first go about my one second left my god well I'm gonna keep going be very quick this is another problem is everything is broken all of the time so this is a problem with doing things with with a thousand libraries is that you end up with just I spend so long just fixing bugs my life is just bug fixing and this is because it is it's horrible and it's because I'm trying to not be an asshole it's like the the thing I feel like it's my responsibility if I'm going to be using somebody's code and I discover a problem with it it's my responsibility it's like the way I pay the pay the person for giving me the code so I'm gonna at least try to fix the module so that's sort of like my don't be an asshole sort of policy but and a lot of the time yeah I think that there's this is the reason why we end up building over complicated applications and it's usually we think oh I'm gonna build a library to solve some problem because I'm gonna reuse it but how often do you end up building the library and then not even use it once you know this happens to me all of the time pretty much my entire github is just these are things which I thought would be reusable but weren't the problem is premature modularization I think this happens a lot of the time and I think another way of talking about that is yagney which is you aren't going to need it so so often you'll read I read technical books and they've got all these things about like trying to break things up into a single responsibility principle use it use philosophy all this kind of stuff but I feel like they're optimizing for you know having an incompetent team because there are a lot of really bad developers out there but you know in reality I found at least in the teams I've been working in that we have too many chefs there's as opposed to not enough chefs you know they optimize for under engineering as opposed to over engineering and this is something which I've seen a lot of we have too too much engineering you know we often end up building the wrong thing for the right reasons like we've got all of the back you know all of the theory behind it but it ends up being just a waste of time you know when we build things into modules where an OO like encourages you to hide mess hide complexity but I feel like that's not the same as removing the place I'm sorry that's what I'm trying to do and one of the things I've been trying to get my team to do is stop hiding mess in modules just expose it leave it in the file because if it's there and it's messy it's more likely to get cleaned up but if it's broken out and it's put somewhere and nobody looks at it for six months then sure great you know it's a black box it works but then what happens when it doesn't nobody knows how to work it or even the author if you have to code there at least people were constantly scanning past it going oh god that is a horrible piece of code and eventually one day somebody will most likely fix it if it stays in the file so when you modularize increases cognitive overhead like you know who's had to try to figure out what the hell's going on by having to click through a directory directory directory open a file directory so irritating just and you know you open the file has got three lines in it or it's a whole module which does that I've stood up here before and claimed this was a good thing so it's a lot easier to understand what the hell's going on if the code is just a little bit messy so like I found working with legacy code base is sometimes is way easier to get shit done because the codes just it's all there it's not spread out across a thousand modules there's a conversation we had just like last night one one one of the guys who was he wants to make his things into little small files his thing was well I hate scrolling I'm gonna just have a one-function file but the other guy said you know I hate scrolling through all of your modules now we you know we literally have a file a folder this big full of this guy's modules so it's very irritating so the idea is optimized for deletion don't break things out when unless you absolutely need to less codes better make less files make less functions make them longer but make them clean but not too clean because the only constant has changed and there's a high cost to use building the wrong structure as opposed to having no structure at all so keep your code dirty keep it sort of don't make decisions this is the idea if you don't have if you don't point it yet what's the wrong structure you'll often you'll be like oh this thing's cool I can break this thing out and build up that's like what engineers do they want to organize things they want to structure things they want to make things reusable but the point is it almost you're never going to reuse it and not only that you're making it harder to change shit later by by organizing it seems like counterintuitive and it's like it's the opposite of what books will tell you and a lot of you are probably thinking God this guy's this guy's like really offensive he's offending my whole career he's off this is what happens you read these books and you feel like you feel like a hopeless person because when you try to follow the instructions and you try to do things properly try to test driven development you get fired because you didn't get anything done this happened to me plenty of times it's happened to Sebastian I know like this is like these people who work and tried really hard to do the right thing get fired so keep it dirty build them on build them on with first like let the code sit there mature let it be let it like um let let it live for a while until you do to it what let it age yes exactly so and once once something has sort of survived a few you know culling processes then you can break it out and make it into a thing which deserves to live on its own so and yet the further decisions don't make decisions just get simplest thing that'll work that's the end of my talk