To understand why this class exists, we need to first analyze how you code now, and then we can talk about why this does not scale beyond the classroom.
Most of your coding experience probably consists of projects with less than 100 lines of code.
How do you manage this code?
Some line counts for a few projects I work on:
At these sizes, just working with the code (distributing, sharing, etc.) becomes a non trivial task.
We need a way to backup our code, track changes, and avoid conflicts with coworkers–at scale.
How do you test your course projects?
Manually testing large codebases is, literally, not possible without doing a poor job.
The number of paths in your code to test grows exponentially! If the time you spend testing does not, then you are not testing your code.
Even writing tests for large codebases is not possible if the code is written poorly.
Accordingly, we need to automate testing and write our code in a way that makes it feasible to write sufficient tests.
How do you build your code?
Do you even know how you build your code?
As projects grow in size and complexity, even compiling, building, and deploying your code becomes a problem.
We can not rely on manual steps!
Instead, we must automate the build process (including testing!) to ensure that we can deliver code in a reproducible, safe way.
Ideally, we automate deployment as well.
How hard is it to maintain your code after a year?
You don’t know, because you throw it away after a week!
In the real world, your code will live for years (or decades) and will have to be maintainable by the unlucky individual that gets stuck with your legacy code.
Often, you are that unlucky individual.
Also often, you will not even understand your code if you are not careful with how you write it.
We can largely conquer these problems (and more) by simply caring about our code and automating all the things.
Humans suck at coding and we must humbly accept all of the help we can get from tools, processes, etc.