Organizing Your Code

[00:00:00]
>> So the next thing I wanted to get into was organizing your code. And this is something that people ask me a lot, particularly in my react courses, how do you organize your code? It's kind of like an existential problem that developers always have. There's the saying that naming your variables is really hard, but I also think along those lines, organizing your code is very difficult.

[00:00:22]
So there is an endless ocean of good ways to organize your code. They all have some sort of trade off one versus another, some favor searchability, some favor discoverability, some favor being understandable from a file explorer. And I have no strong preference one way or the other towards it because they're all well-intentioned and they all eventually fall apart.

[00:00:46]
And I'm kind of a pessimist when it comes to this, everyone starts out with great intentions, we're gonna organize it this way and everything's gonna work. And people are always gonna put their files in this format in this way, and then it never works. And the reason why is if you can't automate it, it's not gonna get enforced.

[00:01:01]
It goes back to that thing I was telling you before, unless you can force your code to not compile unless it's organized a certain way, it's just always going to drift. Even the best code bases I've worked on, the Netflix codebase was probably the cleanest, best kept code that I've ever seen, and it was still it just an enormous mess.

[00:01:20]
It was so hard to find things just cuz it's a big code base and big code bases are inherently hard. And someone's gonna send me a message afterwards like Brian, I have the best organize code and it's 30 years old and it's older than you and it can blah blah, blah.

[00:01:34]
Fine, okay, I believe you. Maybe the common denominator is me and I haven't worked on a code base that's great. I don't know, you can tell me. Anyway, yeah, in here I said it just ends up being a junk drawer, right? Everyone has their junk drawer and they organize it once every spring cleaning, and then two weeks later it's just back in total disarray.

[00:01:58]
So that's kinda how I feel about code bases. But I wanna talk about my theory behind how I try to organize my code and why, and all the benefits thereof. So I optimize for deleteability, and I actually stole this from another friend of mine who has taught at Frontend Masters, is Ryan Florence.

[00:02:20]
I heard him say this in a workshop that he optimizes for deleteability, and that just really stuck with me. And people are like why would you optimize your code to be deleted? Well, let me kind of explain a little bit more what I mean. All of us that have worked on really large code bases know that there's a lot of dead code in there.

[00:02:39]
Either code that doesn't get used that's inside of a file or just entire directories or entire files that were written, well-intentioned. And then we migrated forward or we fixed a bug, and that code ends up being dead, right? And dead code is the enemy of trying to understand a code base.

[00:02:57]
So if I'm reading through a code base and I see a bunch of code, I can't inherently tell is this being used, is this not being used? And so if you optimize your code for deleteability, that as soon as something is finished, is no longer being used, you can delete it.

[00:03:13]
That's going to make your code base inherently more readable because there's less code, right? Less code is less bugs. And the other thing is, particularly as JavaScript front end developers, we're very sensitive to code bundle size. So if you're including dead code in your bundle that goes down to the end user, that's a cardinal sin because you're wasting bandwidth for no use to you or to your user, right?

[00:03:37]
It's just bad all the way around. So I optimize for deletability, that as soon as something is finished, it's easily deleted. And the nice thing about that, in order for something to be deletable, it has to be modular, and so it kind of forces you into some good practices.

[00:03:51]
Cuz if I wanna be able to rip something out and put something new in, it has to be well-defined of how the pieces fit together. If it's this spaghetti code that goes everywhere, then that sucks, right? You're not gonna end up with very good code at the end of the day, and it's not gonna be very deletable.

[00:04:07]
Here we are, this is kind of my thought. I try and put a things kind of organized into directories. I get accused of putting too many directories into projects, but I think that's the trade off, right? A lot of directories, a lot of nesting, but you end up with kind of, hey, we're using this module but this module has all of its tests in the same directory, all of its CSS, all of its JavaScript and it's all in one folder.

[00:04:30]
And then once I'm done with it, just delete the directory and everything goes with it, that's kind of my mantra here. And I tried to do that with this project a little bit, it ended up being actually less useful. So I actually kind of redid the project back into kind of a more monolithic kind of state.

[00:04:48]
So I actually don't really follow it too much in this kind of organizing code, but I wanted to talk about it because people wanted to know. All of these rules and theories and things that I'm throwing out at you right now, they're just that. They're their guidelines, their theories, and if it doesn't make sense in the projects that you're doing, then don't follow them.

[00:05:06]
All of this is just guidelines and thought processes. So actually, I'm telling you all these things and then I don't follow them, and that's kinda a lesson in don't be such an idealogue to follow rules just because the rules. Always be thinking about always making the trade offs in your head.

[00:05:22]
And if it doesn't make sense to follow one of the rules, then don't follow the rules.