3 ms·

> You can’t do it “correctly” if “correct” is “whatever the guy who’s been here longer wants.” To be honest, "correctly" is whatever actually works. But since

> You can’t do it “correctly” if “correct” is “whatever the guy who’s been here longer wants.” To be honest, "correctly" is whatever actually works. But since we as an industry haven't been around for a long time and don't collectively know what actually works, it is simply the case that we defer to those who have comparatively more experience, so that we may get decent solutions now, as opposed to excellent ones later. It took the ancient civilizations hundreds if not thousands of years to perfect architecture to a reasonable degree, where it's possible to be fairly certain about the viability of most typical designs, as well as the tradeoffs that nonstandard ones might require. Personally, i think that we'll only be able to talk about what truly works and what doesn't once the industry cools down - when there are new JS frameworks once a month or once a year as opposed to every day (or for any technology, really). When there are very few breaking framework changes, because the frameworks would finally be stable. When the primitives around doing web development, interfacing with devices and everything else have been distilled to their most usable possible forms. When a developer doesn't need 10 languages or 20 frameworks to do their job, but can instead rely upon a few, after most others would have died off after a sort of singularity of languages. That's when useful certifications would be possible. That's when estimates wouldn't be guesswork. That's when the education systems could actually prepare people fully for working in the industry. That's when the development of projects wouldn't be such Wild West, but instead would be a process with far higher quality, a true engineering discipline even at the expense of projects taking longer to actually develop, much like you don't construct buildings in an ad hoc fashion. Now, whether that will happen in a 100 years, a 1000 years or never, is another question entirely.

mbrodersen 5y ago
I think you will find that there is a large set of ways to solve the same problem equally well. So arguing about the best way to solve the problem is a waste of time.
- KronisLV 5y ago
  In many cases this is only because of unnecessary duplication of languages and frameworks. People wonder about whether they should create their back end in Ruby or PHP. People wonder about whether they should create their front end in Angular or React. People wonder about whether they should use MySQL or PostgreSQL for persistence. They wonder about which of the many OS distributions they should use for hosting their application. But perhaps that's the true waste of time - maybe we shouldn't need multiple approaches to each problem. Maybe we'd only need one, which could then be the sole focus of the industry. The tooling would be incredible if there would be just one workflow to support. The technologies would be tightly integrated, since that's where all of the effort would go. And there could be models built around the language and frameworks to such a level that any usages of antipatterns could be immediately identified and even fixed automatically. If you ask me, the millions of man-hours that have been spent on creating a brittle and fragmented landscape of tools that don't work well and make developer's knowledge obsolete in a few years while also urging people to do CV driven development are the real waste of time. Of course, that's the reality that we live in but maybe for the developers in 500-1000 years it won't be that way.
  - mbrodersen 5y ago
    I don’t think having multiple ecosystems is a bad thing. Think about it as a market place where ecosystems compete to attract the attention of developers. A bit like a decentralised economy. While what you are suggesting is the equivalent of a top down centrally planned economy where a dictator will tell everybody what to use. And (I assume) police and punish everybody who doesn’t comply. That doesn’t sound like a good thing.

mbrodersen 5y ago

I think you will find that there is a large set of ways to solve the same problem equally well. So arguing about the best way to solve the problem is a waste of time.

KronisLV 5y ago
In many cases this is only because of unnecessary duplication of languages and frameworks. People wonder about whether they should create their back end in Ruby or PHP. People wonder about whether they should create their front end in Angular or React. People wonder about whether they should use MySQL or PostgreSQL for persistence. They wonder about which of the many OS distributions they should use for hosting their application. But perhaps that's the true waste of time - maybe we shouldn't need multiple approaches to each problem. Maybe we'd only need one, which could then be the sole focus of the industry. The tooling would be incredible if there would be just one workflow to support. The technologies would be tightly integrated, since that's where all of the effort would go. And there could be models built around the language and frameworks to such a level that any usages of antipatterns could be immediately identified and even fixed automatically. If you ask me, the millions of man-hours that have been spent on creating a brittle and fragmented landscape of tools that don't work well and make developer's knowledge obsolete in a few years while also urging people to do CV driven development are the real waste of time. Of course, that's the reality that we live in but maybe for the developers in 500-1000 years it won't be that way.
- mbrodersen 5y ago
  I don’t think having multiple ecosystems is a bad thing. Think about it as a market place where ecosystems compete to attract the attention of developers. A bit like a decentralised economy. While what you are suggesting is the equivalent of a top down centrally planned economy where a dictator will tell everybody what to use. And (I assume) police and punish everybody who doesn’t comply. That doesn’t sound like a good thing.