1
JetBrains Adds :Company:Name: to Remote Dev Env Managers
The first paragraph says: "We're thrilled to announce :insert:company:name: partnership with JetBrains, marking the launch of our new JetBrains plugin. This collaboration opens up a world of seamless development environment management within your favourite JetBrains IDEs, such as IntelliJ IDEA and PyCharm, among others."
So basically, they built a plugin - how would you as a developer feel after reading this "bold" title and then reading this first paragraph?
Trying to prove a point to some of my marketer colleagues, so basically, I'm looking for a confirmation bias (LOL), but it really just goes against everything I know and every "best practice" cell in my being, and to be honest, it makes me mad.
I might be wrong, so I won't reveal the name of the CEO and company. Just want to hear some opinions first.
However, devs ldo like to experiment, and if you give them access to what you are building in places they trust, it can go really good. The obvious lesson from what I'm about to tell you is probably - to use your in-house devs to gain insights and knowledge (provided you have good ones and they have the time).
As a marketer, I know that VS Code exists, but I was unaware of a whole marketplace that exists for VS Code Extensions.
One of our devs uses VS Code a lot, and he suggested building an extension for one of Treblle's products (API Insights). He did it, we researched, figured out the best way to present it on the VS Code marketplace, and we ended up in the marketplace's trending area for 10 days or so - gaining over 600 downloads of the product.
If you have the opportunity to build an extension for your own product, I definitely recommend it - it's great exposure the one of the world's biggest dev communities.
According to the 2022 StackOverflow survey, VS Code is the most popular IDE used by developers. That is one of the reasons we wanted to make API Insights even more accessible to developers who use it to work on APIs.
I know this might seem super obvious to devs here, but for non-devs it's not. It's easy to say "just tap into your devs habits", meaning, how do they find things, what do they use on a daily, weekly or monthly basis? But often, people don't see their normal day-to-day work habits as something that can help marketers out - in reality, it's a goldmine of ideas.
So, making a very friendly working environment where a creative dev can suggest and execute their own ideas (this came directly from a dev that uses VS Code as I said), might be the best thing you do for your tool/platform or whatever it is you are building for developers/engineers.
Next stop - GitHub.
DOes that just mean that PE just hasn't amassed a critical amount of people to be its own thing?
It's not there yet, it will take some time. We as a society are kind of still figuring the damned thing out. There are some obvious benefits, there's politics, morals, economics involved here... What exactly will become the "standard" no one really knows. Exciting times.
But, let's talk about something else. I work for an API Observability and Governance company. The product aims to make some of the API stuff easier to handle, for the whole team, from devs to management.
That includes API docs. However, there's a wall of "standard" we need to climb, and the wall has a huge grafitty written all over saying "Swagger".
So, I just want understand why? And what would need to happen to make a groundbreaking shift in that area?
If you have more examples of "standards" that would benefit from a shift or disturbance (what marketing calls disruption), feel free to add.
(+) It needs to be recommended by a fellow dev (*) It needs to look and feel cool (website + product) (#) I need reassurances about security (is it safe to add it to my API, for example) ($) It has to have a free trial with no credit card submissions (?) I hate free trials, it needs to have a free-forever option (&) I need reassurance that it REALLY is easy to integrate (!) It needs to have perfectly written and easy-to-understand developer docs (=) With my busy schedule, you need to find the right time to get me to try a new tool.
... Feel free to comment with something else.
Personal Comment: I am pretty open to trying new stuff. It just sometimes depends on the timing a lot. I might actually like a tool and try it like 6 months later xD
It also depends on the urgency. If the tool looks like just something that is nice-to-have, I probably won't try it immediately or at all.
You do not build trust by giving them:
1) You have these issues + my product solves them (Insert Features)
Developers, engineers and other team members get these kinds of claims all the time and they simply just don't build trust and they are so over-used that they don't spark any curiosity among tech folk.
2) "Stop losing time", "Save money", "Be the most valuable player in your team" ... (Insert Benefits)
These might spark some curiosity, but on the other hand, it might even get tech folk mad at you. This is just too vague of a message. Why would they trust you?
How then do you build trust?
Talk about PROBLEMS! You have a product that probably solves some problems, right? Well, talk about them.
Do not talk about how your super-mega-extra-cool product solves them, just make content talking about the problem. How it's usually handled, what are the pains behind it and so on.
Do it long-form, or short-form, on LinkedIn, on Twitter, in video format, podcasts and so on.
Talk about them on places developers usually hang out. Some of the obvious choices are relevant slack groups, tech Twitter, relevant subreddits, Indie hackers, and so on.
Put your company or your name behind it (although, people usually react better to a real person, rather then to a company logo). Be useful! Engage with the community.
Then, after you've built enough trust, you will be able to reap what you saw, and that means, getting all those people that trust you to try out your super-mega-extra-cool product and they'll give you an honest review.
All you need to do at this point is listen!
Don't misunderstand!
You should definitely communicate your features on places like your website, LinkedIn company page and similar.
In the business-to-developers market, this is essential for early-stage startups. When tech-folk come to your website they'll give you a very short speed date to get to know you. Communicating benefits won't tell them if they need you, features will.
(Although, in these neck of the woods probably the first thing would be - How NOT to bore developers xD)
Anyway, if you are building a product, you might find it useful to do the ICP first.
When you have that down and mastered you can take your journey in so many directions and succeed fairly fast.
Some of the directions you can take when you have this skill down and mastered:
Content (you now know whom you are creating for), Ad buyer (you now have an idea of what they want, what problems they need solved or what they like to buy) SEO (you know what they search for)
And step further from that would be things like demand generation, viral content, establishing yourself as a thought leader and so on.
What's your opinion on short-form video content? How do you consume it? For fun, or do you actually end up trying some of the recommendations these influencers dish out?
With GraphQL you have interfaces and you have union types where you can be very explicit about what kind of response you give to the user. So basiaclly, you don)t really have to worry about codes.
However, the problem is people missunderstanding in which situations you build a GrapHQL and in which REST API.
There’s one very important distinction we have to make between REST and GraphQL. With REST it always the case that the producer of the API can make intent very clear. With GraphQL you actually need to understand the API you want to access. So you’ll have to go to GitHub docs and you want to understand how to get information, you look that up in the docs, and it gives you exactly the endpoint you want to interact with. And with GraphQL you get 10MB of GraphQL schema and now you have to figure out how to formulate your query.
So, from my point of view GraphQL is a lot easier when you produce the API for yourself, whereas with REST you can make intent to 3rd parties much more clear because you have clear entry points, you have URLs with a specific intent and with GraphQL you have one endpoint and then you have a query and they have 50 different fields and you might be a bit overwhelmed and you don’t exactly know where to start.
So if your API is going to get consumers, REST is a better option.
In GraphQL if you’re doing errors as data, you have to figure out how to relay that problem scenario to the client and that is always going to be a unique, snowflake situation. You are going to have to come up with your own error codes that you agree with them.
But that doesn’t work for generic monitoring tools, that doesn’t work for lots of other things.
I really like in REST that I can use status codes as a category of error.
Which will let caching tools know not to recache it, will let monitoring tools know that there was some sort of problem, will let people know if they should retry or not. Those categories of error should be fairly understood.
And then within the message, you can use something like RFC 787 or JSON API errors with really standard error formats where you go just as specific with what went wrong. Dynamic information, various different variables and arguments and messages that are written in English or you can even have them translated.
You can do both in REST and I feel like that gets ignored from the conversation and people just talk about 400 and 409, 406 and get confused about the numbers.