> School teaches us that reusing someone elses code is cheating

No, school doesn't teach this. School just teaches that trivializing an assignment by using others code is cheating, since the point of school is to learn how things work and not learn how to find, evaluate and use libraries.

You could argue that school should better teach library usage, but that is a very hard topic to teach, what would the assignments look like? Would it be a case problem? Like you get a list of current dependencies, an overview of your team members skills, the task you are supposed to solve and then you go out looking for actual libraries and get graded based on how well your choice aligns with the professors?

A good school would give each student a novel problem to solve for their exam grade, instead of wasting brainpower on redundant exercises.

Whose brainpower is cheaper: the professor generating 30-300 novel, unique programming challenges at an appropriate (and identical) difficultly level per course per semester, or the student who's paying to be educated?

That's called graduate school, and because it's so hard to do the teacher can only take a handful of students every decade.

The whole idea of open source is to remove barriers to building on other's code. This isn't cheating. Ignore what school taught you, but make sure you follow the ideals of the license, and try to pass it on if possible. Also, if you import a library, try to actually understand what it does. This is sometimes an unreasonable request (for example libsodium is a gateway to madness/enlightenment) but you should make an effort to understand the code you're importing!

> for example libsodium is a gateway to madness

Nod.

School teaches us the worst possible thing is test failure, so better play it safe and avoid writing original code as much as possible.

As a front-end web developer there are only 2 APIs to learn: DOM and web API (the html5 and browser stuff). Both of those APIs are well documented industry standards. Both change more slowly than the average developer’s career and are almost entirely backwards compatible to their first versions. In short you almost never have to relearn the standards, they always work as designed, and risks of cross-browser failures are largely years in the past.

Yet most front-end developers are scared shitless of writing to the standards directly, because that means writing original code and putting their name on it. Better to play it safe with a giant monster framework and 1000 NPM packages in order to bind some CSS to a piece of dynamic content. The commonality of invented here syndrome suggests that not spending the time to use common libraries is what’s cheating.

https://en.m.wikipedia.org/wiki/Invented_here

However, is this how we get into situations like npm, with everyone using other people's libraries and having so much bloat? Where is the balance if any? I don't have an opinion either way, just putting it out for discussion.

I will write here that you should use libraries. Then next week you will see me complain about an app having two million dependencies... Here's how I find balance: I try to use "battle tested" code rather then writing my own. eg. other people's libraries. But I try to keep the dependencies down. If a package has 10,000 files I rather just rip out the functionality I need. (So I hate when you can not do that, eg. if every function in the code is dependent on every other function.) Often I find issues and are either too lazy to send a "merge request" or the maintainer refuse to merge it. So in many dependencies I often end up using my own fork.

Dependencies are a two edges sword. It's good that you get security updates. But if you can't review all the changes, security issues can also sneak in. Like if someones npm account get hacked and the hacker sneaks in a remote shell or backdoor. Those can be hard to find if you got millions of dependencies which get tons of updates every day. So I usually lock down dependencies, and NPM becomes a fancy tool for copy/pasting.

Every npm library has its own copy of its dependencies. This duplication is what causes the huge number of dependencies.

This duplication is necessary because npm is not a curated software distribution designed to work as a cohesive system. Anyone can push software to npm. As a result, there are packages that depend on different versions of the same library and they must have their own individual copies of the dependency in order to work. This isn't the case in a Linux distribution with maintainers: there's one instance of the package that's shared by all other packages.

School presents students with artificial rules and an environment that simply doesn't reflect the real world. They call it academic integrity but it's really just artificial difficulty. In the real world, people work together as a team, they build on top of each other's work, they have free access to reference material... The real world is pretty much the opposite of a school exam or assignment.

In school, people have to prove themselves by doing stuff without any support whatsoever, only to be punished for any and all mistakes. All grades are final: there is no opportunity to review one's mistakes, learn from them and get re-evaluated. Either get it right the first time or risk failing the course. Of course people cheat: the cost of failure is simply too high. Outside school, people use every trick in the book to lower cost and risk; somehow that's not acceptable in school.

If school is currently teaching this, it is seriously failing its mandate. This does not mean that using sort(3) as a solution to a sort assignment should be acceptable.

School, if it is not merely using you as a source of revenue, is trying to teach you to understand something about the technology, as there is more to making good software than copying existing stuff.

Most problems solved with technology are like this, stringing together the right libraries with a thin layer of business logic.

However many startups or research-oriented technology development will require some part of your stack to be reinvented from scratch to solve whatever problem is the premise of the business. In these situations it becomes clear pretty quickly who is comfortable solving technology problems from first principles, situations that these educational exercises are aiming towards.

School wouldn't be too useful if all you learnt was to copy others code.