243

April 27th, 2020 × #team dynamics#productivity#code quality

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

Advice on convincing a development team to adopt code formatting tools like Prettier

or
Topic 0 00:00

Transcript

Announcer

Monday. Monday. Monday.

Announcer

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.

Scott Tolinski

Welcome to Syntax ESLint this Monday hasty treat.

Scott Tolinski

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.

Scott Tolinski

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.

Scott Tolinski

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.

Scott Tolinski

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

Scott Tolinski

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

Scott Tolinski

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.

Scott Tolinski

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.

Wes Bos

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.

Topic 1 02:54

Dev asked how to get team buy-in for Prettier code formatting

Wes Bos

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.

Wes Bos

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.

Wes Bos

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.

Wes Bos

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

Wes Bos

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.

Wes Bos

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.

Topic 2 05:14

Senior devs anxious about becoming outdated; don't want to break things

Wes Bos

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,

Scott Tolinski

I don't like them. Anymore.

Scott Tolinski

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.

Topic 3 07:16

Do cost/benefit analysis of tools for codebase

Scott Tolinski

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.

Scott Tolinski

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.

Wes Bos

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

Wes Bos

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,

Topic 4 08:26

Ask for thoughts on tool instead of suggesting it

Scott Tolinski

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.

Scott Tolinski

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.

Topic 5 09:45

Connect tools to benefits for codebase instead of criticizing

Scott Tolinski

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?

Wes Bos

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.

Topic 6 10:34

Show improved readability despite different formatting

Wes Bos

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.

Topic 7 11:39

Coding standards needed; automate formatting enforcement

Scott Tolinski

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.

Scott Tolinski

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.

Scott Tolinski

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.

Scott Tolinski

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.

Topic 8 12:45

Write pros/cons analysis showing project improvement

Scott Tolinski

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

Wes Bos

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.

Topic 9 13:01

Try tools on smaller project first

Wes Bos

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.

Scott Tolinski

Totally.

Scott Tolinski

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

Scott Tolinski

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.

Topic 10 13:37

Can format your own code until team buy-in

Scott Tolinski

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.

Wes Bos

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

Wes Bos

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

Scott Tolinski

w what? H t t p yeah.

Scott Tolinski

The days of reading out URLs.

Wes Bos

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.

Scott Tolinski

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.

Scott Tolinski

That's that's ugly.

Scott Tolinski

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.

Wes Bos

Alright. Well, we will catch you on Wednesday.

Wes Bos

Peace.

Wes Bos

Peace.

Scott Tolinski

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.

Share