This is largely the duality between a school of engineering, and a school of technology as well. Purdue University has both. Engineering is this 150 year tradition that literally made Indiana the crossroads of America. Top 5 in most of it's disciplines year after year.
But that consistency has brought the hordes. Thus, freshman engineering is this gauntlet to run. Profressors are busy with reasearch, TAs are just reciting teleprompters. If you make it through, it's because you were self sufficient, and didn't rely on the university for much of anything.
The school of technology, on the other hand, requires professors have 15 years experience in industry. No research is performed. Every single core class has a lab section. It is literally disrupting the school of engineering by taking the students who aren't yet polyglots at 18, and actually teaching them to be engineers.
It is effectively a bypass to the same destination of becoming an Engineer. But there's more lanes, better signage,its well lit, more efficient maintenance, and I arrive at my destination refreshed, instead of frazzled because of all that big city gridlock.
There's a lot of similarity between the Computer Science program at Purdue University and the Engineering program. The professors are quite swamped with work outside of their teaching responsibilities and that leaves most of the teaching left to TAs who are, more often than not, terrible teachers. But the curriculum is still decided by the professors with ample experience. Actually graduating with a Computer Science degree shows an ability to self-teach, not an ability to be taught. The first two years are a constant sprint to stay on top of the coursework with little outside help. It's made most of my peers who've managed to stay in the program quite adept when working, but I'm not sure if this is the right way to go about building those skills. Surely you shouldn't need to struggle in the dark so much to learn.
That seems to me a bold claim to me - don't actually teach anything, just demand stuff! And behold, by pure magic (and LOTS of selection) we get a handful of successful students who manage to pass, validating this "teaching" style. Is that really what you have in mind?
I'm actually someone who did and does not have a problem with that style. It suits me very well. At university I mostly learned from non-university sources (e.g. using outside text books and ignoring lectures, and doing my own independent research and work on the side). I also finished over 60 edX and Coursera courses during the last five years (some easy, like history of architecture, many hard STEM and medical subjects) - so I like learning by myself. Still, when I go somewhere to be taught and all they tell me is "this is what we want you to be able to do at the end, but you have to go teach yourself" it makes me pretty mad. I had a few such edX courses - you know, if I have to use Youtube and Google I sure can get the necessary knowledge, but then why did I sign up for the course??
There always is plenty of opportunity to let people act independently. Refusing to teach as a way to teach is just lazy and incompetent.
> don't actually teach anything, just demand stuff!
That is not all that bad pedagogy assuming you have reasonable demands that escalate over time. It is to extreme if you never explain anything, but if your teaching style consist primary of forcing students to learn by themselves and explaining only minimum necessary, then I strongly approve.
Giving students everything directly is more incompetent, because it imo results in weaker learning. The goal is not to show how hard-working teacher is, the goal is to produce as many as much capable as possible graduates.
The strawman that makes your argument so brittle is that there are only two positions on the spectrum. The school of technology at Purdue has some of the brightest people I've ever encountered. What makes them extra luminous is their ability to spot common pitfalls novices run into. They learned this by being engineers in industry. Thus, those educators are supremely positioned to find the struggling adulthood novices that are good at fundamental academic skills, and keep them on the path.
Just like Ford Motors tried to convince everyone that they were the best, they eventually believed their own ad copy, and got entrenched in making cars the way that had always made them. And then all of Ford's competitors reverse engineered his logistics, and said "if your time to you is worth saving, then you better start swimming or you'll sink like a stone, for the times, they are a changing".
It worked for Bob Dylan pretty well too, when popular music was dominated by Elvis Presley.
1. learning to struggle successfully is far more important than mastering the chain rule.
2. If you start with excellent students, then you can set those students up to struggle on much harder and deeper questions.
My point, really, is that a curriculum that manages to not "lose" anyone will also fail to strike a good balance between "struggle" and "hand-hold" if 90% of your students start off as "Excellent".
The hardest part about designing a course is figuring out when students should struggle, and when to hold their hands. The answer will vary depending upon the quality of the students. Excellent teaching aimed at excellent students looks very different from excellent teaching aimed at mediocre students. Differentiating instruction is Teaching 101, and differentiation in universities often happens at the institutional or program level.
E.g., are Khan Academy's descriptions of the product rule better than Chicago's Math 160? For certain students, yes. For others, emphatically not! Neither option is "better" in an absolute sense, but each is definitely "better" for any given student.
There is nothing wrong with a course of study that's designed for the top 1% of high school graduates. And admissions mistakes do not equal bad teaching. On the contrary, torpedo'ing the entire curriculum to make sure that every student makes it through would be grossly irresponsible.
I recently had to write a scheduling algorithm for our home-grown operating system. I was running into some very difficult to debug issues, so I asked my TA for help. They had no clue and told me to consult the professor. The professor wouldn't help. Our textbook offered no guidance. We're not allowed to discuss projects whatsoever with other students. So after north of 5 hours spread over a few days of trying to figure out my issue, I gave up. How was this a beneficial experience?
Not being able to discuss your project with other students in an operating systems class is insane. You need to get input for the subtle bugs that are going to occur.
There is a reason why operating systems and compiler classes are notorious.
However, if 5 hours debugging is too much, I'd get out of the field now. Try debugging something for MONTHS while your bosses are all hanging over your shoulder.
In addition, 5 hours spread out is a problem. Subtle bugs require intense focus and you should be doing 5 hours per session. You have to inload and control a lot of details, most of which are irrelevant, in order to find the thing that really matters.
I really wish I could teach a "debugging class" where I hand groups real code with frustrating bugs. Unfortunately, no CS department would ever let me teach it as it would destroy enrollment.
I agree - 5 hours really isn't that much. I've spent much more time than that on single issues in the past, and it's by no means something that's scaring me out of the field. I should've spent more time in a single session hunting down the issue, but I didn't quite have the time (or motivation after seemingly making no progress) when it was only one of a few things I had to work on that week. One of my issues with that class in general was the complete lack of guidance on how we should go about debugging our operating systems' issues. The only method mentioned by my TA was to print more variables, which isn't incredibly useful if the kernel won't boot or if the print function isn't working. And the issues would compound as the projects were often dependent on previous projects. One of the tasks was to implement asynchronous signal handling through registered callback functions, which is quite difficult to do if you didn't get the scheduling algorithm working properly in the previous project. It felt like the class was designed to be difficult and not designed for me to learn. I was pretty excited to take an Operating Systems class, despite what I'd heard, and it was the class that left me feeling let down, not the content.
I would personally love a debugging class to get some more varied ideas on how to approach difficult problems. Seeing someone's thought process when debugging something like a kernel would've been really useful.
> Seeing someone's thought process when debugging something like a kernel would've been really useful.
The first thing when doing a kernel is don't be clever. Suboptimal isn't just good--it's preferred. Linear searches are fine. Shell sorts are fine. Arrays are fine even if you have to recopy them a lot. Hashes are too complicated. Trees are too complicated. Randomizing things is too complicated. Until your kernel needs to scale, the "suboptimal" ways are more understandable, and, as a bonus, they sometimes are more optimal as they require less up front overhead.
The second thing is "replace pieces". Because you weren't clever, you can rip out and change chunks with relative ease. It's not "proper", but, if you're on a deadline, sometimes swapping some component and having the bug go away is good enough. Just realize that, if a bug goes away randomly rather than because you understood it and killed it, you have planted a time bomb likely to blow up in your face at the worst moment. :{
The third thing is "hypothesize and THEN test". This drives me crazy with junior folks. If I had a nickel for every time I got the response "I dunno" in reply to "Okay, why did you think doing X would fix things?" I would be a rich man. This is the piece that makes debugging a kernel hard. You have multiple layers of abstraction, and the bug is probably 3 layers away from the thing that triggers it.
Something which I tend to use more for things like kernels than "normal" programming (whatever that means) is that I religiously check and assert on my data structures even at great performance penalty. Having a data structure blow up immediately is far better than soldiering on and getting the malfunction after everything is scrambled.
Something which I am becoming increasingly religious about is that time is an input to my functions that operate on "external" inputs (button presses, RF events, USB events, network packets, etc.). It's a pain sometimes, but when you need to debug something subtle, it is really nice to be able to replay things exactly.
And, a final piece of advice, learn your tools. GDB, for example, is amazingly powerful. Unfortunately, I only seem to learn more about it after the fact. :( I do something really stupid and someone asks "Why didn't you just do <mumble foo mumble> in gdb?" and my response is always "Because I didn't know about it."
I feel like there's always a little crotchetyness in older engineers. I remember being in school right when companies were putting all of their literature online. For electronics, that was such a huge leap forward from having to buy entire books of data sheets for integrated circuits. People on the other side of that divide had the same complaint about a different subject.
"You only looked through the data sheet for 4 hours? Back in my day it might take 4 hours to get the thing to even turn on!"
Stack Overflow. The key to debugging is to not be so arrogant as to assume you are working on a problem for the first time. In fact, this is the underlying premise of rubber duck debugging. You tell an inanimate object what you did to get where you are now, and as you enumerate and elucidate, your faulty assumption is often laid bare.
I've seen something similar at other institutions.
The School of Engineering, in this case, is trying to teach something more than just domain knowledge about engineering disciplines. The goal is to take those "18 year-old polyglots" and turn them into world-class problem solvers.
You see this is every elite educational program. Mathematics at Chicago. Computer Science at Carnegie Mellon. Engineering at MIT. Their programs have a difference in kind, and are very intentionally not built for "the average college student".
It's good that there's an alternative path within the same institution for those students who need to focus their efforts on baseline competence. But it's also good that strong programs expect more out of their students.
You've simply recited the fallacy. You've framed the very debate in terminology that assumes you are correct.
But that's what all entrenched interests do.
Schools of technology are not simply teaching baseline competence. They teach the theory of the same subjects, with a more hands on approach emphasized.
They are showing up to civil war reenactments with tanks and planes. The old timers are in a huff about it, but what else is new?
> You've simply recited the fallacy. You've framed the very debate in terminology that assumes you are correct.
I'm not sure what this means.
My claim is that educational programs designed for the top 1% of students are not well-suited to educating the next 10%. And vice-versa. (E.g.: A Chicago math student is often not well-served by the sort of "calculus for engineers" courses you'll find at state college branch campuses. Also, a college senior struggling through their Calculus requirement is not at all well-served by Chicago's honors mathematics program. Neither approach is better in an absolute sense; but in each case, one is clearly better relative to the particular student.)
This is not some sort of tautology. It's a serious pedagogical hypothesis with decades of empirical research probing its truth value.
> They are showing up to civil war reenactments with tanks and planes.
I can't speak to Purdue specifically. In the cases I know about, the very explicit purpose of these alternative degree programs is to build a department by admitting students that the name-brand program rejects, or who fail out of the weeder courses. The "old timers" aren't in a huff about it, because they had no interest in admititng those students to their existing programs in the first place.
I suppose I would argue that in the evolutionary sense, a university accumulates it's marketable value in units of accomplishment by it's people. To the extent that any one person can unequivocally demonstrate exceptional value through their own accomplishments, by inventing and commercializing valuable goods and services that improve the overall well being of humanity, the particular buildings those people occupied 30 years prior, and the particular people that educated them for those few months, are of no particular interest to the university. The university wants prestige because it attacts more prestige, which they can monetize.
I can agree that in the sense that the people best positioned to become the most educated should be paired with the best equipped to effect that teaching. However, at some point we're arguing over what is the best position to be in, which is not in anyway objective.
I would say, to firm that up even more, every school can point to their accomplishments, and the graduates/professors that worked on them, as to why they are in rarified air. You can look through Wikipedia at all of these renowned scientists, and who their advisors were, and who their students were. So you can say they stood on the shoulders of giants, and also stood tall for others to perch even higher.
But not a single one of those heroes of science should rightly be remembered primarily or even secondarily because of where they studied.
The underlying fallacy is that you can only learn the best skills from the best people in a short window if time in your early adulthood.
This is all anecdotal. I've found though from simply asking around, that most Engineering schools, as well as other fields, have weed out classes. They aren't technically labelled as such, but there is no better description, given their passing rates. They are curved grading, so by simple distribution of scores, large numbers of people will fail. There are so many students per teacher, the scarcity of resources demands a competition.
I suppose on the larger scale though, as universities compete for students, and their money, it makes sense economically to let in anyone with the base level of aptitude, because there are plenty of other programs you can switch to from engineering. But the easiest time to lock in your customer base is when they are making the decision to buy for the very first time. Almost like a car salesman. Just keep them on the lot long enough to convince them to buy something, in lieu of the thing they wanted when they first showed up.
My focus is on the student who gets to college and has all of the aptitude but simply doesn't know how to learn. In engineering, they go to class, listen to the theory, work the problems, and hope for the best on the test. They don't understand that there is a way to learn abstract concepts or even what an abstract concept is- what they are good for, and so on. They need to be taught that consistent review is essential- and how to do it.
So the idea that Purdue has a back-channel for students who may not be as academically gifted, meaning they don't learn well in the manner that traditional courses are taught, is interesting.
This happens outside of E-school and the sciences though. A helluvalotta students are showing up not being able to "do" college. High school was so easy they never had to learn how to learn.
I found in my experience that there were too many things to learn, and not just in class. I was also learning about being self sufficient, and restraining my impulses, and basic life habits that had been taken care of for me my whole life up to that point. Turns those courses are fraught with peril as well.
The confluence of social pressure, having to take care of all my domestic needs, and being exposed to tens of thousands of healthy young adults from all walks of life was nothing short of a quantum leap for me.
Not to conclude that the school of technology fixed all or any of those things for me. But their teaching method was infinitely more contextual to me, at where I was at that point in my life.
But that consistency has brought the hordes. Thus, freshman engineering is this gauntlet to run. Profressors are busy with reasearch, TAs are just reciting teleprompters. If you make it through, it's because you were self sufficient, and didn't rely on the university for much of anything.
The school of technology, on the other hand, requires professors have 15 years experience in industry. No research is performed. Every single core class has a lab section. It is literally disrupting the school of engineering by taking the students who aren't yet polyglots at 18, and actually teaching them to be engineers.
It is effectively a bypass to the same destination of becoming an Engineer. But there's more lanes, better signage,its well lit, more efficient maintenance, and I arrive at my destination refreshed, instead of frazzled because of all that big city gridlock.