Why developers need to be able to identify technologies with staying power
medium.com
medium.com
What slows me down is the little implementation detail that is causing this weird bug that I just don't understand.
And if it is a new technology, then stack overflow doesn't have the answer.
So, to take the example the author gives, when Rails was new, its not that I didn't understand the MVC framework and how the roles were different. I didn't understand that RVM had to be set to a default ruby version every time I restarted the console.
Fair enough if you avoid certain situations because this is where you end up -- I do the same thing -- but the work is the work whether it's a new language or some oddball patch/upgrade that made things act funky in ways they didn't before.
That won't help you learning the technology, because that bug will be fixed in some configuration script and later users won't even encounter it, because the tooling will generate the proper scripts for the first time. So it's often not that kind of knowledge which proves to be useful later, but some implementation detail which you won't ever encounter again.
Both of these are red flags. Sure, I can learn how to steer around all the potholes. But so will everyone else who works on the project. Eventually someone will miss some important detail, or go on a refactoring expedition and end up removing a bunch of what appears to be excess complication but is actually a carefully constructed workaround for some wart in the system (the comment explaining this having long since been deleted - or maybe migrated to the team wiki, where all good information goes to die - by someone who had been watching a lot of Uncle Bob videos on YouTube at the time), and then production bugs sneak in, and eventually people quite rationally start to blame the technology.
https://reactjs.org/blog/2018/03/29/react-v-16-3.html https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...
It's at v16, and they're still making major changes to the basic component lifecycle, deprecating things, and then almost immediately having to write articles to teach against anti-patterns that already arisen in the new APIs!
A programming model that is so unintuitive people still cannot use it right, even after so many years, does not seem like a great bet to me.
That would be fine if they were making major releases every 2+ years, when you release a major version on average of 3 times a year it's incredibly unstable. A typical upgrade will be jumping several versions.
Don't get confused by the version labeling scheme.
I found this article from Saturday worth the read, as it explains what Docker actually is, and why no one needs it: http://catern.com/posts/docker.html.
The same goes for everyone working in the cloud; I've build my own clusters to compare the effort and expense (rather than just accept the marketing line) and running one's own servers, from one to hundreds, is exponentially more cost effective than any cloud service.
People are not doing their homework, and the herd mentality owns the entire tech industry.
Running a server is child's play, people. Don't believe the hype!
I've done this analysis for (mostly small-scale) companies for about 10 years, and, every time, the cost of using public cloud computing has been 2x-10x of running ones own servers for 3 years.
I've only had one exception, where the incremental cost of compute was 1:1, if the servers were placed in more expensive space near the other servers in the existing datacenter. Data transfer costs made cloud more expensive, of course.
> Running a server is child's play, people.
I'd say that's a bit of a hyperbole, but I agree that the incremental expertise (and time/effort) required to deal with hardware over cloud, is far from the prohibitve headache it's made out to be.
But I (and the GP) addressed that. It just isn't hard.
Your earlier comment is closer to the truth:
> political and cognitive effort of doing it themselves
With "traditional" industries, it seems the problem is entirely political, and it actually is about cost, because cloud isn't competing against the commodity gear we've been talking about here. Cloud is competing against "enterprise" hardware, which easily costs even more than cloud, not least of which due to maintenance contracts.
There was some discussion of this (somewhat tangential to the main topic) I participated in here https://news.ycombinator.com/item?id=17329028
I have servers in the data center and in the cloud, and I can say that the line "is exponentially more cost effective than any cloud service" has so many caveats attached, it's not even worth debating.
Simply put, if all you are doing is comparing running X servers in the DC and running the same servers in the cloud and that's it, yes, the cloud will be more expensive. This is why no cloud provider recommends simply doing that.
> People are not doing their homework
You should continue to do homework.
Only thing I'll add is that at best it's asymptotic to a constant factor more cost effective.
Not sure I agree with the conclusions. A bunch of OS-specific alternatives don't compare as I see it, but regardless, for me the value of Docker isn't the filesystem trees alone but the tools that then leverage them; compose, swarm, etc.
It might be simple for an adept developer but not all companies can find/hire that kind of talent. You need abstractions that simplify dev ops in a way. Yes, docker does not solve everything and should only be used when you can leverage some of its pros.
I've seen that, but I've also seen individual engineers and entire departments refuse to move on from what they are using. When they eventually realize they need to change, they are a lot further behind than they were initially, and it takes a lot more work to catch up.
A lot of organizations are getting real value out of Docker (and Kubernetes and NoSQL and React and all of the other trendy new things), and saying that "no one needs it" is just as myopic and wrong as being part of the herd mentality.
At the risk of nitpicking a word that may have been just used for emphasis, how can you be sure the value is real, though? Perceived value can be tough to tell apart, especially in a monoculture (called "herd mentality" earlier, perhaps too uncharitably).
Also, even if the value is real, is it technical, or political/behavioral? If it's the latter, that doesn't minimize theri value, but let's not pretend their advantages are technical. We could, instead, discuss if using the new tool is the best (or only) way to effect that change. It may be. It may even be that which tool it is doesn't matter, so long as it's different, as has turned out to be the case in ergonomics and RSI.
We've certainly seen some negative "NoSQL" headlines. How many startups used it to their eventual detriment, just following a trend and/or doing premature optimization? I'm not saying it can't provide value, rather than mere popularity and even perceived value, especially initially [1]
> saying that "no one needs it" is just as myopic and wrong as being part of the herd mentality.
I think that's what's called a "shallow dismissal" and is discouraged by the guidelines. The bare statement would be mere hyperbole and could possibly be "just as" wrong, but it was in reference to an entire article, which lays out the technical reasoning, which it's up to you to refute and point out they myopia of.
[1] I am reminded of how "easy" MySQL replication was always touted to be.. except that people choosing it did so with an empty database. If it broke, with a far-from-empty database, I found myself wishing for one of PostgreSQL's much more "difficult" options.
It's this kind of gross exaggeration that's keeping AWS so profitable, I suspect. Half a year and 5 sysadmins for only 100 server would do the NYC MTA subway construction team proud.
> We have to minimize time to market, make money not build servers
This is a false dichotomy, though. Of course you'd start with something where you can have infrastructure on day 1 of product launch. At small enough scale, cloud (or a VPS) is actually cheaper, too. Once you're at "time to market", if you're not re-evaluating, I'd say that's foolish.
> make markup adjusted with price
I'd expect any business to prefer to keep that markup for themselves as profit, assuming they even have that pricing power in the first place.
React, in my opinion, is filled with "best practices" where they choose complex solutions to simple problems. The dependency hell is also ridiculous in React. I would like to see how many of these apps are having issues upgrading to the latest versions of their dependencies in 5 years.
In terms of capabilities they are fairly similar but the the existence of an official router and official state management store means that the "things that can break in horrible ways" surface is reduced.
I stuck with KnockoutJS for a long time because they had (for a JavaScript project) incredible backwards compatibility and stability.
I've been programming long enough that "the new hotness" is of much lower interest than "what capability does it give me I don't have and will I still be able to build/deploy this in 3 years if I need to".
Also if something seems amazing I'll wait a year, if it was amazing it'll still be amazing in a year and I'll have 365 days of other people smacking their heads on the not amazing parts.
Someone else I know also has a soft spot for Ember though from my vantage point (dabbled in them all), they all seem quite similar. (Them being Ember, Backbone, Angular).
What? No it didn't. An imperative language is the opposite of a declarative language. OP might want to edit this one.
And what the article tells is that you should actually get interested in what you are doing, if you want to become experienced and not just old. That should be common sense, but I guess it is worth repeating from time to time.
However, if you don't have 30 years of experience, ranging from coding on a C64 to modern JS frameworks, the Lindy effect (older technology tends to stay longer) is a good shortcut.
It's not because older technology is inherently better, but it's because if older technology is still relevant, it's survived the "will it be relevant in the future" test once before.
The problem is we obtain that "senior" title long before we have this experience. Then when it's finally deserved (the 10+ year mark) the pressure starts mounting to move into architecture/management roles. And let's not forget the "old man can't keep up" that's always been rampant.
The industry as a whole seems to consider experience as a liability.
Why this isn't happening for languages such as C, C++, Java? Sure, new standards are kicking in, but you can still program using old standard, it will continue (more or less) to work.
Why do JS developers follow overhyped frameworks? I do not understand.. the few times I've programmed in JavaScript, I've always used jQuery: it might be old school, but it does its job well and bootstrap is still using it too.
Node.js? Vue.js? React? Angular? Elm?
I can't keep up with the Javascript tower of babel anymore.
And what happened to Django? Nobody seems to talk about it anymore.
As for your javascript questions: React is the answer. Not just because it has the considerable resources of Facebook backing it, but because at it's core, the idea is extremely sound and well tested, going back 30 or more years.
Vue.js has similar principles and might also be a good choice, but what you need to look out for is the community surrounding it, and whether it will eventually be unsupported.
Node.js is great in the backend, but doesn't have quite as many mature frameworks like Django. If you're down to build things from bare metal using some libraries like Express.js or Koa.js, then you'll enjoy Node.js. Typescript and Flow have also made Node more attractive.
With React you have the most options and biggest community, including ways to shoot yourself in the foot. It's preferred by full stack JS guys who also use node, so it could be great if you're a startup and can hire somebody who can do everything.
Angular is popular with enterprises who know what they need (a stable environment at scale with strict rules), who have a high budget for hiring specialists, the whole framework is more complex.
Vue sits in between Angular and React, but more geared towards smaller businesses and their needs. It's very popular with PHP devs, and full stack devs who don't use JS exclusively. The main advantage is peace of mind, knowing that everything works well togehter.
Elm is very opinionated, but also very different from those other frameworks. In React or Vue you start thinking of components, in Elm you think about functionality, and create components as they emerge from patterns, potentially leading to a more cohesive and elegant result.
But that's not how designers used to work. Bridging the gap between designers and devs, and how they currently work, is the main advantage of React and Vue imo. Web designers (like graphic designers) are used to think in whole pages, or layouts, and break things down from there (top-down). React and Vue and the component first paradigm is a compromise, where devs aren't degraded into only doing the implemetation, and designers aren't degraded into doing the styling only. It still respects both roles.
Elm is basically the next level for designers, or designers who like to code. It's how design that left the analog world behind could be.