Hacker News Reader

Comment by electic | Hacker News Reader

You can spin it this way if you like. However, a big part of this framework and Tool epidemic is ego. The trick is to take a dominant framework or tool, find a deficiency, and then rewrite it again with that deficiency fixed. Why? Because if it takes off, your career takes of.

What developers should really do is contribute and make the existing projects better. Everyone will thank you for it.

View on HN

Nope they won't, because then your are just another contributor.

There are thousand working on linux (the kernel). How many of them do you know?

Which is better (for your CV), be a contributor to Angular.js (example) or create your something.js that left-pads and right-pads at the same time?

I think a better example would be: be a contributor to Angular.js or be the creator of Aurelia.js.

From what I can tell, something.js if the amount of code is equivalent.

Having a patch or two in angular doesn't seem to move the needle.

No. Because nobody knows about your something.js

Getting something on Angular means you were able to get your changes approved and merged (team work)

Situation is better if you can have a bigger project or more people using your something.js

Well, left pad was quite famous. And especially famous when the author removed it. You never know.

Was it famous before the author removed it?

It actually helps if you contribute to an existing project, because it is like, you worked with others on an existing codebase and contributed features in a big project which has high visiblity and is being used in real life by real people.

Much of what we work is all with people and on large codebase, so if you are contributing to existing project, it is actually helpful for interviews. Also it takes weeks to get a PR accepted, so if you actually were successful in getting your feature accepted, it shows your resolve to contribute the feature because you want to contribute and not because you want to do a PR stunt for your career (and not get annoyed by the constant changes which the authors ask, which are close to a million)

You took the words right out of my mouth. It has more to do with ego than everything else, and you can tell because most competing tools, in JS anyway, don't have a significant edge over the others and are largely the same tool reimplemented without much of a concrete goal besides "performance" and "scalability ". Like you said, taking an existing tool with a deficiency and rewriting it from scratch without that deficiency. Advances have occurred for sure, but not without some massive failures from not having a good roadmap. Brute force, in other words. The projects that do have more concrete goals and vastly different methodologies in the JS world happen to be low in popularity, relatively speaking. I wonder if the inflated egos in the JS community comes from all the talk of "Node.JS is the future" in recent years. There aren't nearly as many competing projects in the Ruby world, or Python or even PHP.

I second the part about ego. I once wanted to write a BaaS because I was not happy with parse-server. After considering the time efforts and comparing it with the efforts to improve parse-server I decided to just improve that software and don't care about my own project, because I try to value my time higher than my ego. It isn't easy to be rational if your ego is involved.

But it's also difficult to decide if it's worth it, especially if you've found a real deficiency. The creator of http://propelorm.org said to me that his framework gets him €120k+ offers and that he recommends building open source projects that are in demand.

So I don't think it's possible to give a definite answer what developers should really do. Maybe bit of both?

I somewhat agree...

However, there is also something to be said for rewriting work. There's the concept of "plan to throw it away"[0] I think a lot of these projects start because people are just trying to learn. Then they share them and get built upon. You then have an ever increasing amount of technical debt, eventually inspiring others to write a simpler version and then that becomes the defacto and so it continues...

I think my favorite example of just stupid stuff that keeps getting propagated is the Date type in javascript - the month field starts with "0", but the day field starts at "1"[1]. Like what is with that?

Even with everyone contributing to Javascript that stupid thing still exists because you can't break the internet to fix it (ask the Python community how changing a lot of syntax works out - although Python wasn't even that bad). That's why people write new stuff, because they want to make things simpler. Not really something to complain about IMO.

The unique stuff I learned is probably just these four languages: BASIC, C, C++, Python - I learned it in that order and now I can pretty much do w.e. language I need to use. Because all frameworks are based off the same stuff. Go is easy, Javascript - no problem!, I do full-stack work and data science in my day job it's really not hard at all. All the frameworks make it even easier.

[0] https://en.wikipedia.org/wiki/The_Mythical_Man-Month

[1] http://www.w3schools.com/js/js_dates.asp

This not work at all, is super-unrealistic.

And it grow more un-fixable as longer and bigger is the project.

For example: Fix C. Or javaScript. or Angular.

Is impossible to do it without change what them are. And when the trouble is intrinsic the only sane option left is restart.

In fact, stick to old is as worse (and maybe more) then rewrite. The trouble is when rewrite not change enough to be worth it.

Are you saying that JS devs are different from Ruby devs in this regard?

Throwing out some observations/arguments here:

Many more JavaScript tools and libraries have websites that are visually appealing than for any other tool or technology that I've seen. Since the informational content is usually not of a similar or higher quality in my experience, it stands to reason that appearance is more important to developers of JS tools/libraries. Which could imply that peer recognition or career building is a more common, or stronger motivators in this particular demographic (of JS tool/library authors)

I'm also entertaining the thought that JS development might be a more solitary work (on average), which could conceivably also influence if you choose to cooperate rather than build anew yourself. Most JS tools were also not very big, as they had to be delivered to the client, and as such more amenable to being built by a lone developer or a small team.

The only thing I known for sure is that in 20 years of coding, nothing have confused me as much as the plethora of JS 'things', not even DCOM or the almost unequivocal praise of Hibernate (for a while)

>Many more JavaScript tools and libraries have websites that are visually appealing than for any other tool or technology that I've seen. Since the informational content is usually not of a similar or higher quality in my experience, it stands to reason that appearance is more important to developers of JS tools/libraries. Which could imply that peer recognition or career building is a more common, or stronger motivators in this particular demographic (of JS tool/library authors)

I agree with your other points, but this one is easily explained by the fact that people who specialize in Javascript tend to be in the front-end/UI development field, and thus are more likely to have an artistic background/sensibilities.

Both could be true. In my experience outside perception is quite a bit more important to people with artistic background than to the average programmer.

> (...) it stands to reason that appearance is more important to developers of JS tools/libraries. Which could imply that peer recognition or career building is a more common, or stronger motivators in this particular demographic (of JS tool/library authors)

I think you read too much into it. The front-end of a website would be important for tools which help making front-ends of websites, don't you think?

Reply on news.ycombinator.com