Slashdot Mirror
Do Businesses Really Need to Hire CS Majors? (cio.com)
A new article in CIO magazine argues that when it comes to computer science, "few of us really need much of any of it." Slashdot reader itwbennett offers this summary:
At the heart of the matter is the fact that most businesses don't really need programmers to be deep thinkers. For them, it's "just as worthwhile to hire someone from a physics lab who just used Python to massage some data streams from an instrument. They can learn the shallow details just as readily as the CS genius," according to the article.
CIO's anonymous author promises an incomplete list of "why we may be better off ignoring CS majors." Some of the highlights:
CIO's anonymous author promises an incomplete list of "why we may be better off ignoring CS majors." Some of the highlights:
- Theory distracts and confuses. "Many computer scientists are mathematicians at heart and the theorem-obsessed mindset permeates the discipline."
- Academic languages are rarely used. "...the academy breeds snobbery and a love for arcane solutions."
- Many CS professors are mathematicians, not programmers. "One of the dirty secrets about most computer science departments is that most of the professors can't program computers. Their real job is giving lectures and wrangling grants...."
- Many required subjects are rarely used. "...it's too bad few of us use many data structures any more."
- Institutions breed arrogance. "...the very nature of academic degrees are designed to give graduates the ability to argue one's superiority with authority. "
- Many modern skills are ignored. "If you want to understand Node.js, React, game design or cloud computation, you'll find very little of it in the average curriculum... It's very common for computer science departments to produce deep thinkers who understand some of the fundamental challenges without any shallow knowledge of the details that dominate the average employee's day."
"It's not that CS degrees are bad," the article concludes. "It's just that they're not going to speak to the problems that most of us need to solve."
From my standpoint, this is an earmark of of the end of IT as a professional specialty.
At this point technicians are treated as hourly workers- if they exist at all. The word "engineer" is being banished from the IT profession. Support is by phone script. The network is built on appliances. Configurations done by subcontractors. Job qualifications require education over experience. Certifications are required- but are generally useless without a degree.
Programmers are shuffled in and out on contract....code is undocumented. Competence is un-rewarded.
And management doesn't understand the technology with a mentality that says: "Do the minimum possible to get a short term result".
The net result is lots of titles like "Network Manager"... "Network Architect"... "Vice President of Information Systems".... ETC.
And yet none of these people have functional knowledge of real practical networking or server administration. They function as gateways to subcontractors, some of which follow the executive from job to job, and the officer level of the company is so ignorant of the issues involved that it continues.
Then there's the "Cloud".
It's the biggest ripoff any company can be subjected to. A multi-layer IT staff that only administrates the actions of sub-contractors. And yet while this management structure can be three layers deep- it does nothing, presents no skill set, and is useless without the added expense of subcontractors which provide "IT Expertise" as a service. And the company... isn't even in control of it's own data. It's security and availability is now preserved by a third party company whose interest is singularly profit.
So when "CIO Magazine" writes an article saying that CS majors are not needed all I can do is chuckle.
Another consultant who stuck it out.
"We are the Priests, of the Temples of Syrinx..."
This is an open secret that's been known for decades. The best minds that I've work with are almost invariably from other majors. The sharpest programmer that I know came out of the music department. In most positions, technical skills represent about 1/5 of what you need to do a job. Those other 4/5 matter a whole lot. It's easier to teach a humanities person some technical skills than it is to teach a technical person humanities.
throwing away the importance of modern math and CS theories is suicidal. Never had to do with problems due to rounding errors, for example ? Try fixing them without somebody with skills in CS and math! The author of TFA is probably somebody involved with the development of web interfaces, and we just appreciated the results of many years of progress in web development.
I think obedience is doing what you're told, discipline is doing it on your own without being told again.
I've never been in the military but I've worked with a couple of guys who have and they all carry a certain amount of military discipline with them, even the ones that say they hated the military.
Now maybe it's worthless self-discipline, but nearly all of them were *extremely* tidy. Personal work spaces kept fucking spotless, and whenever they dealt with some cabling or something else that would be easy to keep on the slightly chaotic side they all were completely OCD about organization.
They were all extremely neat in their personal presentation, too. IT has a lot of fucking slobs, but these guys were totally neat -- shirts tucked in, shoes shined, etc.
Oddly, all of them deny it was because of the military but I think they get it drilled into their head so much it's part of their identity.
If I had a criticism of them its that they're prone to low initiative on problems, preferring to report conditions and await instructions. American business culture mostly isn't like that, though, and their trained-in desire to await orders vs. committing on their own accord seems to be the only real drawback.
Construction doesn't need every carpenter to be an architect but you'd better have an architect.
Or just a competent builder. My dad was a builder, and almost every single architect-designed house he built needed anything from significant through to major design changes to get it from what the architect wished for to being physically buildable and in compliance with building regulations. There was one house that was so bad he refused to build from the architect's plans when the owner wouldn't agree to him fixing them. Forty years later the owners are still in the house, and they'll be there till they die, no-one in their right mind would buy what they ended up with.
I've seen the same thing with software, I once did a bit of work for a company where their salesdroids would spend their lunch hour telling me why their Grand Poobah System Architect's design couldn't ever work. It didn't even take a developer, even the sales guys could see why it couldn't possibly work, and they had things like MBAs and BComs.
I have only taken two computer classes in my 40-year career -- Fortran and Cobol. The first was for the credit in case I ever got a degree, I had already taught myself Fortran because I had already taught myself BASIC for a project in my calculus class (I was a math major) and realized I could teach myself far faster than the school can. I took COBOL because I was a computer operator and they wrote programs in COBOL, and I didn't want to stay a computer operator. Every other programming language I've learned since then has been on my own. Except for C++, I took an online course for that.
It doesn't take a CS major to be a programmer. It does take someone who can understand logic and I believe has spatial awareness, the ability to 'see' how chunks of code and external processes fit together and be able to manipulate them in their head. The best programmers I've ever met were musicians, and I think it's because the best musicians have a high degree of spatial awareness so they can 'fit' different parts of a piece together in their head.
There are different types of programmers. There are those that need a spec to get anything done because they aren't able to figure it out on their own. Some CS work will help with that, but I think at some level you can't teach it. It's like teaching me to play the piano .. I can learn where the notes are but I'll never be a concert pianist because I just don't have the dexterity and coordination. That's why I play the saxophone instead of the piano. Then there are the natural programmers that just get it, CS will help them get a job because it checks off a box in HR, but for the most part, they are very capable of learning themselves.
While I believe all aspects of CS can be learned on one's own, they can also be taught faster. Testing techniques, architectural designs, data designs, and a whole host of things can be learned by googling. But, if one doesn't know something exists, one may not be able to find it. A CS degree, at a minimum, should provide exposure to a wide range of knowledge that can be extended as one needs it and technology changes. Let's face it, while we may have come a long way since I wrote assembler, deep down inside, it's still all ones and zeroes, registers and memory.
Idiots abound, both untrained and trained. If companies were more focused on hiring smart people, paying them well, and then hiring the next level down and letting the smart people mentor them and give them the tedious tasks, we all get a lot more done.
Regardless of what degrees they have. Degrees don't mean squat, one has to actually talk to someone to figure out if they know anything.
This isn't mean to disparage learning things, I'm only saying the HR department needs to look past the degree to the person before making decisions. I've known very smart people with and without degrees, and the same goes for idiots.
I'd rather have smart non-degreed workmate than an idiot with a degree. Ok .. I'd rather have a genius with a degree, so the actual order is:
1. A genius with a degree.
2. A genius without a degree
3. The rest of the idiots for tedious tasks, a degree is irrelevant.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
Sigh. I hear this argument often, but its not true. You don't need a separate person as an architect when your project is small. Do you need an architect for putting together the barn behind your house? No. But its not because an architect isn't needed. Rather its because, building the barn is such a small problem that the builder (programmer) can perform the trivial architecture piece all by themselves (in most cases, in their head, without needing to formally declare it on paper).
It takes a while before college graduates deal with the big problems. Until one understands that big problems come with challenges that require a different approach, its hard to understand why an architect is needed. To go back to the example of the parent post: the architect isn't specifying how exactly one needs to implement the code. It is a false argument to say that they are taking away anyone's flexibility in that area; this viewpoint makes it clear that the poster doesn't know what an architect does. To go back to the building analogy: suppose the customer comes to the builders and say that they want an office building. Who gets to make the decisions on what it should look like, how tall it should be, how many entrances and exits, where does the supporting infrastructure (pumps, networking and telephony equipment, etc) go? Its not the builder or the electrician, or the brick layer or what ever the trade is. They are not laying down the vision of what to build. The architect - whether it is civil engineering or software engineering - is describing what it is that you need to implement - not how. An architect is NOT a lead developer. If you have to blame someone for taking away your flexibility in programming style, blame the lead developer.
There is no such thing as luck. Luck is nothing but an absence of bad luck.
One professor would literally hand-wave "Those are implementation details."
But it depends what you teach. I teach computer science. And when I teach algorithms I could not care less how some of the bricks are implemented. I care about teaching correctness and complexity analysis.
Your example on doubly linked list that trash the cache are a particularly good example. I don't even care that there are trashing the cache because they just change constant. And ignoring them enables me to get my students to focus on something more important in that class: Is it correct? What is the complexity?
Now when I teach High Performance Computing, I typically tell them that the only thing they should care about is the performance. And therefore the complexity may not be as relevant as before. There is even a very famous case in matrix multiplication that highlights that fact. Because constant definitely start to matter. But you need to care about different things at different point of the curriculum if you plan on driving the concept of the day through the students' brains.
Kind of like how not everyone needs to hire someone who designs programming languages or builds compilers, right?
Studying programming languages and compilers is important. Such a foundation to build upon is how we CS grads can easily learn and switch to whatever "new" language is the flavor of the moment, while writing decent code that has some understanding of the limitations of the underlying architecture it all runs on.
Not having such a foundation can lead to those degenerate situation where "fans" of a language try to use it everywhere for anything and require 3 GHz quad core CPUs and 16 GB of RAM to accomplish relatively simple things.
In short those CS classes and projects teach a young developer there are many ways to do things, a wide variety of tools are available, some tools are better for some tasks, and they learn a little about what happens at the architecture level where all the levels of abstraction have to meet and execute on the available hardware.
Now can a young developer learn these things outside a formal degree program, sure, but very few have the personal initiative to do so and most need the coercing of the university. And the direction of the university as well since many of the seemingly "unnecessary" classes actually turn out to be useful.
If you think a CS degree is limited to complex problems and inapplicable to modest projects, you are mistaken. CS and other degree programs are a foundation, and with a stronger foundation the personal study one does and the experience one gains will be more effective. Again, its just starting on day one with a bigger toolbox and more tools.
And for the record, I've gone both the self taught and formal university route. The former is not a replacement for the later, the two are not mutually exclusive, and the CS grads that have an inherent interest in software development (as opposed to those who were told its a good career path) likely have practiced the former as well.
Second time in two days I've had occasion to post my favorite Master Foo story:
http://www.catb.org/esr/writin...
(the story doesn't say anything about PhDs, but it does talk about elegant)
Agreed to a point. Enlarging, if you just want a privacy fence you don't hire an architect, an engineer, a general contractor, and a work crew. You just hire one guy who probably doesn't have a degree in anything and he hires a couple helpers and they put up a fence. You certainly don't hire people degreed in materials science and physics.
Likewise, you don't need to hire a EE to put a dimmer switch in your dining room. You don't hire an ME to figure out why your Ford stumbles on acceleration.
The guys who install home theater speakers aren't acoustic engineers.
Also, when the project gets complex, you will NOT be allowed to start over from scratch. Because it's complex, chances are you can't even disassemble it into workable components that you can reuse. Too many projects like that which eventually get to the stage that the entire team does nothing but keep it limping along until there's a competing product that takes over.