Great. Then get the universities to stop lying to kids who say "I want a job."
Yes. In general, it's a real problem.
I have yet to see a single Art History curriculum include a Deep-Fryer Cleaning course. If universities aren't going to prepare students for the jobs they're going to have, then they shouldn't lie to kids about it.
First, a more minor point: Mechanical engineering is a university subject, even though it isn't physics. What you call "Trade School" is really software engineering; it is properly also a university subject, rather than something that should be dismissively consigned to trade schools. (It could be taught there as well, of course, to the same degree that mechanical engineering is - which I suspect is not much.)
My larger point: According to your thinking, then, we need to take the people who are studying computer science, and move maybe 98% of them to a software engineering major. If CS is what you define it to be, we absolutely do not need as many CS graduates as we have people enrolled in CS.
What we currently have is that the schools think they should be teaching CS (per your definition), and both the students and the outside world are expecting the courses to teach what is actually useful out in industry - software engineering. I could actually see this as a useful split (we separated physics from mechanical engineering). But then CS becomes "that computer thing you take if you want an academic career", not what you teach all the people who are trying to get a job. CS loses the vast majority of its students, and with it, much of its prestige.
But I think you're underselling the value of pure computer science compared to the software engineering discipline. Physicists don't have to go into academia, they can ply their trade applying physics, collaborating with engineers on the cutting edge of semiconductor manufacturing, aeronautics, space exploration, and so on. Before a field is ready to be turned into engineering, the early work is usually done by physicists.
Sure, there's hopefully no need to account for novel physics when you're building a bridge - all the theoretical models engineers need have been worked out long ago (by physicists). But if those same engineers were working on a space-elevator? They'd bring along some physicists to help figure out the new stuff they were going to encounter.
The same applies to the software domain, too: before something like deep learning can be engineered into regular products, it's going to be computer scientists who work out all the details - and not just in an academic environment, they're doing it in industry, working with engineers to turn theory into practice.
Seems like the trade school component is being at least partially covered by the Bootcamps popping up. And just like some CS programs expect you to then go out and learn how to be a software engineer (usually via jobs), there's an expectation in these Bootcamps that then you'll go out and learn the deeper/broader CS components you missed out on (usually via jobs).
These aren't problems, these are things you learn in a matter of weeks/months from on-the-job experience. Why would you expect a recent graduate to have that? And why would it even matter?
If someone is smart enough to talk about data structures competently in an interview, don't you think they could learn git?
I swear people must be conducting interviews to try to feel smarter than the candidate rather than to find a person who can do a job.
I would argue you can learn the efficiency of a binary tree search in a few months on a job too. And no, often times those people can't learn git on the job because in so doing the mess things up so thoroughly in the repo half the time you have to rewrite history to clean up a bad push.
I've seen it happen and this is not an issue of people trying to be smarter than the person they're interviewing. In point of fact, I just had an interview with a company where I'd be forking and improving open source code for building modular website content blocks and they asked me to write a bubble sort algorithm.
Trivial, but I hadn't done it in 12 years since college. Now quicksort, that's actually useful, but a bubble sort? I got a little tripped up, remembered it eventually, but the whole time the "bad cop" in the interview was checking his phone, sitting cross legged on the heater and talking about his adjunct position at local, minor university. Who's trying to look smart?
> A CS education is great for those who wish to pursue it as a purely academic exercise, but a person with solely a formal CS education is woefully under prepared for employment as a software engineer.
This sums up the root problem, to me. Many comp-sci programs are run with an eye towards arid, abstract wisdom, not marketable skills. That's not inherently bad, and it's true of many degree programs--no one goes into a philosophy major thinking that it'll be a good career move; they do it because they love philosophy. The problem is that the philosophy department is honest about that fact. Advisors tell bright-eyed would-be programmers that they'll just love the CS program when they should be telling them to turn around, walk out the door, and check out the technical college across town. By the time the kid discovers the lie, he's down five years and $30,000 will not much to show for it.
Well said, and honestly, I think this goes deeper than just CS. It's probably a shitty thing for me to argue standing here with a BA, but I don't think the vast majority of people earning BA's today are actually using universities and colleges for what they were designed for. We need voc-ed and technical schools to not be shameful any more. There is nothing wrong with wanting to learn how to code without wanting to learn higher level mathematics along the way.
I promise you that not every electrician understands the subtly of homogeneous layers in high frequency integrated circuits. Nor do the vast majority of people actually building things with computers need to understand the draw backs to using a binary tree over a hash table. Sure, it'd be nice to be curious and want to learn more, but you don't need it to be competent.
I feel that having a CS background has made it easier for me to pick up new skills throughout my career. I hear colleagues talk about things being challenging yet I've never struggled with them. Why? Because I can recognize the underpinnings of the whole thing
This article has, as an analogy, a premise similar to: "Materials science graduates make rubbish bricklayers."
Computer science is not software engineering, just like materials science is not structural engineering, and neither of those is that closely related to building a bridge or a building. Most of what we call "software engineering" is actually closer to what an engineer would call a "technician" in any other practical field.
I've met many, many "computer science" graduates who are barely aware of the "science" element of what the field contains. This isn't helped at all by those of us in the field (and our academics who teach us) happily mixing up the terms "computer science", "software engineering" and "programming".
Scientists expand the range of human thought in the field by discovering new truths, such as algorithms, design patterns, and conceptual relationships. Engineers turn these truths into techniques and building blocks/frameworks, and maybe designed solutions. Technicians take the building blocks and techniques and make artefacts, hopefully using best practices.
We're suffering from the fact that our field is less than a century old, in real terms, and neither the terms for these things, nor indeed the techniques and literature, have become concrete.
I also imagine that fresh civil engineering graduates also make pretty rubbish bridge designers. They still need a few years working in the industry to understand how actual bridge construction projects work in the real world. It seems unlikely that a couple of fresh Civil Engineering graduates from a hot school could set up a startup to disrupt the bridge-building industry and expect to successfully bid on major civil works projects.
You're unlikely to find a scientist or structural engineer that designs a bridge physically putting it together, but the best or only implementation of an algorithm is often made by its' inventor. The line that separates technicians from designers and scientists is much blurrier in computer science etc. than most other fields.
> The line that separates technicians from designers and scientists is much blurrier in computer science etc. than most other fields.
I think that the GP provided a reasonable explanation for this situation by saying that the "field is less than a century old". If you go back in time you are more likely to find one person inventing a new brick, designing a house with it and then building it. But later when the body of knowledge was too big for one person, specialization started (the same happened in medicine and many other fields).
And actually it is already happening in the IT area. Just several years ago it wasn't uncommon that a game or any other non-trivial piece of software was created (including some clever "inventions") and marketed by one person.
> This article has, as an analogy, a premise similar to: "Materials science graduates make rubbish bricklayers."
Computer science is not software engineering, just like materials science is not structural engineering, and neither of those is that closely related to building a bridge or a building. Most of what we call "software engineering" is actually closer to what an engineer would call a "technician" in any other practical field.
There's a lot of people in this thread saying the same thing. You're not wrong in the abstract, but in saying "haha, this article doesn't understand computer science" you're missing the hugely important point that most universities also don't understand computer science, or else knowingly lie about it to increase enrollment. If a starry-eyed high school kid shows up for a campus tour and says "I've always wanted to be a bricklayer," nobody is ever going to tell him "Oh, we have a wonderful materials science program that you'll just love"; but that was exactly the experience that I had with CS, along with many millions of other would-be programmers.
you're missing the hugely important point that most universities also don't understand computer science, or else knowingly lie about it to increase enrollment
Not at all. It's pretty central to my point that both we in the industry and the academics who teach us are mixing up the terms and not paying heed to the "science" in "computer science" (and I said as much in the comment).
I agree that the starry-eyed kid who wants to write apps and games would likely be turned away if he was faced with actual computer science instead of what is sold as such: If you showed him TAoCP and said "This is an example of broad-based computer science", he'd get blurry-eyed instead, because there is no visible relationship between one end of that desire and the other.
But that might not be a bad thing if we get our stuff together and fix our expectations and our terminology: An 11 year old tinkering with electronics in her bedroom, or mixing up colours and smelly stuff with her "my first chemistry set", or dragging her family fossil hunting in the hills is not doing "science", but she knows that "science" is that way, and at the end of a degree course in science--assuming she doesn't stay in academia--she gets a job as a lab technician, not a scientist; much of that role might actually involve sitting in front of a computer processing statistics and analytics anyway, rather than mixing up fun stuff in a test tube (which, after all, is what she was originally passionate about). The technician stuff is not what she wanted when she was 11, but it's still a part of the journey, and the science education is what sets her up for later participation in chemical engineering work or even some actual science (if she's very driven or fortunate).
Computer science is also not hardware engineering. A computer science student has no idea how to get trains to report their position, because that requires hardware. For example, sensors laid along the track at reasonably closely spaced intervals which read an RFID transponder carried by the train, and send a message to some concentrator which forwards it to a data centre. It's okay not to have all the answers; transit systems are not a one person job.
A good answer to the question is "I don't really know the specific technology for sensing the positions of trains. If the sensing is used to make automatic driving decisions, it is of crucial importance that it be accurate and reliable, for safety reasons. If trains are automatic, then the system must not only know their positions, but the trains must know that the system knows their position; if a train's computer loses touch with the system, it must come to an emergency stop. A rogue train whose position isn't known must not continue moving, for obvious reasons. I think I would survey how all this has been successfully done in existing transit infrastructures around the world and borrow the best elements from the existing designs".
Is the author of this article suggesting that learning about version control, working in teams, and reading new code will help someone with an interview question about how to design a software system? These seem to be two different things to me.
As a recent computer science student graduate I can relate to this. It's worrisome how many of my classmates are graduating with very little knowledge on how to actually build something, rather than solving little math/CS problems. I was lucky to have taken a startup programming course they taught for one term, in which we were required to build a scalable startup from ground up. Wish me luck finding employment now!
It's nice your college cared enough to offer a startup programming course. If I was looking at CS degree, I would want to see a few courses like this(practical experience) required for the major?
A lot of degrees don't offer much practical knowledge for the real world? With what you people are paying for tuition;
I would demand it from your university though? You students have so much more power than my generation had.
I picture a lot of tenured professors thinking, "Woa--I got them through the textbook! I'm not really prepared to deal with real life situations? After all, I been holed up here for years, and my sabbaticals were basically vacations?"
I understand why most majors can't really prepare the student for the real world, and real world problems. Years ago, I got a degree in Business Administration/Management. It was a joke, and there was really no real world/relevant courses offered. I had one Econonomics Professor give some real world advise, he told us, "If you want to get ahead in business; you will need a red nose--"
He was a returning to teaching from a long stint in the private sector. . His last job was working for Texas Realestate company? He said at lunch--it wasen't uncommon to Have to drink 3-5 cocktails--just to fit in with the guys.
I really dated myself with that comment? It's probally the opposite today? Maybe not in Texas though?
When I was in college, I thought General Education courses were a waste of time. I now look back, and I am so glad I was forced to take so many, seemingly random courses. The courses for my major we a waste of time. I picked business because I was young, and very poor. I was about to drop out, and I figured I needed a degree in anything--so I wouldn't resent paying back those student loans, and maybe go to a professional school? In the 80's, Business Administration was considered a safe degree in terms of employment. If I was to do it over, I would have majored in something I was really interested in! Geology? Engineering?
Art? Philosophy? Biology? Yes--we had CS, but I just wasen't interested in it.(It's such a better major today!)
All I learned from this article is that the University of Maryland's computer science program is terrible compared to the University of Arizona program I graduated from more than five years ago.
Using version control, working in teams (using version control!), working with other people's code, and designing software to meet requirements (in teams!) were all part of the core curriculum. The curriculum even used Extreme Programming (which seems, in my experience, to differ very little from agile methodologies like Scrum) as the model for guiding group/team projects. Not to mention projects where we had to complete assignments on top of provided 'nightmare code' written by a professor.
And pretty much every grad can still tell you the Big-O complexity of the major sort algorithms. Or anything else you'd expect from a "more academic" CS program.
However, I believe the UA program very much tried to combine practitioner knowledge with academic knowledge. (And once again, my experiences were more than 5 years ago.)
I went to a private school with a reputation comparable to Maryland and none of the observations apply there either. Version control is a given for students who collaborate on projects. Maybe the problem is that larger state schools don't have as many project classes.
A co-worker's kid is about to graduate from UMD with a B.S. in Computer Engineering. He has one very good job offer and is likely to have more. He worked on research projects steadily in the school and had internships during the summers.
I don't suppose that he is a typical graduate of the program, but perhaps the one cited in the article isn't either.
I learned a lot in my CS program I probably never would have discovered by myself and much of it is foundational skills I subconsciously use when solving problems. I also understand what the trade offs that need to be made and where my optimization time should be spent.
When in college I did a whole lot of programming using version control (CVS in my time, kids have it good today!), API's and various programming languages. I didn't need my college to teach me these things. It was the application of what I was learning in school.
Also, in college we had a Software Engineering course elective, a Testing course elective and some other more practical course electives that most people took because it was, well, practical skills.
So I think a decent mix of theory and practical skills are best but the it is also up to the student to engage themselves outside their program to learn "real world" skills. That's especially easy for students today with tools like Github and OSS becoming such a huge thing.
Looking at my brother, who is about to finish CS at Columbia, I don't recognize the criticism. He seems to have a good mix of theory and practice. There's a fair amount of grinding ("argh why won't it compile? / Google the error") as well as working with other students. There's also a huge amount of data structures and algorithm stuff that you expect in this sort of course. I didn't see a lot of reading other people's code, but maybe that's in there as well somewhere. I definitely get the feeling there's a lot of mini-projects.
Of course there are things that are much easier to learn on the job, such as how to navigate a huge codebase. Because you'll have time to do that. Also architecture decisions are hard to get right as a novice. You can read around, you can ask people questions, but in the end you need to make mistakes and rebuild to appreciate some aspects.
I just graduated from CU, and I'd agree. Just based on anecdotal evidence comparing w/ friends from Cal, MIT, Harvard, etc, I think all of these 'top' schools do a pretty good job of mixing theory and practice within the required/core CS classes, and then allow the students to decide for themselves which track they want to follow. For instance at Columbia, we have tracks in AI, Applications, Theory/Security (forget the exact name but this is theory & algorithmic heavy), Systems, etc. These tracks comprise several senior / master / phd level courses which you usually take in your last year or two. No matter which track you go into, all CS majors take the same core CS classes in data structures, basic CS/compiler/language theory, statistics, linear algebra, etc.
I can't say that any of the core classes involve navigating a huge codebase... there are certainly some upper level track classes (especially in Systems) that give you that experience, but I do agree that is relatively uncommon.
Honestly so much of the learning happens in extracurriculars (Hackathons, CS/tech clubs, etc) that it's hard to keep track of which skills you learn in classes vs just doing other activities with friends. I think the power of college resides in the strength of such extracurriculars.
How much does Linus and the CIA pay you to suck their dick?
First, the CIA puts all code in the cloud. Then, the CIA plans to ban compilers. People will write html as their jobs and have no clue any other computer programming exists. They will make people think that making a website is the only computer programming.
This issue's been around for awhile. See this post (http://blog.codinghorror.com/why-cant-programmers-program/) from 2007. The problem actually inspired me to create a piece of kinetic sculpture I'll be offering as a series later this month on Kickstarter.
Computer Science is to Programming what Anatomy is to realist painters.
No, learning anatomy will not make you a good painter. However if you are already a painter and want to become great, then you will need to learn anatomy.
The complexity of searching a sorted list is only logarithmic if you have positional random access (it is implemented as an array or an array-like structure). If it is a linked list, the sorting doesn't help; you have to traverse all predecessors of an arbitrary item in order to access it, and that is linear: the sorted order doesn't help.
Usually when we say "list" we mean "linked list": a flexible structure with poor random access, though sometimes the word is an implementation-agnostic designator for any sequential structure.
Sometimes the unfortunate part of the education system is that you have to teach yourself a concept or skill. It's admirable that the individual mentioned was a straight-A student, but its almost meaningless compared to the people who have been teaching themselves how to code, hack, tinker with hardware, etc, since they were a kid.
I read Sean Parker's bio on Wikipedia sometime back and it explained his "autodidacticism". It got him far very early in his life so much that he didn't have to attend college. Granted not everyone has the kind of innate skill that some of these so called geniuses or prodigies do, but you can certainly learn a thing or two from them.
As far as working in teams go, again, nothing is preventing you from gathering two or three of your good friends and building something together, no matter how useless the end product turns out to be in real life. This way, you are not restrained on your idea or your methodology in building, you learn from trial-and-error and build on your experience, and if the product does turn out to be something remotely useful then that is one more thing to write on your resume and talk about in your interviews. Work towards getting your degree and do well, but always work towards making yourself better; don't solely rely on coursework and professors, because that won't take you very far.
FSU CS grad here. FSU offers a BA in CS. Basically it allows you to substitute a minor of your choosing for some of the more academic CS courses (theory of computation, algorithms II) and pure science courses (Stats II, 3 semesters of physics/bio/chem, Discrete II etc).
I minored in business but then transitioned to double majoring in CS and MIS. MIS was more focused on teaching you how to build systems.
My take is if you want to work for one of the big firms tackling problems at scale, then you need the CS and math rigor to get in the door. If you're OK building websites or mobile apps, then most of that CS knowledge is going to go to waste.
For me, machine learning has been the catalyst for getting deeper into math and science. I decided that I'm more interested in ML/AI than building business systems, so I'm going deeper into CS/Calculus/Linear Algebra on my own and I really enjoy it.
38 comments
[ 3.1 ms ] story [ 88.1 ms ] thread(The article begs the question that undergraduate computer science programs are a good idea in the first place)
You're describing a Trade School. I think Trade Schools are a decent idea.
But learning the trade SHOULD NOT be what they teach in a Computer Science curriculum.
Yes. In general, it's a real problem.
I have yet to see a single Art History curriculum include a Deep-Fryer Cleaning course. If universities aren't going to prepare students for the jobs they're going to have, then they shouldn't lie to kids about it.
My larger point: According to your thinking, then, we need to take the people who are studying computer science, and move maybe 98% of them to a software engineering major. If CS is what you define it to be, we absolutely do not need as many CS graduates as we have people enrolled in CS.
What we currently have is that the schools think they should be teaching CS (per your definition), and both the students and the outside world are expecting the courses to teach what is actually useful out in industry - software engineering. I could actually see this as a useful split (we separated physics from mechanical engineering). But then CS becomes "that computer thing you take if you want an academic career", not what you teach all the people who are trying to get a job. CS loses the vast majority of its students, and with it, much of its prestige.
But I think you're underselling the value of pure computer science compared to the software engineering discipline. Physicists don't have to go into academia, they can ply their trade applying physics, collaborating with engineers on the cutting edge of semiconductor manufacturing, aeronautics, space exploration, and so on. Before a field is ready to be turned into engineering, the early work is usually done by physicists.
Sure, there's hopefully no need to account for novel physics when you're building a bridge - all the theoretical models engineers need have been worked out long ago (by physicists). But if those same engineers were working on a space-elevator? They'd bring along some physicists to help figure out the new stuff they were going to encounter.
The same applies to the software domain, too: before something like deep learning can be engineered into regular products, it's going to be computer scientists who work out all the details - and not just in an academic environment, they're doing it in industry, working with engineers to turn theory into practice.
If someone is smart enough to talk about data structures competently in an interview, don't you think they could learn git?
I swear people must be conducting interviews to try to feel smarter than the candidate rather than to find a person who can do a job.
I've seen it happen and this is not an issue of people trying to be smarter than the person they're interviewing. In point of fact, I just had an interview with a company where I'd be forking and improving open source code for building modular website content blocks and they asked me to write a bubble sort algorithm.
Trivial, but I hadn't done it in 12 years since college. Now quicksort, that's actually useful, but a bubble sort? I got a little tripped up, remembered it eventually, but the whole time the "bad cop" in the interview was checking his phone, sitting cross legged on the heater and talking about his adjunct position at local, minor university. Who's trying to look smart?
This sums up the root problem, to me. Many comp-sci programs are run with an eye towards arid, abstract wisdom, not marketable skills. That's not inherently bad, and it's true of many degree programs--no one goes into a philosophy major thinking that it'll be a good career move; they do it because they love philosophy. The problem is that the philosophy department is honest about that fact. Advisors tell bright-eyed would-be programmers that they'll just love the CS program when they should be telling them to turn around, walk out the door, and check out the technical college across town. By the time the kid discovers the lie, he's down five years and $30,000 will not much to show for it.
I promise you that not every electrician understands the subtly of homogeneous layers in high frequency integrated circuits. Nor do the vast majority of people actually building things with computers need to understand the draw backs to using a binary tree over a hash table. Sure, it'd be nice to be curious and want to learn more, but you don't need it to be competent.
Computer science is not software engineering, just like materials science is not structural engineering, and neither of those is that closely related to building a bridge or a building. Most of what we call "software engineering" is actually closer to what an engineer would call a "technician" in any other practical field.
I've met many, many "computer science" graduates who are barely aware of the "science" element of what the field contains. This isn't helped at all by those of us in the field (and our academics who teach us) happily mixing up the terms "computer science", "software engineering" and "programming".
Scientists expand the range of human thought in the field by discovering new truths, such as algorithms, design patterns, and conceptual relationships. Engineers turn these truths into techniques and building blocks/frameworks, and maybe designed solutions. Technicians take the building blocks and techniques and make artefacts, hopefully using best practices.
We're suffering from the fact that our field is less than a century old, in real terms, and neither the terms for these things, nor indeed the techniques and literature, have become concrete.
I think that the GP provided a reasonable explanation for this situation by saying that the "field is less than a century old". If you go back in time you are more likely to find one person inventing a new brick, designing a house with it and then building it. But later when the body of knowledge was too big for one person, specialization started (the same happened in medicine and many other fields).
And actually it is already happening in the IT area. Just several years ago it wasn't uncommon that a game or any other non-trivial piece of software was created (including some clever "inventions") and marketed by one person.
There's a lot of people in this thread saying the same thing. You're not wrong in the abstract, but in saying "haha, this article doesn't understand computer science" you're missing the hugely important point that most universities also don't understand computer science, or else knowingly lie about it to increase enrollment. If a starry-eyed high school kid shows up for a campus tour and says "I've always wanted to be a bricklayer," nobody is ever going to tell him "Oh, we have a wonderful materials science program that you'll just love"; but that was exactly the experience that I had with CS, along with many millions of other would-be programmers.
Not at all. It's pretty central to my point that both we in the industry and the academics who teach us are mixing up the terms and not paying heed to the "science" in "computer science" (and I said as much in the comment).
I agree that the starry-eyed kid who wants to write apps and games would likely be turned away if he was faced with actual computer science instead of what is sold as such: If you showed him TAoCP and said "This is an example of broad-based computer science", he'd get blurry-eyed instead, because there is no visible relationship between one end of that desire and the other.
But that might not be a bad thing if we get our stuff together and fix our expectations and our terminology: An 11 year old tinkering with electronics in her bedroom, or mixing up colours and smelly stuff with her "my first chemistry set", or dragging her family fossil hunting in the hills is not doing "science", but she knows that "science" is that way, and at the end of a degree course in science--assuming she doesn't stay in academia--she gets a job as a lab technician, not a scientist; much of that role might actually involve sitting in front of a computer processing statistics and analytics anyway, rather than mixing up fun stuff in a test tube (which, after all, is what she was originally passionate about). The technician stuff is not what she wanted when she was 11, but it's still a part of the journey, and the science education is what sets her up for later participation in chemical engineering work or even some actual science (if she's very driven or fortunate).
A good answer to the question is "I don't really know the specific technology for sensing the positions of trains. If the sensing is used to make automatic driving decisions, it is of crucial importance that it be accurate and reliable, for safety reasons. If trains are automatic, then the system must not only know their positions, but the trains must know that the system knows their position; if a train's computer loses touch with the system, it must come to an emergency stop. A rogue train whose position isn't known must not continue moving, for obvious reasons. I think I would survey how all this has been successfully done in existing transit infrastructures around the world and borrow the best elements from the existing designs".
A lot of degrees don't offer much practical knowledge for the real world? With what you people are paying for tuition; I would demand it from your university though? You students have so much more power than my generation had.
I picture a lot of tenured professors thinking, "Woa--I got them through the textbook! I'm not really prepared to deal with real life situations? After all, I been holed up here for years, and my sabbaticals were basically vacations?"
I understand why most majors can't really prepare the student for the real world, and real world problems. Years ago, I got a degree in Business Administration/Management. It was a joke, and there was really no real world/relevant courses offered. I had one Econonomics Professor give some real world advise, he told us, "If you want to get ahead in business; you will need a red nose--"
He was a returning to teaching from a long stint in the private sector. . His last job was working for Texas Realestate company? He said at lunch--it wasen't uncommon to Have to drink 3-5 cocktails--just to fit in with the guys. I really dated myself with that comment? It's probally the opposite today? Maybe not in Texas though?
When I was in college, I thought General Education courses were a waste of time. I now look back, and I am so glad I was forced to take so many, seemingly random courses. The courses for my major we a waste of time. I picked business because I was young, and very poor. I was about to drop out, and I figured I needed a degree in anything--so I wouldn't resent paying back those student loans, and maybe go to a professional school? In the 80's, Business Administration was considered a safe degree in terms of employment. If I was to do it over, I would have majored in something I was really interested in! Geology? Engineering? Art? Philosophy? Biology? Yes--we had CS, but I just wasen't interested in it.(It's such a better major today!)
Using version control, working in teams (using version control!), working with other people's code, and designing software to meet requirements (in teams!) were all part of the core curriculum. The curriculum even used Extreme Programming (which seems, in my experience, to differ very little from agile methodologies like Scrum) as the model for guiding group/team projects. Not to mention projects where we had to complete assignments on top of provided 'nightmare code' written by a professor.
And pretty much every grad can still tell you the Big-O complexity of the major sort algorithms. Or anything else you'd expect from a "more academic" CS program.
However, I believe the UA program very much tried to combine practitioner knowledge with academic knowledge. (And once again, my experiences were more than 5 years ago.)
I don't suppose that he is a typical graduate of the program, but perhaps the one cited in the article isn't either.
When in college I did a whole lot of programming using version control (CVS in my time, kids have it good today!), API's and various programming languages. I didn't need my college to teach me these things. It was the application of what I was learning in school.
Also, in college we had a Software Engineering course elective, a Testing course elective and some other more practical course electives that most people took because it was, well, practical skills.
So I think a decent mix of theory and practical skills are best but the it is also up to the student to engage themselves outside their program to learn "real world" skills. That's especially easy for students today with tools like Github and OSS becoming such a huge thing.
Of course there are things that are much easier to learn on the job, such as how to navigate a huge codebase. Because you'll have time to do that. Also architecture decisions are hard to get right as a novice. You can read around, you can ask people questions, but in the end you need to make mistakes and rebuild to appreciate some aspects.
I can't say that any of the core classes involve navigating a huge codebase... there are certainly some upper level track classes (especially in Systems) that give you that experience, but I do agree that is relatively uncommon.
Honestly so much of the learning happens in extracurriculars (Hackathons, CS/tech clubs, etc) that it's hard to keep track of which skills you learn in classes vs just doing other activities with friends. I think the power of college resides in the strength of such extracurriculars.
First, the CIA puts all code in the cloud. Then, the CIA plans to ban compilers. People will write html as their jobs and have no clue any other computer programming exists. They will make people think that making a website is the only computer programming.
No, learning anatomy will not make you a good painter. However if you are already a painter and want to become great, then you will need to learn anatomy.
Usually when we say "list" we mean "linked list": a flexible structure with poor random access, though sometimes the word is an implementation-agnostic designator for any sequential structure.
I read Sean Parker's bio on Wikipedia sometime back and it explained his "autodidacticism". It got him far very early in his life so much that he didn't have to attend college. Granted not everyone has the kind of innate skill that some of these so called geniuses or prodigies do, but you can certainly learn a thing or two from them.
As far as working in teams go, again, nothing is preventing you from gathering two or three of your good friends and building something together, no matter how useless the end product turns out to be in real life. This way, you are not restrained on your idea or your methodology in building, you learn from trial-and-error and build on your experience, and if the product does turn out to be something remotely useful then that is one more thing to write on your resume and talk about in your interviews. Work towards getting your degree and do well, but always work towards making yourself better; don't solely rely on coursework and professors, because that won't take you very far.
I minored in business but then transitioned to double majoring in CS and MIS. MIS was more focused on teaching you how to build systems.
My take is if you want to work for one of the big firms tackling problems at scale, then you need the CS and math rigor to get in the door. If you're OK building websites or mobile apps, then most of that CS knowledge is going to go to waste.
For me, machine learning has been the catalyst for getting deeper into math and science. I decided that I'm more interested in ML/AI than building business systems, so I'm going deeper into CS/Calculus/Linear Algebra on my own and I really enjoy it.