Hasty Treat - Getting Buy-in for a Tool Like Prettier From Your Team

Monday. Monday. Monday.

Open wide dev fans. Get ready to stuff your face with JavaScript, CSS, Node modules, barbecue tips, get workflows, breakdancing, soft skill, web development, the hastiest, the craziest, the tastiest web development treats coming in hot. Here is Wes Barracuda Bos and Scott El Toro Loco Tolinski.

Welcome to Syntax ESLint this Monday hasty treat.

We're gonna be talking all about how to get buy in for a tool from your team. There's all sorts of things that we present to our team, and we say, I'm so excited about this new thing. This thing is going to be great. And then you get these looks from your team, and they say, I don't want to do that. So this is gonna be talking about how to sell developers on the tools that you should be using in your tool chain, where everybody can get a ton of benefit out of them. And the, the one that we're gonna be talking specifically about in this is Prettier, but I think this advice will apply to a lot of things. So my name is Scott Tolinski. And as always, I'm joined by my awesome cohost, Wes Bos.

Oh, very kind of you. Thank you, Scott. You're awesome cohost too. Thank you. I appreciate that. This episode is sponsored by an awesome sponsor, and that's LogRocket. Now LogRocket is the error and exception handling service that allows you to see how your errors happen. And what I mean by that is they give you a session replay video that is scrubbable with the network tab and error logs and all those things that we like to use when we're actually debugging ourselves.

It's really cool. It's so fantastic because it's the tools that we use to debug, but it's actually a replay of somebody else causing the problem. It's unbelievable. One of those things you're gonna have to see to believe, and that's at logrocket.com.

And, it looks like there's some interesting new developments at logrocket.com.

They have this new LogRocket on premise, which is run LogRocket in AWS, Azure, or your own environment or LogRocket cloud.

Use our hosted solution, which is the version that we've been, you know, advertising here ESLint Syntax for a little while now. So they now have a look looks like it on premise hosted version where you can host it Vercel, or you can continue to use the one, that is hosted with them. So you're gonna wanna head on over to logrocket.comforward/syntax and get 14 days for free to see the magic of LogRocket.

So, Wes, I know this question came ESLint you from an email, and it was a good enough email that you said, hold the phone. We gotta make this into our our next, hasty treat here. So I'm interested in it maybe you giving me a little bit more background on this, and then we can dive into this subject.

Yes. So the question came out in email, and I thought, like, this is this is a great question. So it was. I wrote a long message to our architect want that, and Prettier doesn't always format the way I like it.

I'm want that in Prettier. It doesn't always format the way I like it. I don't wanna enforce that on other devs. So Prettier is a tool that will take your code and format it based on what it thinks is best. And the reason why we say that is because Prettier doesn't have a ton of options.

There are some minor options, like you can use a single or double quotes or there's a couple other ones. I forget what they are. But, generally, Prettier just just works for you.

And it's awesome because you, as a developer, you don't need to worry about properly formatting or indenting or remembering the style of of how your team codes or or any of that stuff. You just kinda you should see me. I'm just a mess when I code now, and then I just hit save, and it just formats it all all nicely. So the question goes on to say, this sucks because I know our code base could benefit from it so much right now. I visit the project and the code is not spaced out, and that makes it hard to read quickly for me. Lots of the React code is bunched up with no spacing.

It is a mess. That's one thing in React world.

Prettier will automatically indent and put quotes around the things that that Node it even with, like, spaces. If there's a space that you you need there, React will automatically do the stupid React space, which is curly brackets quote space.

Yeah. Right. I hate that. I hate it. Me too. I hate it. It is a mess for me, especially because I am very organized. If this is with your situation and you know of a new tool or standard, something that can help a lot, and it is Scott Node, do you just give up? I don't know how to respond to this because I'm the only dev who ever proposed this at my company, and I just started here. So we hear this a lot. I'm a new dev at a company, and they're not using x, y, or z, which is clearly way better. What do I do, in in that case? So there's a lot to unpack here. First of all, I don't think that any senior devs like junior developers, especially new to the company developers coming in and and starting to say, like, why aren't you using this thing? It's not as good.

Like, I I think everybody has a little bit anxiety about becoming out of date, especially in JavaScript land. And if some whippersnapper comes in and starts asking, why don't I use this package called Prettier? Probably what would happen is I would open up the website and look at it and go, no. K. Because I don't like that. Alright. Like, what what are you doing? And, also, I think senior developers know better to than to slap a new tool into their code Bos, because every time you add something new, especially something that changes your code, then how do you know that's Scott gonna break something down the line in one little use case? And that's probably what the developer here is is afraid of is that getting a call on a Sunday morning that something is broken, and it's because a weird formatter, came in and did that. So I'm betting that the situation here is that the senior developer here doesn't necessarily know what Prettier is or doesn't think that the formatting that Prettier gives is how they like to write code. I certainly have that as well. I I went to Prettier and I said, oh, I don't like this. And Prettier intentionally doesn't have very many options because it's opinionated about it. And I I found, personally, if you just sort of give up and let Prettier format it how it wants and just be okay with that, then life gets a lot better. What do you think, Scott? I largely feel the same way. I think I tweaked it on some things like Have a couple little settings. Yeah. Yeah. Semicolons,

I don't like them. Anymore.

I like had a hard time admitting that out loud. I don't use semicolons anymore. I had to turn it off, and that's something that would definitely irk a senior dev who'd be like, what? You don't want semicolons in our project? So, I mean, I mean, I think, largely, you you hit the nail on the head for most of this. There's tools that that can help us in in everyday life that you might not necessarily see the benefit on or you might not be awoken to the benefit on until you either use it for yourself or you you get it. The light bulb pops on, and you're saying, this is why.

And a lot of that has to do with the value proposition there. The what is the value of this to the code Bos versus what is the cost of adding it. Right? Is the cost that it's going to create bugs, or is the cost that it's going to modify things in a way that I'm not comfortable with? And what's the benefit? So there's this whole cost benefit analysis that needs to be done, and that's definitely what the senior developers are thinking. You I think you nailed it on the headwind. Senior developers really know not to willy nilly add stuff to things.

But in the same regard, I think Prettier is one of those tools that will just make about any code Bos better, in so many different ways from sussing out stylistic bugs to making everybody's code look the same. There's so many things that are in the positive value column here that it's a lot about how can we illuminate those values in a way that's coming across as helpful rather than, like, know it all and, like, needing to take in this. Like, I need to take over this project with my new fancy tools.

Yeah. So we've got a list of a list of sort of suggestions of what can you do here.

The first suggestion is, like, you ask for their thoughts on a tool instead of suggesting it. So That's nice. Come to them saying, like, hey. I need your opinion on this rather than why are we not using y, or z. And it sounds like you've already done this, but just for anyone who is looking at a new,

approach to something like this, that's probably a good way to to go about it. That to me, before you move on on the next one, I think an important thing to note there is that, developers we developers, we love our code bases. My code base is my child. It's not actually my child. I, you know, I love my children more than my code Bos. But, like Yeah. I really, really, really have put a lot of time and sweat and effort into my code, and I really I connect with it very on a deep level. And if somebody were to come into my project and be like, you know, your formatting sucks. Why don't you use this thing? I would be like, you suck.

You Node, like, that's that's that's the natural response when Wes it's it's almost like an insult. Right? It's like an insult to the work Totally. Base that's happened. So I I think, largely, that's a a great suggestion because if you're asking for their advice, you're not insulting their code base. You're not insulting their ego. You're not getting in in that sort of mental space, and it's more like looking at it as an objective person rather than in relation to something that they hold dearly.

The next 1 is show the dev that even though it looks weird, it's better for readability, and it it is. It looks weird or different maybe. Different might be even a better word. It looks different than than what they are used to looking at. But we have a project, and sometimes somebody writes code one way. Somebody writes another code another way. And it's important to see, hey, this is this is better for readability because we're all going to be looking at the same thing every single time, and we know what we're gonna be looking at rather than, having to teach things. Like, I don't have to teach my developers anything about my own formatting because Prettier teaches it to them. Right? Prettier takes care of that aspect. Therefore, we don't have to do that aspect of training, and this is how we write code here. You know?

Next 1 we have here is, look at the existing guidelines. So this is 1 question I I don't know about this specific use case JS, like, are there an existing coding guidelines that you are following, like a a formatting guidelines? Like, we always put array methods on their their new line or always explicit return, when it's an object or some something like that. Right? Like, different rules. And if that's the case, then you really are asking the Vercel to change their coding guidelines. So try to see if you can match it as close as possible.

For this reason, I wish Prettier did have more options, and you you slowly do see them adding more and more options. But try to, like, take what the existing guidelines are and match it as close as possible for that. Because my other question was is, like, if there are no existing coding guidelines, like, what's to stop you from using it personally Right. On on the new code that you write and then just checking it in. Right? But it sounds like maybe there are some existing standards in place.

Yeah. I think that getting a close like, between ESLint together with Prettier, you need to have some sort of standards. Wes it whether it is just ESLint or whether it is Prettier or whatever, you need to have some sort of formatting standards. And asking the developers to enforce those formatting standards by hand, I do not think JS a good strategy for having those formatting standards.

So if the standards already exist, maybe even before you give it to them, say, hey. Check out this cool tool that will enforce our standards, but enforce ESLint in a way that just does it for us automatically.

Right? There's that value proposition. Here's the value. It's going to allow us to enforce our guidelines that either already exist or a closed version of our guidelines and, those aspects.

Another good tip would be to put together a solid argument for it and really write down the pros and cons. And, you know, here's I thought about these things. I thought about the impact that's going to have on our code base. Here's how it's going to make our code base better. Here's how it's going to make us more productive. Here's why I think we should probably use this for our application.

Like we said, keep in mind, you wanna be respectful of the code base. Totally.

I also would try to use it in a smaller project because I think that a lot of people are against tools like this, especially ones that are so aggressive and opinionated.

But, honestly, have you ever seen someone use Prettier? It's usually like, yeah. Oh, that's nice. Like, oh, you see. Get even especially, like, I use Prettier on save in my editor. Every single time you save, it just formats it. Some people only like to do it on as a git commit or something like that. I think that's crazy. Yeah. I think that you should it's a tool that you should use on save Yeah. JS aptly. But let's just let them use it. It it that'll help, a whole lot.

Totally.

And lastly, you can always just use the Prettier formatter yourself.

And, you know, this is this is one's a little interesting because if your code base has an existing guideline to it, if it has an existing guideline, then you use Prettier when you're typing and then whatever, then you'll have to readjust to the guideline.

That's not a lot of fun, but it certainly scratches that itch. I remember this being a thing when, like, SASS first came out. Like, some people didn't wanna use SASS, and then other people were like, well, I'm just going to use SASS myself and then just only send the CSS down the line or something. Or, it it's definitely not an ideal situation. This is sort of like a last ditch effort, and I personally might not even do this one myself.

Yeah. Yeah. I think as Wes. You should also maybe check out JS Beautify.

I think this one comes with a Versus Node by default, and there are, I think, more options in this one versus Prettier. Mhmm. I'm sure there's a reason why Prettier JS is better. That's why everyone uses it. But, if you find that you can't match yours Prettier with what your existing coding style is, then maybe check out JS Beautify. It's Scott GitHub. I'll just I'll link it. I'm not gonna say the www in here. W

w what? H t t p yeah.

The days of reading out URLs.

Alright. So, hopefully, that helps you. I I I emailed this person back. I I asked for, like, more details because I'm very curious to see, like, how this goes. Like, I would certainly be really bummed to have to do a project without Prettier on it right now. So Totally. Let us know how you got your boss or other team onboard with tools like Pradir, ESLint, whatever. Tweet us at Syntax FM, and we'd like to hear that.

Yeah. I I would like to hear that too. And I think a lot of this advice applies like we mentioned at the onset of the show is, I think it all applies for selling anything to your team and and maybe not just pretty or whatever. But, remember, at the end of the day, there is a sort of cost benefit analysis that managers are always looking to do. And if you have a senior developer, they're they are most likely manager minded, and and they have an idea of, like, what is the cost? What is what is it gonna take to do this? What what is the it was funny. I before we wrap the show up, I had a job interview once, and they didn't use any CSS 6 features at all. And the reason was JS because they didn't wanna have to to deal with it. And I was like, what do you mean deal with it? You guys already have a build tool. They already had a build tool, and they weren't using ES 6. And this is this is, like, recent break it. Yeah. Like, what? Like, you can use this. And and that I if I would have gotten the job, I would have been like, listen. We need to talk about this Wes s six thing because it was for a senior Node, whatever. But, you know, I think that is definitely, there there's all sorts of these little things that can pop up that you need to be able to sell the team on in various ways, all all sorts of time. I remember Node of our devs Wes we worked at Ford trying to sell us on React, and and it was before I understood React. And I was just like, no. Like, that's ugly.

That's that's ugly.

I don't get it. And then once he sold me on it, he built like a pixel like a pixel art editor, and he's like, look. I built this pixel art editor in absolutely no code whatsoever, and it was super easy. Let me run you through this code. And I was just like, oh, this is dope. Okay. And let me let me look into this React thing a little bit more. Yeah. That's that's a great story. Yeah. Alright. I think that's it for today. Anything else to add there, Scott? I don't have anything. No. No.

Alright. Well, we will catch you on Wednesday.

Peace.

Peace.

Head on over to syntax.fm for a full archive of all of our shows. And don't forget to subscribe in your podcast player or drop a review if you like this show.