I saw this talk recently

which if I understand correctly and a very interesting point of view which in one way could be summed up as "write more code and less libraries". Yea I know that sounds controversial. Watch the video and see what you think.

If I tried to summarize here's what I took away:

It seems like writing libraries is a good thing. It makes your code smaller. It makes it easier to read. It makes it possible edit the library and affect lots stuff. The problem is, especially if you're a company like Facebook with thousands of programmers working on the same code base is that there's no way to organize all the libraries. Everyone is going to write their own libraries. That means someone using their code has to first go learn their libraries. Whereas, if you had just written the code instead of using a library and you had use common patterns to write your code then the code would be understandable by others quicker.

Now, he wasn't saying write zero libraries. What he was saying though is make sure your library is solving a problem and not adding more problems. He gave some examples, one being AngluarJS which I haven't used but it is/was all the rage for web dev for the last 2−3 years. He claims that while it solves some big issues and therefore solves lots of bugs it also is a very complex api with a very large number of functions and that complexity in his opinion outweighs the benefits. In other words it's a net negative.

I have a feeling I'm not going a good job of summarizing his POV.

He is specifically talking about JavaScript so for example one idea/opinion he had is don't make custom libraries when there is a standard that would solve it. Write a polyfill (in other words write a library that implements the standard for browsers that don't yet support it). That way your code will follow the standard which eventually everyone will know vs custom library #749 that only you know.

Anyway I'm not sure how much I agree with this idea. I think it totally makes sense for Facebook and possibly for Google and other giant teams. But, I wonder if the same is true of a small team or a team of 1. Maybe it does. Or maybe at least thinking about "is this library going to add more problems than it solves in the long run" before writing one.

Well, something to consider at least.