Coding Camp vs. Computer Science
Coding Camp vs. Computer Science
A response to a comment disparaging the usefulness of computer science degrees.
Join the DZone community and get the full member experience.Join For Free
Step 1, read this: "Dear GeekWire: A coding bootcamp is not a replacement for a computer science degree". It's short, it won't hurt.
I got this comment:
"The world runs in legacy code and the CS degrees focus on leading edge. Most of what is learned in CS [is] never used in the mainstream of business. Much of computer work is repetitive and uninviting to upwardly mobile people who generally are moving up not improving the breed"
I disagree. A lot.
"The world runs in legacy code". First, this is reductionist: everything that's been pushed to GitHub is now a "legacy".
- Does "legacy" mean "old, bad code?" If so, only CS grads will be equipped to make that judgement.
- Does "legacy" mean "COBOL?" If so, only CS grads will be able to articulate the problems with COBOL and make a rational plan to replace it with Microservices.
- Does "legacy" mean "not very interesting?" We'll return to this.
"...CS degrees focus on leading edge." Not really true at all. The foundations of CS (data structures and algorithms, logic, and computability) haven't changed much since the days of Alan Turing and John von Neumann. They're highly relevant and form the core of a sensible curriculum.
The "leading edge" would be some Java 1.8 nonsense or some AngularJS hokum. The kind of thing that comes and goes. The point of CS education is to make languages and language features just another thing, not something special and unique. A little CS background allows a programmer to lump all SQL databases into a broad category and deal with them sensibly. A Code Camp grad who only knows SQLite may have trouble seeing that Oracle is superficially different but fundamentally similar.
"CS is never used in the mainstream of business." True for some businesses. This is completely true for those businesses where "legacy" means "not very interesting."
There is a great deal of not very interesting legacy code that fails to leverage a data structure more advanced than the flat file. This code is a liability, not an asset. The managers that let this happen probably didn't have a strong CS background and hired Code Camp graduates (because they're inexpensive) and created a huge pile of very bad code.
I've met these people and worked at these companies. It's a bad thing. The "leadership" that created such a huge pile of wasteful code needs to be fired. The "all that bad coded evolved during the 70's and 80's" isn't a very good excuse. A large amount of not interesting code can be replaced with a small amount of interesting code quickly and with almost zero risk.
Any company that's unable to pursue new lines of business because — you know — we've always done X and it's expensive to pivot to Y is deranged. They're merely holding onto their niche because they're paralyzed by fear of innovation=failure.
"Much of computer work is repetitive". False. It's made repetitive by unimaginative management types who like to manage repetitive work. If you've done it twice, you need to be prepared to distinguish coincidence from pattern. When you've done it three times, that's a pattern, and you need to automate it. If you do it a fourth time, you're missing the opportunity to automate, wasting money instead of investing it.
"Much of computer work is...uninviting to upwardly mobile people". Only in places where repetitive is permitted to exist. If repetitive is not permitted, upward mobility will be the norm for the innovators.
"...people who generally are moving up not improving the breed". I get this. The smart people move on. All we have left in this company are Code Camp graduates and their managers who value repetitive work and large volumes of uninteresting code.
Improving the Breed means what?
Hiring CS graduates instead of Code Camp kiddies.
Published at DZone with permission of Steven Lott , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.