
The other kind of JavaScript fatigue - innerspirit
http://chrismm.com/blog/the-other-kind-of-javascript-fatigue/
======
Chris_Newton
Yes, this is a real problem.

The solution, as I see it, is to teach less experienced developers about why
old school ideas like standardisation and curation and longevity and
compatibility are important in the first place. We should be sharing knowledge
about the sound programming fundamentals and good practices that we’ve spent
half a century and change learning. This is particularly true in fields like
web development, where the low barriers to entry and potential for great
success (mostly illusory, of course) attract a lot of practitioners who are
relatively inexperienced and may simply have no idea how much they are
missing.

We shouldn’t be praising those who advocate moving fast and breaking things,
or auto-updating software every few days, or so-called living standards. We
shouldn’t be encouraging a programming style that is one step above join-the-
dots puzzles and colouring by numbers (or downloading random modules from some
package repo and then asking on Stack Overflow how to make them work, as we
call these games in 2016). We shouldn’t be encouraging anyone to treat an
applicant’s GitHub account as their CV, and by extension both encouraging less
experienced developers to pad out their GitHub with trivial reimplementations
of things so they look busy and overlooking anyone who’s too busy doing real
work to play the game. We shouldn’t be encouraging those who want to deprecate
anything older than five minutes and expect the whole world to stop what it’s
doing and update for their convenience. These are the get rich quick schemes
of the software development world, the ways that a few people win big but most
people just produce poorly-conceived, short-lived, low quality work that in
many cases will fail soon afterwards.

Unfortunately, the second set of ideas there have been getting far more
attention than the first lately, and it doesn’t help that some of the biggest
names in the industry are some of the worst offenders. Until some high profile
organisations or established thought leaders start promoting a few more old
school values like building things that actually work and not penny-pinching
at every possible step along the way, it’s hard to see the overall culture
shifting in a more healthy direction, and the best we can do is try to do
better with our own projects.

~~~
EvanPlaice
So you suggest that we should put even _more_ emphasis on Computer Science
fundamentals?

Ad of most jobs don't already put too mich emphasis on mindlessly coding
reference implementations of naive classical algorithms and data structures as
proof of competence.

Encouraging inexperienced devs to embrace NIH (Not Invented Here) Syndrome is
not the answer.

Even poorly supported open source projects will often have better edge case
coverage, testing, and battle hardened code than a prototype produced by a
reasonably experienced dev alone could provide.

The issue isn't whether or not to embrace third-party libraries. Thr issue
that it's very hard to get devs to join/support existing open source libs.

As a dev of multiple libs, one of which is widely used among the JS community,
it's very difficult to promote my lob and draw more users/support. Despite the
fact that the lib has been battle hardened, tested, and in common use by
hundreds of thousands of other devs for over 4 years.

Somebody could easily create a framework specific wrapper of my lib that
garners more stars/forks on GitHub in a matter of months; and worse, most
wrapper/clones never bother to update from upstream so their users are left
using old/outdated code.

If you want to stick to 'old values' then do the work to make existing
libraries better. Don't waste time/resources producing one-off garbage that
contributes to technical debt.

Not sure if you got the memo but the one distinctive benefit of employing
software developers is that we provide the ability to automate away repetitive
work and save the business money in the long-term. Including, saving
development time, effort, and future maintenance by leveraging existing bodies
of work.

Where the code comes from and how it works Is only relevant to software devs.
The everybody else, the only thing that matters is the result it produces and
how costly it'll be to maintain and update in the future.

The sad truth for devs who pride themselves on a strong knowledge of algos and
data structures is, most jobs don't require those skills. Software produced
for profit requires mostly composing an application of existing code, not
writing original implementations.

~~~
Chris_Newton
_So you suggest that we should put even more emphasis on Computer Science
fundamentals?_

I’d say more like engineering fundamentals and robust professional practice,
rather than CS as such.

 _Ad of most jobs don 't already put too mich emphasis on mindlessly coding
reference implementations of naive classical algorithms and data structures as
proof of competence._

The thing is, when you neglect awareness of basic data structures and
algorithms, and understanding of related issues like algorithmic complexity,
you get developers who have no idea why (for example) their framework-based
front-end is horrendously slow, and worse, who then assume they’ll fix the
problem just by switching to React+Redux because They’re Fast™. You get people
who have no idea how to weigh up the pros and cons of different designs, or
where the expensive parts of their code will be, or what to do about those
parts if they’re causing problems. You get people who are entirely reliant on
_other_ people knowing what they’re doing to get acceptable results.

 _Encouraging inexperienced devs to embrace NIH (Not Invented Here) Syndrome
is not the answer._

I don’t want them to embrace NIH. I want them to think critically about the
costs and benefits of developing some functionality themselves vs. reusing
some existing code, and make intelligent decisions.

 _Even poorly supported open source projects will often have better edge case
coverage, testing, and battle hardened code than a prototype produced by a
reasonably experienced dev alone could provide._

I see little evidence of that in any field of programming I have ever worked
in. It seems to me that a great many poorly supported open source projects are
themselves developed mostly or entirely by a single contributor, so unless
that lone developer is significantly better than whoever you have on your own
team, there is no reason to expect their project to be better than what you
would produce in-house just because it’s freely available.

A good example is the now-infamous left-pad package that was a dependency of
some of the most popular and high-profile projects in the JS ecosystem today.
It consisted of a single function that was just 10 lines long, yet within
those 10 lines it still managed to have potentially quadratic time cost,
potentially surprising handling of null input, and potentially surprising
behaviour given various non-English text input.

 _The sad truth for devs who pride themselves on a strong knowledge of algos
and data structures is, most jobs don 't require those skills. Software
produced for profit requires mostly composing an application of existing code,
not writing original implementations._

Well, that’s one way to build software for profit. Whether it’s actually
faster, more reliable, more cost-effective, easier to maintain or otherwise
superior to actually knowing what you’re doing and programming is a different
set of questions. If you’re trying to create something more demanding than a
simple front-end to a CRUD system with modest amounts of data and little
complexity in what you’re doing with it, those questions may be answered very
quickly…

------
matthewtoast
The "other kind of fatigue" mentioned is that we have an overabundance of
tools/interest in making ourselves more prolific, but a scarcity of
tools/interest in improving our code's quality. We chase immediate
productivity at the expense of longer-term survival (and happiness).

I agree with this sentiment, but the problem is barely tractable even at a
small company working in a closed codebase.

The thing about those disregarded edge cases, which OP uses to exemplify the
quality problem, is that there's always an opposite edge! Your fix might be a
bug for someone else. There was one particular beautiful, high-quality,
generalized, and case-covering npm module, but those very facts about it made
it unworkable in one past project of mine, which had strict requirements
around footprint size.

It's funny we use the word "ecosystem" to talk about this stuff. An
interesting parallel is r/K-selection in ecology, where your species either
favors nurturing a small few offspring, or churning out a big swarm and hoping
that a few survive. Elephants vs. lemmings.

~~~
innerspirit
Author here. Thanks for the input.

I think in some cases it can't be argued that a change is only going to be an
improvement, such as in the case of npm lacking proper caching of packages
until very recently.

In the case of package managers, there are a multitude of them and it's up to
the user to figure out which ones have which features, and then go and learn
how to use them. It can be time consuming, and I believe it's more important
to improve this part of the user experience than to make it easier for people
to share their own packages.

------
EvanPlaice
So, what's the solution here? Other than some 'hand wavey' call to action for
devs to work together?

I am the author of a handful of OSS libs, one of which is very popular. Of the
500k+ downloads; not including repo clones, package manager installs, etc I
can count the number of contributors other than myself on one hand.

Considering the relatively recent migration over from Google Code the number
of stars it has is under 100. From the users I've interacted with, I would be
shocked to find that even a small fraction of them understand how it works.

From the 4 contributors, except for one useful bugfix (that introduced another
bug), their impact has been mostly insignificant.

At one point, one impatient dev requesting a fix forked and atrempted to
assume ownership of the project. But that dev disappeared soon after and just
left more work for me to clean up after.

So, do tell. Aside from marketing the hell out of it on blogs and referencing
it on SO by answering relevant questions, where do I go to find other
passionate OSS devs to help support my project.

It's easy to find contributors on projects that require only general
knowledge, such as building a website or creating collections of links.

For anything that requires even a little specialized knowledge, it's difficult
borderlining on impossible to find help.

I don't need contributors with specialized knowledge. I need contributors who
can provide more working examples, better documentation, and can improve the
tests.

~~~
innerspirit
I believe sites like [http://up-for-grabs.net/](http://up-for-grabs.net/) and
[https://openhatch.org/](https://openhatch.org/) are the kind of communities
that we need more of.

There is an attitude where people create projects to feed their egos, and
giving help on existing projects doesn't seem to fulfil egos so much.
Unfortunately, marketing your project is necessary, and for now the only idea
I can give you is that we need to build tools to make that job easier.

------
manibatra
Completely agree. I have found myself more often than not trying to "bet"
which framework I should learn next that will give me an edge. And this always
leads to the fear of missing out and sometimes learning seems a chore.

