|
|
|
|
|
|
by z3t4
2304 days ago
|
|
|
The problem with developer tools is not technical, it's all about the selling part. If you make a new superior developer experience, you think developers will instantly see the benefits? haha! You first have to teach them, then after a few month if you are lucky you will get a "aha, now I understand". So first you need to manually educate each user until you have a critical mass. Then you need to market and hype your product. So that developers will tell each other how cool your new technology is. Continue with that a few years until there are code in production that use your product, before even thinking about a business plan. So there are few options, either you have enough money so that you do not have to "work" again, and can spend your time making new tools. Or your current employer lets you work on the tools. For a startup working on developer experience (language and tools) I would suggest a 10 year runway (funding) and that 1/3 of the budget goes into educating users and 1/3 goes to marketing. Any software business that is profitable, already have code in production, and that code need to be maintained. So instead of creating a new better experience, you can make the current experience better. eg. putting rockets on a horse, rather then creating an automobile. |
|
|
Selling is going to be hard but I feel like you underestimate the technical difficulty of replacing a large stack of complex tools that have decades of work and experience behind them. And that, in part, makes selling harder: I'm immediately suspicious of anyone who claims they've invented a superior way to work. It's more likely that they've invented a small improvement (and an arguable one at that) for a particular scenario, but developers would still have to rely on their old tools for a lot of stuff. In worst case, they're trying to sell a tool that doesn't extend but replaces the old tools without providing support for scenarios and workflows that existed with the old tools; step forward on one front, three steps back on others.
Of course, small improvements to existing workflows can usually be implemented by developers for themselves (and others while at it) once they learn about the idea, and that's how the developer experience has slowly improved over the years.
For example, you can make a new fancy code editor (let's call it sublime) and hype it on features like multiple cursors. And I can have that in emacs at the cost of about 3000 sloc of elisp, and I don't have to give up any of the old things that I've grown to rely on.