BabelJS creator laments open-source development
twitter.com
twitter.com
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.
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.
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
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?
I hope Sebastian can take the complaining as a badge of honor because so many people are so focussed on his product.
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.
Still, I'm on Sebastian's side. Being a maintainer of a popular project is tough.
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.
Maybe the best thing is if you can get hired by a company with the purpose of working on an open-source project?
> 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?