Ask HN: Understanding software that was made because previous ones didn't work? | Hacker News Reader

Ask HN: Understanding software that was made because previous ones didn't work?

2 pointsitsyogesh2 comments

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't seen them, what should they choose. Or React (Shadow DOM). Or Kafka/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.

View on HN

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.

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.

Reply on news.ycombinator.com