Would-Be Engineers Hit Books the Hardest, a Study Finds
nytimes.com
nytimes.com
Bringing your mind gently back to a topic again and again (until thoughts arise which make it clear, or giving up if they don't) isn't intrinsically hard in the sense that shovelling coal is hard.
What seems to make it hard is the belief that learning hurts, and fearing about one's future, which comes largely from the legacy of being continually graded and assessed at school (as if knowledge could ever be measured!)
Fearing that study is hard seems to make it hard. And this makes it easy to be distracted by other interesting ideas upon which one isn't being assessed. Also drinking, partying, and other typical student pursuits (which are in fact quite straightforwardly boring if you try to take them seriously).
The intellectuals and scientists that came up with the knowledge in the first place didn't find it hard. They were essentially determined to have a good time. Fortunately nobody was there at the time to check whether they were doing it right.
When I was an undergrad (warning: liberal arts majors), I had a lot of friends who were engineering students. I asked one if all the study was all that relevant. He said once he was in the workforce, he wouldn't need to have every little thing he learned memorized because he'd have manuals to consult and pull off the shelf when he had a problem he couldn't solve on his own. Another engineering friend seemed way more energized by the assignments where he had to come up with an actual solution to a real problem, in contrast to cramming all night for some horrendously difficult timed test.
So is all the ceaseless studying of engineers really just an effort to weed out those who are not diligent?
On the one hand, no I don't need to know calculus formulas off the top of my head for my daily work. Even if something came up, I could kick my textbooks out of the attic and look it up. Most of the actual, job-specific knowledge in modern programming is either domain-specific information or integration "plumbing" knowledge. Although the practice from doing engineering homework is helpful, you can get better practice faster in a more direct form by simply holding down a programming job or working on an open-source project.
On the other hand, if I had never read my textbooks in the first place, I wouldn't know which ones to reference for solving problems I encounter later. Many of the problems you face in real-world programming are ones that have already been solved somewhere else, but if you never heard of the solution, that doesn't help. Real problems also are not conveniently labeled with the name of the algorithm that solves them, so you need to know the solutions at a fundamental enough level that you can recognize and apply the solution to apparently-unrelated problems in disparate fields. That usually means you need to know it at an academic level. There are theories and rules-of-thumb from my Artificial Intelligence class that I consider to be the most important programming knowledge I have precisely because I understand the issues at that level.
My feeling is that studying engineering formally at college is the second-best training you can receive for programming. The first-best is working on a programming job at a company that has a nice, deep technical bench and the willingness to mentor you. However, most companies with that much technical capacity will only hire you if you're at least somewhat trained or experienced to begin with, so the real alternative to college is working by yourself and teaching yourself programming. The effect of teaching yourself will depend somewhat on how good you are at teaching yourself and a huge amount on sheer, dumb luck, since you might pick a terrible place to start learning and quite patently not know any better. So I recommend majoring in engineering if you want to be an engineer. It's not the only way, but it's the most practical and likely one.
It's worth pointing out: Getting real experience basically confers the same benefit, and probably does it better, but not all engineering disciplines are as fortunate as software engineering in the availability of experience. A programmer can just fire up an editor and start making programs, with zero cost and near-zero risk. A civil engineer, say, cannot start building bridges with anywhere near the same ease.
When I say "fundamentals" it really covers almost the entire engineering undergraduate curriculum. There is so much you need to know in engineering before you can start doing anything of value in the "real world". Most people learn those things in their first few years on the job or in graduate school.
And I'm willing to acknowledge that perhaps I'm not giving enough credit to contemporary engineering curricula, in which much of that 'study' time might be devoted to problem-solving exercises in place of preparing for tests of one's memory.
In fact, all of my classes allow at least one sheet of notes to all the exams and I've even had one class that was entirely open-book. Additionally, the graders tend to be rather forgiving for details--thinking consistently is more important.
Even though an engineering degree might be harder and involve more work than something like Political Science or History, the latter two require much more reading and memorizing.
But this doesn't always hold. I remember one class where all of the practice exercises on op-amps were done using an idealised model of the op-amp, without having to worry about things like resistance/capacitance in the op-amp. Then on the day of the test, the professor ran a whole series of questions using op-amps with more realistic characteristics. A huge percentage of the class crashed and burned, because they had just rote learned solutions to problems, but the problems in the exam did not resemble the practice problems. It did however resemble the material that had been taught in class. Those that put more emphasis on understanding what the lecturer was saying than on how to do tutorial problems aced the test. We ended up with a bi-modal result - you either got about 95% for the test (if you understood the principles, the questions were actually very easy), or you got about 15% if you had just learned how to do the practice problems.
The thing that really made that test stand out for me was what it meant in the real world. I went to a military academy, and after graduation we all had to work in uniform for the next 5 or so years, so you got to see how the engineers that got 15% and how the engineers that got 95% in that test fared. It turns out that those getting by on memorisation turned out to be terrible engineers, a fact that I found quite frustrating whilst getting my degree, because their tactic actually worked exceptionally well for most exams. There were only a couple, like the exam I mentioned above, that really cost them dearly.
So, be aware that even if you aren't going down the memorisation route (and I agree with you, engineering should be all about deriving from principles, not memorising tricks), there are others around you that are not doing this. You'll meet those people in your professional life afterwards, and they won't be able to engineer their way out of a wet paper bag, but they will have the same diploma hanging on the wall as you.
In CS, most of the time we spend is probably working on either problem sets (for algorithms classes) or projects (for more programming-oriented classes). In both cases, there is an extreme spread in how long it takes people--some people finish in hours what takes others days. However, in every case, very little time is spent memorizing; we just have to understand difficult concepts and be able to solve complicated problems that combine them in weird ways.
As for weeding out students, CS is special. It is a well document fact that a significant subset of the population just can't manage the sort of thinking needed to succeed in CS; this leads to even very easy classes getting scary reputations.
Finally, we come to career pertinence. I'm still a student and my only experience has been in simple internships. However, even there, many of the things we've covered have been very useful. While it's reasonable to just pull a book out (well, not a book--just the internet ;)), we need to learn everything we're covering to even know where to look, and, often, to know that we need to look anywhere at all.
Ultimately, all the hard work just gives us the baseline to identify problems and consider possible solutions to look up. Chances are, by the time we get to solving nontrivial problems, there will have been interesting advances anyhow--only the big ideas stay at all constant.
If you've never learned about how a computer is structured, you would never consider optimizing an algorithm for cache usage. On the other hand, with a CS degree, you will know enough to look up your processor's specs and twiddle around with the code until it "magically" becomes much faster. The main point of my education--as I see it right now--is to get me to basically that point in all of the sub-fields of CS.
The other big thing that all the work tries to instill is how to think like a programmer. If you've programmed on your own, you've probably started developing this; if you haven't, it's particularly important. For some people this step is difficult; others don't need much help. In the end this ability is extremely important in the real world.
So yes, I might never use MIPS at work but I will know enough to look up x86 if I really, really need fast code or if the compiler is optimizing weirdly.
My college certainly wasn't like that. We spent the a lot of time learning stuff you would never devote 3-4 months to while working. There was a lot of breadth.
In my experience there weren't really "horrendously difficult timed tests". There were tests... but either you got the general concepts or you didn't. It wasn't about micro-optimizing speed or memorization. I think a good education should teach you broadly what you don't know that you don't know, and then you can go back and fill in the details yourself.
When I got out of college, I thought a lot of CS wasn't all that useful for my programming job. But 10 years later, I am glad it taught me some "lofty" things, at the expense of having to struggle a bit early in your career.
What I mean by this is that when you come across some common engineering problem, if you've never seen it before, you'll spend a lot of time trying to re-invent the wheel, probably very badly. That's why engineering programs spend so much time on fundamentals and so much time on studying because when you hit a similar problem you're supposed to have a switch go off and say wait, I've seen something similar before, know where to head to do your research and find a solid answer.
So yes, the cramming and huge amount of coursework is "mostly useless" but in reality just having gone through all that work turns out to be a real boon later in life.
(I went through a Computer Science/Software System degree but have many SOEN/Mech/Civil/Indu friends.)