Participant code,reasons for using trivial packages,Author#1,Author#2,agreed
P1,"""You make small focused modules for reusability and to make it possible to build larger more advanced things that are easier to reason about.""

""I want programming to be easier. Making it easier to build durable systems. And the way forward in my point of view is definitely not reinventing everything and everyone making the same stupid mistakes over and over.""

https://github.com/sindresorhus/ama/issues/10#issuecomment-117766328",[Increased Productivity],[Increased Productivity],[Increased Productivity]
P2,"I think the premise is wrong, left-pad/binary sort etc are not trivial. Some other packages are, and should not be used. ",[No reason],[No reason],[No reason]
P3,Already-optimized solutions to not-always easy problems,[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P4,1. not rewriting the same function 10 times in 10 projects. 2. there may be a more elegant/efficient/correct/cross-environment-compatible solution to a trivial problem than yours. 3. saves time 4. code-reviewers don't have to check your custom implementation if a trivial package is already known to implement something correctly,"[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity]"
P5,"Widely used and tested, less bugs, standard community agreed code.",[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P6,It makes more sense for code organization and reusability of code. It's much faster to install a package and require it in multiple files than to write it myself.,[Increased Productivity],[Increased Productivity],[Increased Productivity]
P7,"A lot of these ""trivial"" packages are (or can be) used on many projects. By breaking it out into a standalone module I have the ability to share it among all projects and thoroughly test it in isolation. Copying and pasting code from previous projects is inefficient and inelegant. I personally prefer to `$ npm i -S is-blank`. This also ensures that when a bug is found, it can be fixed in one spot and pulled in by all dependents. Each trivial module is like a lego block. If they match a sound and predictable API we can build something great without having to deal with the triviality of utility functions. A related issue I often reference: https://github.com/sindresorhus/ama/issues/10#issuecomment-117766328",[Increased Productivity],[Increased Productivity],[Increased Productivity]
P8,"No ""trivial"" task in programming is ever fully solved. To write it yourself is to assume no progress will ever be made in this problem for the rest of human programming. ",[Increased Productivity],[Increased Productivity],[Increased Productivity]
P9,"""Trivial"" is a relative, ever-changing line. As JS evolves, fewer ""trivial"" things are necessary ��� but they may exist for environments that don't provide them. Sure, fillLeft exists now, but if you're writing a browserify app for IE8, fillLeft might not be available. OTOH: I think piping streams together is trivial. I still wouldn't object to someone using npm.im/mississippi, if that makes them more comfortable!",[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P10,"Not having to write them, should be part of the standard library or a toolset",[Increased Productivity],[Increased Productivity],[Increased Productivity]
P11,It's well maintained and has tests specific for that particular task. Divide and conquer ,[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P12,"Consistency, reduplication between deps, documentation, reliability.",[Well implemented & tested],"[Well implemented & tested,Increased Productivity,Well maintained code]",[Well implemented & tested]
P13,"Testing. I generally confirm that a trivial package has passing unit tests before using it. It is also good to see that there have been multiple versions and resolved github issues, as this shows that the lib has been used and improved from user feedback. And it does save time to not have to think about how best to implement even the simple things. Sometimes what sounds trivial can have weird edge cases that a mature library, like deep-equal, will have addressed.","[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity,Well maintained code]","[Well implemented & tested,Increased Productivity,Well maintained code]"
P14,"Often small bits of code still have edge-cases, and why spend the time if you know it is available and already done.","[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity]"
P15,"See above.  Plus if a package serves to do something like ""change the shape"" of a trivial function such at it can be used in a different context (i.e. a more functional way in JS code).",[Increased Productivity],[Increased Productivity],[Increased Productivity]
P16,The primary advantage is to outsource the need to test or maintain the code for common tasks.,[Well implemented & tested],"[Well implemented & tested,Well maintained code]","[Well implemented & tested,Well maintained code]"
P17,"Generally packages are already well tested and used by a wide variety of developers. It mean more stability, less antipaterns. The API of the functions the package provide is relatively known. So it helps for future developers to pick up the code, if this is a package they already know.",[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P18,Someone else has made sure it is right and maintains it. Saves me time.,"[Well implemented & tested,Increased Productivity,Well maintained code]","[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity,Well maintained code]"
P19,"Reduced complexity on my part, and hopefully they've worked out the edge-case bugs.",[Well implemented & tested],[Well implemented & tested],"[Well implemented & tested,Improved readability & reduced complexity]"
P20,Some ���trivial�۝ packages cover edge cases and for some some use cases those edges matter.,[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P21,"nothing, when a native javascript option becomes available or is added to the language, that's always the preferable option",[Increased Productivity],,[Increased Productivity]
P22,A trivial package may utilise best practice for an implementation of which I have no prior experience with.,[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P23,"covering edge cases, can speed up writing proofs of concept, lowers barrier to entry for and educates junior devs how to implement feature X","[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity]"
P24,"Sometimes is just the syntactic sugar that I'm used to, and my team is used to.",[Improved readability & redced complexity],[Improved readability & reduced complexity],[Improved readability & reduced complexity]
P25,"If the team knowledge isn't uniform, trivial tasks can be made wrong",[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P26,"Avoiding edge case debugging, code bloat, consitient API (was is (str, len) or (len, str) ?",[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P27,"Don't reinvent the wheel! If the task has been done before, it's likely been done better. People should think carefully about re-architecting code that is already in the public space, especially if that code is well tested and generally well maintained.","[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity,Well maintained code]","[Well implemented & tested,Increased Productivity,Well maintained code]"
P28,"having more eyes on the code, tests, battle-proven",[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P29,"Even when I write the code myself, I still make it a module that I use. Is the question perhaps intended to be about the advantages of using others' code? If so, that is obvious: I didn't have to write the code.",[Increased Productivity],[Increased Productivity],[Increased Productivity]
P30,0) A false premise. I have written many of these packages I use. 1) May already have tests. 2) No code duplication; easy shared updating.,[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P31,Speed.,[Increased Productivity],[Increased Productivity],[Increased Productivity]
P32,dry,[Increased Productivity],[Increased Productivity],[Increased Productivity]
P33,Reduce the likelihood of introducing bugs by using a well-vetted implementation.   ,[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P34,Immediate clarity of use and readability for other developers for commonly used packages,[Improved readability & redced complexity],[Improved readability & reduced complexity],[Improved readability & reduced complexity]
P35,especially in javascript relieves you from thinking about cross browser compatibility for special cases/coming up with polyfills and testing all edge cases yourself. Basically it's a substitute for the missing standard library. And you do not depend one some huge utility library of which you do not need the most part.,"[Well implemented & tested,Increased Productivity,Better Preformance]","[Well implemented & tested,Increased Productivity,Better Preformance]","[Well implemented & tested,Increased Productivity,Better Preformance]"
P36,"I usually don't use trivial packages but sometimes if one of my dependencies uses a trivial package, and I need it, I reuse it as I'm indirectly depending on it anyway.",[No reason],[No reason],[No reason]
P37,Same as for 'non-trivial' packages. Code reuse. Correctness. Centralized maintenance. Discoverability.,"[Increased Productivity,Well maintained code]","[Increased Productivity,Well maintained code]","[Well implemented & tested,Increased Productivity,Well maintained code]"
P38,It saves time in some cases,[Increased Productivity],[Increased Productivity],[Increased Productivity]
P39,"There has not been enough research on this, but I've been taking note of people's proposed ""quick and simple"" code to handle the functionality of trivial packages, and it's surprised me to see the high percentage of times the proposed code is buggy or incomplete. It would be interesting to look at relationships between github issues and self-coded implementations of the functionality from trivial packages.",[Well implemented & tested],"[Well implemented & tested,Increased Productivity]",[Well implemented & tested]
P40,Saves time and effort for small/short lived projects. Easy to read and understand internals of it.,[Increased Productivity],"[Increased Productivity,Improved readability & reduced complexity]","[Increased Productivity,Improved readability & reduced complexity]"
P41,"Being able to rely on small 'trivial' packages, reduces cognitive load. Although it wouldn't be hard to implement left-pad myself, it would still take a few minutes and a context switch. By using left-pad, I am saving myself time and energy. One of my favorite programming sayings is ""Let Jeff do it"", why write a left-pad function, when I could get Jeff to write it for me?",[Increased Productivity],"[Increased Productivity,Improved readability & reduced complexity]",[Increased Productivity]
P42,Proven solutions mean less time finding edge cases. Copy-pasting isn't good enough since there is no indicator of code quality. Stars on github help social-proof the best implementations. ,[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P43,"Trivial' is very subjective and I have a hard time believing, based on the questions being asked and the packages you are targeting, that your research will provide any value or insight.

Apparently you believe shell-escape and core-object are trivial packages. 

Yes, the code for shell-escape is simple but the regex behind the character replacement is not exactly trivial. In that particular case It would be foolish to waste my time researching which characters require escaping for my use-case and then looking up the regex necessary (because I'm not well versed in regular expression). Annnnd then writing tests to make sure I really did cover all the bases is another time dump. No thanks.

And that leads us to the core-object package. The pattern used here is very well known and easy enough to implement on your own. What is not particularly easy to implement is a nice way to call `_super` from inside overwritten methods. There are several ways I've read about for accomplishing this and I happen to really like the pattern used in core-object. I also know the package's developer to be extremely talented. Annnnd again the tests. This package also comes with tests so I don't have to worry about writing my own.

I do not believe these packages to be considered trivial. With that said there is still an advantage to small or trivial packages: time saved and test coverage. Both of those can lead to being a more proficient developer.","[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity]"
P44,Darwinism,[No reason],[No reason],[No reason]
P45,Even tasks seeming trivial can be optimized. Also a highly used trivial package is probable to be well maintained. Hence one can outsource maintenance this way. Also it reduces duplicate code (summed over all available packages).,"[Increased Productivity,Well maintained code]","[Well implemented & tested,Increased Productivity,Well maintained code]","[Well implemented & tested,Increased Productivity,Well maintained code]"
P46,Is less expensive and more expresive,[Improved readability & redced complexity],[Improved readability & reduced complexity],[Improved readability & reduced complexity]
P47,Simple abstract brings less complexity,[Improved readability & redced complexity],[Improved readability & reduced complexity],[Improved readability & reduced complexity]
P48,"Save time, code reuse",[Increased Productivity],[Increased Productivity],[Increased Productivity]
P49,"First, I generally write my own so-called trivial packages.  Second, they may be small, but I disagree that they are ""trivial"" in that they generally encapsulate a subtle piece of logic I don't want to get wrong ever again.  So a ""pad"" function will provide me with consistent way to pad digits; my ""config_okay"" module gives me confidence that every config file is always chmod 0600 and js or json encoded, etc etc.",[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P50,"Reuse, well tested, someone else has already thought about the problem","[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity]"
P51,"If it helps to progress faster than it should be used. Trivial packages are not as trivial as we think, some packages have good testing and have covered all aspects, which one might forget while implementing it's own logic.","[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity]"
P52,They are not as trivial as you might think (error checking etc.).,[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P53,"Ideally the only advantages exist if you're not working in/for production - trivial packages to get quick proof of concept node apps off the ground are likely to be fine, but that's the only real use case I can think of. ",[Increased Productivity],[Increased Productivity],[Increased Productivity]
P54,"Well tested code, place to share bugs and usage, keeps focus on problem domain, standardised knowledge of how to do the same thing shared between projects and developers",[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P55,re usability,[Increased Productivity],[Increased Productivity],[Increased Productivity]
P56,"It's very easy to miss edge cases in ""trivial"" code.  Using an isolated module that is well-tested and vetted by a large community helps to mitigate the chance of small bugs creeping in.","[Well implemented & tested,Well maintained code]","[Well implemented & tested,Well maintained code]",[Well implemented & tested]
P57,It is tested. It works as expected. The function is clear. I would need to google it anyways and other developer might need a similar function. Less copy paste.,"[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Improved readability & reduced complexity]","[Well implemented & tested,Increased Productivity]"
P58,Avoid repeating the same code.,[Increased Productivity],[Increased Productivity],[Increased Productivity]
P59,Hopefully they handle edge cases.,[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P60,"Using known working, tested code. ",[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P61,"A trivial package is not always marked as such.

Sometimes, you think a problem is complex and you search for a package to solve it (example: finding minified files from your application dependencies - seems very complex for a Gulp novice, but is solved with 3 lines of code). The package's code may be really simple. But since you expect this package to save you time, you do not inspect it, you only verify it works and solves your problem.

Sometimes also, you use libraries that solve many trivial use cases. But they are all gathered in one place. This code is tested and used by many, which makes it more trustful and reliable.",[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P62,"JavaScript needs a standard library, and 'trivial' packages are a kind of scar tissue that's formed in its absence",[Increased Productivity],[Increased Productivity],[Increased Productivity]
P63,Well tested. Less redundant bytes on the client side. Saves time.,"[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity]"
P64,"fast prototyping? don't know, I am more a designer than a developer",[No reason],[No reason],[No reason]
P65,These packages are tested by many other developers.,[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P66,Minor time savings,[Increased Productivity],[Increased Productivity],[Increased Productivity]
P67,"For some, like sanitize-filename, there could easily be new edge cases detected and if I can get updates to cover the edge cases with minimal effort then I have made a gain.",[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P68,"Tests already written, a lot edge cases captured (https://github.com/sindresorhus/ama/issues/10)",[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P69,"As with any open source project; it can cascade fixes to bugs and issues found in the code. Also if a method is missing on older/other versions of the environment you're running under that can make it more resilient. The solution, how small it even may be, will most probably be very very well tested.

And if anything should happen to the external dependency, it is a trivial thing to switch to another external dependency or built inhouse if no fully compliant alternative exists.","[Well implemented & tested,Well maintained code]",[Well implemented & tested],[Well implemented & tested]
P70,Code readability for a team,[Improved readability & redced complexity],[Improved readability & reduced complexity],[Improved readability & reduced complexity]
P71,"Guaranteed implementation each time. Although you could extract the functionality yourself, by the time you have written this module then you could also have 'npm install'ed it, along with the guarantee that being open source and highly visible, the odds are that the external implementation you sourced will be error-free and continuously updated (without your input) to encompass any advancements or suggested improvements - so will always be the 'best version available'. However, as above, this does not apply to one-line implementations (such as a package to call isArray - that's really a thing?).","[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Well maintained code]",[Well implemented & tested]
P72,Likely to be well-vetted,[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P73,"Well-tried solution, easily used in your project",[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P74,There are none.,[No reason],[No reason],[No reason]
P75,"Depends on the level of ""trivial"". Packages are great for having professional, well written code. ",[Well implemented & tested],[Well implemented & tested],[Well implemented & tested]
P76,"Others use frameworks �ۡ���� I use trivial packages. Framework could be bad, or the network delivering these micro packages, as was the case with NPM.",[Better Preformance],[Better Preformance],[Better Preformance]
P77,If the package doesn't use up to much space and speeds up development time it can be worth it,"[Increased Productivity,Better Preformance]",[Increased Productivity],"[Increased Productivity,Better Preformance]"
P78,"Don't like repeating myself. Sure, I could build up my own library over time, but why not just reuse existing code.",[Increased Productivity],[Increased Productivity],[Increased Productivity]
P79,Saves development time,[Increased Productivity],[Increased Productivity],[Increased Productivity]
P80,"Not reinventing the wheel, leveraging feedback from a larger community to fix bugs, etc. ","[Increased Productivity,Well maintained code]","[Increased Productivity,Well maintained code]","[Increased Productivity,Well maintained code]"
P81,is it faster to code or type install,[Increased Productivity],[Increased Productivity],[Increased Productivity]
P82,Less error prone than writing it myself. Quicker than copying it. ,"[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity]","[Well implemented & tested,Increased Productivity]"
P83,no advantage,[No reason],[No reason],[No reason]
P84,"The biggest and most impactful advantage that I've observed with these 'trivial' packages is simply that it makes software development easier.  I can't tell you the number of times where I was working on some project with a clear goal in mind, but I ran into a few obstacles that made it more difficult to achieve the end result.  I'd have to do research on how to solve a particular problem, peruse questions and answers on StackOverflow, Reddit, or Coderanch, and find the most recent and readable solution among everything I've found, then write it myself.  Why go through all of this work when you can simply `require()` someone else's solution and continue working towards your goal in a matter of seconds?

The npm ecosystem makes it extremely easy to do this, and this undoubtedly makes development easier.  I have successfully gotten several colleagues and friends (some with no programming experience at all) interested in JavaScript development because of how easy it is to use and consume these 'trivial' modules.  Anything that makes it easier for people to get involved in the software community is a good thing, in my opinion.

If you're interested, Sindre Sorhus has a pretty good post about this issue here: https://github.com/sindresorhus/ama/issues/10#issuecomment-117766328

In the enterprise, I think trivial npm packages make your codebase more readable, and every company that I've worked at values this above all else.  The book ""Clean Code"" by Robert C. Martin does a pretty good job of explaining the importance of extracting your code into tiny, re-usable helper functions, and trivial npm modules seems like a pretty good implementation of this idea.","[Well implemented & tested,Increased Productivity,Improved readability & redced complexity]",[Increased Productivity],"[Well implemented & tested,Increased Productivity,Improved readability & reduced complexity]"
P85,quickuse,[Increased Productivity],[Increased Productivity],[Increased Productivity]
P86,"""trivial package"" that you flagged down in my repo (ejsify) is short, but that alone doesn't make it trivial. it requires some knowledge to implement, it is a interface towards a nontrivial system (browserify). I don't want to spend a few hours reading documentation and then implementing it if I can reuse a community effort.

People in general used left-pad as it is very commonly written 10 lines and they don't want to rewrite themselves every time, and is missing from whatever small helper function library they used (underscore?) They don't want to start their own lib with left-pad as they don't care / know how to npm. That's maybe the only crime, I regularily chug my own helper function library around with me in all projects, left/right/pad was actually a part of it.",[Increased Productivity],[Increased Productivity],[Increased Productivity]
P87,"For left-pad or isArray where the code is unlikely to change for the years to come, I would probably avoid using them. However for things like git-rev that actually depends on a software that will change, I would rather fix it there than in all projects that are based on it.",[Well maintained code],[Well maintained code],[Well maintained code]
P88,There is no reason to do this other than copy-paste programming,[No reason],[No reason],[No reason]