Core Principles of Enterprise Code

[00:00:00]
>> All right, this is it, this is the final stretch. We're here and I really want you to leave off with this workshop with three core principles that really make up what production grade apps basically entail. And so the first principle is that we impact over intent, so this is related to our Pareto principle from understanding what problem are we actually trying to solve?

[00:00:34]
And we've covered a lot of different techniques, we've talked a lot about different areas of view application that can impact and solve certain problems. But as you're looking at production level applications, the key thing here is figuring out what kind of problem you want or need to solve.

[00:00:52]
And that should be what guides basically, the implementation or the things you're researching and trying to do. So a lot of times, for example, a great example of this is performance, performance is a buzzword that a lot of people use. And so they will a lot of times go out of their way to delete some lines of code or optimize the whitespace in a way that feels productive, right?

[00:01:19]
And the intent is good, you want to ship smaller bundles. But at the end of the day, this is why the impact is more important than intent, because what you really should be doing is for something like performance, you should have a baseline metric as far as ping times, actual delivery size, like ping to render times.

[00:01:37]
You should have a baseline of metrics, and then figure out what can actually shave off performance from that. Because otherwise, if you're simply just doing things for the sake of it, right? For the sake of like, this feels like we're improving performance because we've now prevented an import on this one module.

[00:01:55]
But guess what? As far as the ultimate impact, it doesn't really do anything for performance, then we've spent time on the wrong piece. And so when it comes to this, the other thing that to keep in mind is a lot of times in tech, we talk a lot about the 10x developer, right?

[00:02:11]
And everyone likes to say, this is a myth. And I think the key thing to remember at the tech developer is not so much about you writing 10 times more code, but really is about helping to lift other developers up. So let like enabling 10 other developers to work faster, this is I think where we need to shift this mentality and why when it comes to conventions and enterprise great apps, the key question here is scalability.

[00:02:37]
Because if you can spend time to solve a problem, that makes it easier for x number of developers to ship faster, you have basically achieved that 10x effect. And this is why, as we mature as engineers and understand how we can best provide value to our clients, or whether to the company we're working for, this is the key.

[00:03:00]
It's understand what matters to them and how we can best address those problems and make those things a reality faster. And, I've talked about this multiple times and repeated it, but, I think this is worth emphasizing and it's that context is everything. A lot of these proven patterns we've talked about have caveats, there's a reason why basically everything that we've talked about has pros and cons.

[00:03:25]
Because, if there's anything I'd want you all to take away from this, it's that ,when you're choosing the technique and what you're trying to do, you need to understand why, and you don't understand what you're dealing with. And so that is ultimately the the time that we want to spend, so reading documentation as far as like, why certain things were designed or how they work, and trying to figure out the caveats, can be extremely useful in making the correct decision, that will then correlate to what we talked about earlier as far as impact.

[00:03:57]
Because if you can figure out for example, a component design pattern that solves your company's problem in a reusable way, that's gonna be huge. That's completely worth the time that you would invest, but it's important for you to understand the context in which you're making those decisions. So similarly for example, let's say the props experiment that we did, right?

[00:04:18]
Kind of tongue in cheek and it's funny to see basically say that okay, if you have too many props just use slots, and that's like a good rule of thumb. But, for example, if your company is creating its own component library, for example, this rule sort of falls off the wayside a little bit because, it doesn't necessarily mean that having a long props dictionary is a bad thing, right?

[00:04:43]
I talked about it for the most part, it is, but there are context in which if they help to enforce standards in a way that help your company move forward, then 100% break that rule and make components complex with lots of different props, because you want to constrain them to certain types and certain values.

[00:05:03]
If you look at component libraries like Vuetify for example, this is the reason why on their docks they have a giant table of different props and different slots that you can access because they need to allow you to customize things in a way that like still follows Google design specs accordingly, but then allows you to escape things in slots in a different way.

[00:05:24]
And so knowing when to break the rule is really critical to creating these production level apps. And I set it at the beginning, but I wanna end on this principle is that, all code is compromised. And so keep that in mind as you make decisions for your apps, use different techniques or try different methodologies.

[00:05:45]
And know that, even things that seem like they're perfect, definitely have their drawbacks. And it's important to always question it at this level, so that you can then make the best decision for your team and company moving forward.