Selection & Implementation of Conventions

[00:00:00]
>> Okay, so when it comes to choosing conventions, how do we choose these conventions? And so there are three main stages when it comes to implementing like these conventions that we wanna pitch. And so the first one is selecting, selecting the convention that your team is going to use.

[00:00:21]
And the very first thing you have to be able to do is define the problem properly. And so what do I mean by this? A lot of times when we talk about things like tabs, spaces and these conventions that make up our ultimate like developer experience across an entire company, things are rarely objective and absolute, right?

[00:00:41]
It's rarely like, well, research has shown that 100% of the time people who use tabs and twos or people use spaces as invitation with two spaces, are 30% more productive than developers user. It's basically almost never that cut and dry. Because the makeup of each team is individualistic, and as a result they need to be considered as such.

[00:01:06]
And so when you're defining a problem, you need to find a problem that matters to your team, that actually will have a measurable impact on what they're going to do. And so as you're selecting these and having those discussions, the key thing I'd like to recommend here is to avoid bike shedding.

[00:01:23]
And so if you're not familiar with bike shedding, it's this general concept that's referred to like basically arguing over something that's small, and spending a lot of time over it even though it doesn't really matter. Okay, and so with the bike shedding right, and like discussed and basically fighting over tabular space in these things.

[00:01:46]
The way to avoid these things there are three primary ways to consider, and the first of which is time constraint voting. And so have those discussions right dedicate an entire hour long meeting to make sure that people can present their points and what they think. But then at the end of it, go ahead and have everyone vote to see what they wanna try.

[00:02:04]
So let's just keep with the tabular spaces indentation example. So if most of the team says you now what, I think two spaces is the way we should go. Then the key here the concept you wanna keep consistent with your team is to disagree and commit. And so it's true some people will still be feel very passionately about tabs.

[00:02:22]
But then what you do now is you do a 3 month trial on this piece. And so this is like the 3 month discussion freeze. And the reason this is important when you're discussing these votes, is because you want to ensure that your team doesn't feel locked in by it, right?

[00:02:36]
That's, I think, one of the hardest things that when it comes to selecting technology is there is this feeling of permanency and conventions definitely have that feeling as well. They're like, once you choose this convention it's over, it's done. And so this is why you see a lot of discussions around conventions.

[00:02:49]
Basically people were like, tried very hard to overturn something cuz they're afraid they'll be stuck with it forever. And so with three months discussion freezes you lower that sort of you create an emotionally safe zone. Where you can say, okay, we're going to try for a timebox period and see how everything feels, and then we can re-examine those discussions later.

[00:03:12]
This is a great way to again make progress towards conventions, especially on these sort of larger applications. We have so many people that it would basically be near impossible to get like a unanimous vote on things. So these are ways you can use to select those conventions for your team.

[00:03:31]
As far as implementation goes, I refer to this a little bit a second ago with the unit testing, but the key here with implementing any convention is to automate it, automate everything. So when you're deciding on conventions for how JavaScript should look, semi colons, indentation, whether or not it should have a trailing comma, all of these things, they should be handled by linters.

[00:03:53]
Because the moment you expect someone to be responsible for this piece, you're basically introducing room for human error. And more importantly, people wanna focus on writing code. And as someone who's gone through this type of pull request before, one of the worst reviews you can get on a PR is just, can you add a dangling comment to that?

[00:04:14]
We use dangling commas in our codebase, right? And so when you automate things, you make it easy for everyone to follow the conventions, while like focusing on the key pieces. And so with eslint, stylelint, markdownlint like whatever it is. These I generally recommend running at the pre commit hook, so that once it's committed, it's already been formatted everything's been added.

[00:04:36]
And this way like developers and so kind of write code the way they would normally do. And then when they commit it to the code base, which is where the standard really needs to be enforced, then at the pre commit hook, it will automatically link to everything. And then we are good to go.

[00:04:52]
Basically, like your pull requests can focus on the things that actually matter going forward. Formatters are another good way of addressing the implementation piece as well. So in this particular case most of you are probably familiar with prettier. So it ensures that everything looks similar in terms of not only indentation.

[00:05:09]
But like how many characters should it go over the line, whether it should add certain stylistic elements. Standardizing these things and including them, for example, as a prettier RC where the configuration is the same for everyone, is also like a great way of at least pushing those standards forward and conventions.

[00:05:29]
So that people can get used to basically working in that environment and basically getting familiarity with it. Image optimization is another popular one. I've worked on code bases where there's no image optimization pipeline. So anytime a developer wants to add an image into their codebase because the designer handed them something, they had to manually go and basically either requested the designer for like the individual sizes they needed.

[00:05:56]
Or they need to go ahead and run it through an optimizer. And that is a waste of time from a pipeline perspective, right? And so if your best practice is hey, we wanna deliver best practice convention. It the convention is that we ensure that the images we deliver to customers are always as small as possible and optimized correctly.

[00:06:18]
Then you wanna automate that image optimization process, because that way someone who's not familiar with the process, right? Who hasn't been working at the company for six months and maybe this is our first time interacting with designers. Like they're not gonna submit a PR with an image that's not optimized without the right break points, which then you have to spend time to then go back and go hey, by the way, this is how we do things.

[00:06:40]
Things like optimization can 100% be automated because you have to run it through a build pipeline. And then as long as you meet the minimum requirements of say, having the image be at like 2X for example. There are tools that allow you to then either resize images correctly and then optimize them accordingly.

[00:06:59]
And so these sorts of things also should be automated. And generators, we talked a little about this earlier, but generators if you can think of it this way is so let me the easiest way here is to show you here. So in the view enterprise boilerplate this is probably the best place to start if you're thinking about doing your own generator.

[00:07:21]
So here you'll see that inside of the view enterprise boilerplate, there are actually basically boilerplate scaffolds for things. So in this case, you'll see that this component is scaffolded in this case, like Chris also uses the script template style sort of order. But on top of that, it actually also goes ahead and make sure is that like the language SASS or the preprocessor SASS is configured and that by default, it's using the CSS modules.

[00:07:51]
And then on top of that, you'll see he's even optimized it to the point where it automatically imports the design variable. So that's not something you have to do. And so this kind of automation is super useful because again, as I mentioned to be here before, you'll see that we actually have here a dynamic test generator.

[00:08:10]
That will go ahead and import the correct component that you're trying to create. And then it will say that it exports a valid component and then it basically has a sample scaffold, that will run this will this will pass basically 100% of time unless you do something horribly wrong.

[00:08:27]
And this just works. And so generators here, basically you can think of generators for anything. As you can see he has end to end tests, whether they're for layouts, modules, utilities. Generators are probably one of the best ways to enforce consistency across your project. Because the moment you need to rely on a developer to copy and paste or create files in a certain way.

[00:08:50]
Basically, when you're at scale that's basically never going to work and you will introduce a lot of human error. The final piece of the automation piece, so for those who don't know VS Code allows you to create, basically code snippets. And so an example of this is Sarah Drasner she has her VS Code, like snippet pack extension, which allows you to basically do things like when you're scaffolding components to basically do like SFC.

[00:09:18]
And then when you hit enter, it'll actually go ahead and like scaffold out, the pieces for you accordingly. And so in VS Code, you can actually create, you can commit like a VS Code folder to your repo that contains like the various snippets. That your teammates can then use to then scaffold out different pieces that you might want different standards on.

[00:09:40]
And so this is another great way of introducing conventions to your team.