[fieryeagle]

Just sugar-coated kool aid I'm hearing. Community benefits? First of all, I'm coding to get paid and this recent madness proved that JS ecosystem is semi-garbage. Back to the original question - do people really can't program that they need packages like left-pad or is-integer which had their own dependencies? Before writing those cool toolchains (which would likely work in a specific machine with a specific setting with all the real world testing the community has) can we at least pretend that we know the computer science basics?

[usrusr]

People need modules like leftpad to tick the "maintains moderately popular open source project" checkbox. Instant hirability.

I don't want to claim that it would be a directly calculated career move, more like starting a blog: you admire a good blog, you want to be more like the blogger, you start your own one. On the dim chance that it will become both good and not abandoned after the third post. Nanomodules can be just like that, the air guitar of would-be rockstar coders. This is certainly not the only reason for their existence (and even the air-guitar aspect has a positive: low barrier of entry that might lead to more serious contribution), but the discussion would be incomplete if it was ignored.

[spenuke]

Yep, I think this is a huge, HUGE part of it.

Step 1: Create a culture in which "having open source contributions" is a requirement to entering said culture.

Step 2: Remove all friction from introducing open source contributions into the culture.

Step 3: Watch the Cambrian explosion.

Step 4: (Two years later) Point to the Cambrian collapse and how the new hot thing will solve everything.

I don't know what sort of shit show Step 4 will turn into, but it will also definitely be the result of folks taking a simple and good rule of thumb (this time, it won't be "small and composable"), and implementing it without ever stopping to think what problems it solves and doesn't solve.

[usrusr]

That scenario in the last paragraph is an uncomfortably convincing view of the future. Do you think it could be avoided by an additional step like the following?

Step 5: a mechanism for curated metamodules

This would not have changed much for the current situation, but it might help cultivating a "too important to play it fast and loose" mindset that would.

[spenuke]

No, probably not. On the contrary, what I'm suggesting is that the solution of Step 5 you suggest would be "the hot new thing" of Step 4.

It's about unforeseen consequences of a solution to a problem. That's what I mean by "I don't know what it will look like", because it will definitely solve the problem this thread is dissecting, and the problem it introduces will be a whole new vector.

But its selling point (the way it solves our current problem) will be a simple idea that is taken to its logical extreme by people who don't think critically, and then it will be time to solve that problem.

That is, I see the underlying recurring problem as stemming from the cultural forces –– how we educate people, how we make ourselves hireable –– that enable even very smart people to be shortsighted and immune to learning from the past.

[fieryeagle]

I would give those candidates the FizzBuzz problem just to see if they can actually code from scratch or `require('fizz-buzz-solver');`. I care more about their competence than what 1 or 10-liner packages they maintain.

On the contrary, I would certainly mark "maintains moderately popular open source project" as a calculated career move, just like how prostitutes would dress up right for the cliente. Sorry for the crude example but I am not placing the blame on the devs here but the absurd notion of employers considering a GitHub repo the 'in' thing before actual capability. Candidate - Brah I got 10 of those packages with 10mil downloads in total but I can't code for shit. Hiring manager - Since we are suckers who look at stats, you're hired!

The problem with this nanomodules approach is that it results in complacent and naive developers that eschew the basics and just publish random crap. Anything can make it to be a NPM package and be judged by...popularity? Since when is code turning into pop music :)?

[nailer]

I'd hire the people who use fizz-buzz-solver and spends time doing original work rather than rewriting something for the sake of ego.

[fieryeagle]

Here's where expectation should be set for both candidates and interviewers. The point of solving Fizz Buzz problems is to open up angles for discussion. What would you do differently with this problem, at this scale, for this integration etc etc. If someone writes crude code, I'd ask if they follow style guides or conventions. If someone writes overly fancy and clever stuff, I'd ask if they ever have to maintain shit. There is not much value in talking if all candidates would write "import fizz-buzz-solver from 'fizz-buzz-solver';".

You see, the whole Fizz Buzz is nothing more than a prop to allow me to find out what this candidate can actually do. Anyone can include a package and critical thinking differentiate smart ones from the pack. Heh, if there is a package for any and everything, most devs would be flipping burgers instead of doing original work.

Believe me, most problems you think of as original, aren't original. It's not about solving problems either, it's about repacking the solutions into something to sell, or making it popular enough so you can make money off it.

[johnny22]

if leftpad were in the node stdlib, would you still be making the same point about knowing computer science and using leftpad?

in python: https://docs.python.org/3.3/library/stdtypes.html#str.ljust

[fieryeagle]

Yes, until people stopped publishing isInteger and isArray as `packages`. Plus, stdlib is standard library. Can you cite one for JS? NPM is not.