milihello.blogg.se - Dri mazaika

Dri mazaika how to#
Dri mazaika code#

In the case of ESLint for example, most developers like the idea of standardization, assuming you’re standardizing around how they like to do it. Your customer probably thinks it’s served them well so far, and because of that, they don’t have a big motivation to change. The status quo is great for your customer and it’s your worst nightmare. Or they’ll forget about it because they’ll focus on something else. Unfortunately, they’ll usually give up at the first sign of resistance. Selling the benefits will pique a user’s curiosity, even if they aren’t in-market for the tool you’re offering.Ĭuriosity will take most customers up to the first obstacle. Making collaboration easier sounds good too.

Most engineers will want to write better code. Sharing the benefits of the product with the customer helps them understand what will this product do for me?

It will make it easier to collaborate with your teammates.

Our linter tool will help you write better code.

I think most of these details should be accurate based on my knowledge of ESLint. Let’s step up our game with this linter example. There’s a place for sharing the features of a product, but it can’t be the first thing you share.

“Sounds neat, I’m sure someone could like it. They will likely think something along the lines of this when you tell them: In short: A potential customer probably won’t care. The problem is that if a developer isn’t actively comparing different linting tools, no features or functionality of our product could genuinely interest a user with this mindset. It answers the question how is this product the best? If you’re on the market for a new linter tool, these reasons will resonate and be extremely persuasive. In short: describing a feature is talking about the tool from the perspective of the technology. This messaging is promoting a feature, it’s not promoting the benefit. If you’re experienced in sales or marketing you probably see the problem here.

Our linter includes checks for a whole new variety of problems you may have not even considered.

Our linter runs 85% faster than the fastest alternative.

Our linter tool is compatible with the new es2085 syntax.

They may be true, but for the sake of this article let’s pretend they’re true. Here are some facts about ESLint that I just made up right now. It would be intuitive to tell the developer what the product does, so let’s start there. The Value Proposition you share with your customer helps them understand what you get if you use this product. What would a developer value in a developer tool? If we are unable to communicate the value our product has to a customer everything from feature design to prioritization will only be possible through one strategy: guessing. If we can clearly communicate the value our product has to our customer, we can design our product around what they care about.

Why would anyone opt into that type of problem?

Following that, every change you’ll make moving forward will require you to be vigilant to pay attention to the outputĭespite all of these reasons a lot of people are using this tool.

You’ll need to do a major comb through your application to fix the problems upfront.

Once installed, it highlights all the problems in your application.

The tool itself doesn’t add any functionality to your application.

Here’s a list of completely valid reasons you could choose to ignore if you were trying to convince someone to use your linting tool. Why do people use tools like ESlint at all? On the surface, it looks like it only makes work harder to do. And it’s the perfect example to think about if you’re trying to build a tool that requires developer adoption.

Dri mazaika code#

It stops you from shipping code if it doesn’t meet an arbitrary ruleset. It adds an additional step in an engineering workflow. Let me guide you to where your customer is thinking with this question.Įver notice how when you integrate with a linter in your codebase all it does it complain to change your code?Ī code linter adds friction to the developer process. Once we understand how they think about our tool, we can help them think about it in a way that would help persuade them to use the tool.Īfter learning about what aspects of the product can help us drive adoption, we can think about how we can design a product around the things they care about.

Dri mazaika how to#

The goal of this article is to learn how to think about a code linter like our customer. If you were trying to drive adoption of a code linting tool, like ESLint, you’d likely face a lot of pushback, too. I’d argue that most linting tools are relatively simple products, too.