> CS programs don’t teach you anything about architecture, technical debt, testing, source control, bug tracking, etc.
Bug tracking you can learn in a day. It's more about which tool your company is using than anything fundamentally difficult to understand.
Source control you can learn in three days, and I was (briefly) introduced to git in my CS degree. How source control systems work under the hood with diffs, Levenshtein distance, etc. -- that's the kind of thing CS covers. A CS major understands source control way better than someone who's just been using it for a while.
Testing is more of a habit or practice than a subject to learn about. And you absolutely learn to test your own code if you don't want to fail your assignments, because the professor sure is going to test it.
"Technical debt" is a communication term that was invented to help business people correct misconceptions about how software engineering works. If you mean they don't learn how to make maintainable software, I agree that's not a focus. Maybe it should be. But of course nobody in the industry seems very good at that either.
"Architecture" is a tremendously vague term. Are you talking about large-scale, multi-system architecture? The MVC architecture? A web tech stack? Most of those things are either just putting together things you already know, or a subject that you can learn about in a CS degree if you want.
No you can’t. You can learn how to use a specific bug tracking tool in a day. That’s not related to learning how to write/use/organize/prioritize bugs.
This is something that all of my junior engineers sucked at at Google and it took months of prodding to get them to write useful bugs and years before understanding how to prioritize bugs.
> Source control you can learn in three days, and I was (briefly) introduced to git in my CS degree. How source control systems work under the hood with diffs, Levenshtein distance, etc. -- that's the kind of thing CS covers. A CS major understands source control way better than someone who's just been using it for a while.
This is completely wrong. Knowing how a diff is generated is completely useless when learning how to use git, perforce, whatever. 99% of learning source control is about the concepts of that particular tool and how to manipulate them (e.g. branching, rebasing, squashing, merging, cherry-picking, etc).
> Testing is more of a habit or practice than a subject to learn about. And you absolutely learn to test your own code if you don't want to fail your assignments, because the professor sure is going to test it.
This is what someone who knows nothing about testing thinks testing is. Running code before you submit it is a specific type of test, and it’s a pretty bad one. Making code testable involves architecting your code in specific ways and knowing when to use fakes, mocks, functional tests, unit tests, fuzz tests, performance regression tests, etc.
To claim it’s just a habit or practice you follow just right before you submit is a joke. This is one of the hardest thing to train new grads on when they join a company. Part of it is they have notions like yours implanted by completely out of touch CS professors and grad students.
>Technical debt" is a communication term that was invented to help business people correct misconceptions about how software engineering works.
CS doesn’t teach people how software engineering works either. That’s the point.
> Most of those things are either just putting together things you already know, or a subject that you can learn about in a CS degree if you want.
No, you cannot reasonably learn about these things in a CS degree because they are completely uninteresting from a CS academic perspective so the professors don’t care about it. A professor who teaches you about the lambda calculus is just as qualified to teach you about making a maintainable and scalable service as the professor who taught you newtons calculus.
The whole point is that CS only has a small intersection with writing software at the leading tech companies and an even smaller intersection with writing software at normal businesses. It’s useful for distinguishing between new grads but it’s garbage compared to industry experience.
I say this as someone who got a phd on the CS side and then went to Google. They are just completely different universes.
Bug tracking you can learn in a day. It's more about which tool your company is using than anything fundamentally difficult to understand.
Source control you can learn in three days, and I was (briefly) introduced to git in my CS degree. How source control systems work under the hood with diffs, Levenshtein distance, etc. -- that's the kind of thing CS covers. A CS major understands source control way better than someone who's just been using it for a while.
Testing is more of a habit or practice than a subject to learn about. And you absolutely learn to test your own code if you don't want to fail your assignments, because the professor sure is going to test it.
"Technical debt" is a communication term that was invented to help business people correct misconceptions about how software engineering works. If you mean they don't learn how to make maintainable software, I agree that's not a focus. Maybe it should be. But of course nobody in the industry seems very good at that either.
"Architecture" is a tremendously vague term. Are you talking about large-scale, multi-system architecture? The MVC architecture? A web tech stack? Most of those things are either just putting together things you already know, or a subject that you can learn about in a CS degree if you want.