> Surely you shouldn't need to struggle in the dark so much to learn.
You have it all wrong, IMO. Successfully clawing their way out of the dark is by far the most important skill they're learning.
You have it all wrong, IMO. Successfully clawing their way out of the dark is by far the most important skill they're learning.
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.
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.
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.
Well... obviously not! But:
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.
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 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.
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."
"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!"