
Ask HN: Understanding software that was made because previous ones didn't work? - itsyogesh
I understand that I might not be stating the question correctly, so here are a few examples. Consider Docker, it was created to reduce the efforts of CI, CD over previous solutions, but for someone who is just starting to do deployment, how would he understand those issues and decide if that is really required. Or consider MongoDB (NoSQL), which was created to tackles the large-scale  SQL indexing issues, but for someone who hadn&#x27;t seen them, what should they choose. Or React (Shadow DOM). Or Kafka&#x2F;Heron. All these new technologies are required for a good job profile, so learning them is certainly important for a developer. But without an understanding the issues that people had previously, how can one fully grasp the motivation for creating these technologies.
======
galistoca
It's a very good question. You have asked a genuine question but I think it
can be a great rhetorical question. I feel like developers nowadays blindly
learn these "new technologies" just for the sake of learning new technologies,
even though they will probably never build anything that really need these
technologies. Maybe you get some street cred for knowing more but if I were
you I would rather spend my time and energy actually "building" and
experimenting things than just learning some esoteric technology that you
probably don't even need.

Probably not the answer you were looking for, but I can't help but think it's
pathetic how developers tend to think they're competent at what they do just
because they know how to use the latest popular build tool, deploy tool, and
some new framework that you probably will go out of fashion in a few years.
(I'm not even exaggerating. Coffeescript used to be the "it" language but not
anymore, people used to rave about grunt, then moved on to gulp, then webpack.
Probably next year it will be something else. Same goes for Backbone =>
Angular => React hype cycle, you get the point.)

Just to share my two cents, you mentioned knowing these "React", "Kafka", and
"Heron" will get you a better job, but that is far from truth. Let's say a
company is hiring a frontend developer. Chances are they won't hire just
because you know React. It is assumed that good developers can just pick up
any new technology and learn quickly so just knowing some trendy technology
won't make or break anything. They will probably test you to see if you have
fundamental "vanilla javascript" capability.

------
LarryMade2
Its kind of hard to understand if you haven't experienced it. On some projects
you might see the previous and latter generations and compare side by side the
apparent changes and improvements.

For those who did revamps, they knew their value of the original and believed
they could improve upon it. Unless you have some personal investment in the
concept, I don't think you can improve on it too much beyond cosmetic and
mechanical improvements.

So my suggestion if the problem is interesting enough for you, part of your
work is to get experience and own the problem and strive for a solution. It
may not the the project that gets you going but the implementation being in
need of your skills, etc.

