Unfortunately in my experience (founded and built a developer focused SaaS that is profitable) projects or products that are for engineers is a soul and gut wrenching market. Developers/engineers are perhaps the worst kind of customers. I am an engineer, but these days I enjoy business, finance, and the process of building a company more than pure technology.

Engineers have insanely high standards of products. They expect you to be using the latest and greatest tech and design. If you're running a LAMP stack SaaS, must be crap. They will sit and flame war for hours about tabs vs spaces, syntax, best practices, formatting.

Then there is trying to convince an engineer to pay for a product. Besides engineers typically being extremely frugal (I think it stems from the enjoyment of micro optimizing spending and finances), they'd also rather just build that product themselves. After all, what's the point of being an engineer if they can't just build it themself?

Great engineers will custom build product and tools for internal use, where great founders will find other products and companies that solve the problem and pay for them.

This is nonsense. And therefore dangerous if used as some form of inspiration.

Great engineers do cost benefit analysis. They solve real problems.

Great engineers do not just write code for everything to inflate their own egos.

My apologies if I missed some form of too-subtle sarcasm here.

No, it isn't nonsense. Actually your calling it that is a great example of what it's like to interact with engineers.

Honest question, have you ran a business before?

I don't know your definition of "ran a business", but maybe my story can fit in it.

We started a business five years ago. At the beginning, we were only two guys, but the team have been growing since the last three years.

To be honest, this have been a super awful experience​, mostly due to give support to clients. Of course, we have had awesome clients, but many of them have been a constant source of stress and frustration.

I'm planning to change my job in the near future, and the only thing that I'm sure is that I don't want to repeat this.

I'm sorry for the lack of details, but I can't tell much more in a public forum

Thanks for engaging honestly with that forward comment.

Yes, I have. No, I have not sold to engineers.

To add some perspective: Airbrake/Sentry error monitoring; NewRelic monitoring; Pingdom uptime monitoring; Log management Ala Papertrail; Github/Assembla version control; are things that I reach for in the initial set up.

I think engineers are/(should be) unwilling to give up on control when it comes to their core business areas. This is why I prefer open source (or at the very least known stable and long lasting) solutions for the data layer and core infrastructure pieces. Or at least compatible managed services; no introducing new layers of abstractions. Also they’re unwilling to pay for things like editors, from ideology and from the market today.

I’ve seen the build it ourselves approach, primarily put forward by engineers who do not appreciate the costs of building and maintaining things, and from stakeholders with a vested interest in selling particular services. I would call both a circle jerk kind of situation.

To reiterate, in my mind, great engineers would quickly outsource all non core competencies so that they can focus on the more important things. It costs me more to build something, both in terms of time and opportunity, than to have an expert do it for me. Herein lies understanding the problem that you’re trying to solve.

To me, intelligent engineering is, cliched as it is, about understanding the tradeoffs, and building the bare minimum that delivers. Keeping in mind that the tradeoff could be about investing in future directions. One example that comes to mind was a data pipeline built using ifttt, dropbox, s3, and spreadsheets for data analysis: brutally simple, probably fragile, but brilliantly done for what was needed in that situation.

Engineering is not writing code, engineering is solving problems.

From a different angle, from a limited vantage point, I’ve seen companies that sell to engineers struggle because they fail to clearly articulate the value that they bring, and because they introduce too much risk to the rest of the system (What if the vendor disappears, or if I want to migrate to another? Why is there yet another API to learn that also strongly couples with my system?)

I am curious about where you are coming from on this. Would you care to get into some specifics?

"There are 2 kinds of programming languages: the ones people complain about and the ones nobody uses" - Bjarne Stroustroup

I hope Sebastian can take the complaining as a badge of honor because so many people are so focussed on his product.

One of the ongoing narratives here on HN and elsewhere is that there's ‘a new JavaScript framework every other week’, as if that's a bad thing.

A bit further down the thread, Sebastian says:

> Revel in fragmentation and duplication because without it there's stagnation and it stifles innovation.

And that just resonates with me. We have a large amount of fragmentation in JS-land, but also an incredible amount of innovation. That sparkly new hobby framework written by your random Joe Programmer may contain a brilliant idea or two, and for that it's already a net-positive addition to our world.

There's this idea that you'll get hopelessly lost trying to find your way through some sort of framework jungle, but what we really have is options and innovation. If you don't want the hassle, then by all means just go with something obviously solid, stable and here to stay, like Ember or AngularJS.

Innovation is good. I think the knock against "a new JavaScript framework every other week" stems from seeing JavaScript tools, frameworks, and libraries throwing aside 60-70 years of solid design patterns and architectural principles in favor of "minimum viable product" in order to be "first to market." This has resulted in a plethora of relatively immature tools and frameworks that are just better enough than the previous generation of tools to warrant using, but use of the new tools and frameworks to engineer quality software also results in a lot of frustration.

For an exercise in what I describe above, try taking an existing AngularJS (v1.x) application, add some non-AngularJS components using ES6, then attempt to generate a comprehensive test coverage report over all of the components in a single testing pass using Gulp, Webpack 2, and Karma. Bonus points if you figure out where to add Istanbul correctly on the first pass through it.

The thing that is unique about JS is that most people see it as unnecessary and detrimental. No one cares about Joe's brilliant idea if it's used to render text (where a server-side template would've done just fine) or serve ads.

Still, I'm on Sebastian's side. Being a maintainer of a popular project is tough.

Yeah, and people can be really shitty about open-source JS projects in particular. (They bring all their grumpy "JS fatigue" baggage along.)

Maybe the best thing is if you can get hired by a company with the purpose of working on an open-source project?

Word. Anyone who's not famous and tries stepping out of line will be put through the same meat-grinder. The majority seem to think that the way to get anywhere in this world is to make sure that no one else gets there first, which couldn't be further from the truth. That being said, there will never be any progress without people stepping out of line.

> I remember Babel being attacked early on by people on TC39 and members of the browser teams.

> I don't just mean "Babel sucks" I mean "Babel was written by incompetent developers".

That's hard to believe. Does anyone know something like that was posted publicly?

Not letting JS die should not go unpunished!