The other kind of JavaScript fatigue
chrismm.com
chrismm.com
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.
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.
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…
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.
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.
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.
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.