Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Teaching other teachers how to teach CS better

cacm.acm.org

Post reply on HN
Print view View original

51–60 of 93 posts

Re: Teaching other teachers how to teach CS better

#51

Post by teddyh »

throwaway287391 wrote: post #36
enriquto wrote: post #35

Earlier quoted context omitted.

> something along the lines of guided self-learning. I don't know about the solution of this problem, but giving programming challenges to students (in groups of two) is extremely effective. Ideally, forcing the students to use a different language each time. The evaluation is automatic and both the correctness and the speed of the solution over large inputs need to be evaluated. I've seen groups of otherwise passive…

> in groups of two I wouldn't doubt there's good research showing pair programming is a great way to learn, but anecdotally/observationally I really have trouble believing it's effective. In my experience, in at least half of pairs there will be one more skilled programmer and one less skilled programmer and the better one does the lion's share (if not all) of the work -- this is doubly true if the partnerships are r…

I always felt cheated when teachers do this. Either I’m the better one in the pair, and I’m forced to waste my time doing the teacher’s job teaching simple concepts instead of learning anything new myself, or I’m the less knowledgeable in the pair, and instead of listening to a professional I’m stuck being tutored by an amateur who doesn’t know how to explain anything.

Re: Teaching other teachers how to teach CS better

#52

Post by enriquto »

mkingston wrote: post #47
enriquto wrote: post #38

Earlier quoted context omitted.

I only have anecdotal evidence. But in my lab we have tried all combinations (working in groups of n, for n=1 to 4, randomly assigned or not). All setups may fail, for different reasons, but the setup that is consistently less likely to fail is two students that get along well with each other. The case when one of them is more skilled is actually very good, because then they teach the other one. There's often other w…

I was swayed by the argument against working in pairs, then swayed back by your argument in favour of working in pairs. I think the key part that changed my mind was "two students that get along well with each other". I wonder if you emphasise this in your instructions to students? And if so, how?

We just let them group themselves. If there's an odd number of students, a group of three is allowed. Every couple of years there's a "bad experience", in which one of the students does all the work, or some kind of conflict. But so far it seems to be a good choice overall (after the deal, the students generally say that it was a happy experience).

Re: Teaching other teachers how to teach CS better

#53

Post by frant-hartm »

throwaway77770 wrote: post #42
hejdjdjdkkss wrote: post #13

Earlier quoted context omitted.

> I studied CS over 40 years ago. I think I'm still deficient, at the end of my career. CS is hard. Name one system you worked on in your career that was “abstracted well” and built to the quality uncle bob thinks is good. I bet you can’t. Because they don’t exist. Not in the framework that this industry now measures “abstract well” in. It’s a square peg in a round hole. Writing software is more like composing music…

I don't think Bob's standards are preferable. Or, in the likeness of Yegge's Execution in the Kingdom of Nouns, I present: void get_coffee() { /* ... */ } void move_away_from_obstacles(auto what_to_move_away) { /* .... */ } void place(auto object_to_place, auto to_be_placed_on) { move_away_from_obstacles(where_to_place); put_object_on(to_place, to_be_placed_on); } void sit() { place(butt, seat); } void prepare_mind()…

Haha, this is really good, never seen it. But one piece of the uncle bob's advice says you should order your functions from higher level abstraction to lower level, then it reads like a book and you can stop at any time you get the understanding of the code. So your example reordered:

void get_opinion_of_uncle_bob() { prepare_mind(); opinion my_opinion = get_opinion(UNCLE_BOB); return my_opinion; }

void prepare_mind() { get_coffee(); sit(); }

void get_opinion(int on_whom) { /* .... / if (on_whom == UNCLE_BOB) { return create_opinion("too many short functions"); } }

void get_coffee() { / ... / }

void sit() { place(butt, seat); }

void place(auto object_to_place, auto to_be_placed_on) { move_away_from_obstacles(where_to_place); put_object_on(to_place, to_be_placed_on); }

void move_away_from_obstacles(auto what_to_move_away) { / .... */ }

Re: Teaching other teachers how to teach CS better

#55

Post by ModernMech »

cehrlich wrote: post #33

As a university lecturer in a non-STEM subject who is currently self-learning both 'hard CS' and the more practical side of development, I have often thought about what an effective CS curriculum would be, and the thing I keep coming back to is something along the lines of guided self-learning. Nothing is as effective as curiosity, but having someone with broad knowledge and experience in the field can help guide stu…

> the thing I keep coming back to is something along the lines of guided self-learning.

As a university lecturer in CS, I agree this would be a great thing for a lot of students. The thing about CS though is a lot of students hear that programming is a path to a high paying job, and they are really not motivated to learn the subject in the way that people who frequent HN might be. They don't want to self-learn, they want to be told what they need to learn to achieve an end-goal of earning a high salary when they graduate in 4 years. If you sit them down and ask them about their curiosity, interests, or ambitions related to CS, they give you a blank stare. They just want to get paid.

This perception also means that our program is the biggest at my institution. Students from every college want to take our classes. Our department is not so big (in terms of faculty, fewer than 20), so our class sizes are huge. My PL class last year was 200 students. My systems course last semester was 160. What this means is that I can't offer the kind of guidance for self-learning. Maybe if my class sizes were 30-40 students, but not for classes of 100+ students.

And then there's the issue of what students imagine a self-guided education looks like. They want to do things like mobile app development and AI. Most students don't self-guide themselves into fields like compilers and operating systems in my experience. They just aren't interested. Hell, I wasn't interested in these topics, until I was forced to take these classes as part of the standard curriculum. Now compilers are pretty much the only thing I'm interested in! I guess that's where the "guided" part comes in, but the point is that if students are left to their own devices, I worry we'll end up with a generation of programmers who are experts at making predictive AI models and iPhone apps, but have no idea how an OS or compiler works. Then who is going to teach the next generation how to make an OS? Already we have problems hiring people in these fields. 90% of the tenure track applications from our last round of hiring were from AI/ML type researchers, with only a few systems people (2-3 if we're lucky). I even have trouble getting TAs for my PL class, because all of our available grad students only know Python and C++ for their ML research. I see this only getting worse in the future.

Re: Teaching other teachers how to teach CS better

#56

Post by wirthjason »

Overall good article but I was expecting an in depth assessment of how to actually teach CS. I was particularly interested in hearing how teaching CS might be different from teaching other subjects, particularly math, engineering, etc.

Instead the article was more about why student reviews are not a good way to evaluate the teacher. It’s like letting your toddler decide what’s for dinner… “ice cream and candy, again?!?!”

Re: Teaching other teachers how to teach CS better

#57

Post by klodolph »

tester34 wrote: post #34
klodolph wrote: post #30

Earlier quoted context omitted.

"Definitely" what? The parent comment called it IT, so I called it IT, but if use the more specific term "software engineer" I'm still going to say that most software engineering projects aren't likely to injure people when they fail. Software engineering just doesn't seem to fall in the category of jobs where you'd want to mandate ongoing training... jobs like pilots or psychologists.

Definitely SE is kind of job where people are constantly learning a lot of them even in their free time.

Some definitely don't. It's easy to end up with no experience with modern tech stacks after leaving a position. Some environments ossified years or decades ago and make it easy to bury your head in the sand once you're there.

You could spend years at a company working with internal frameworks or internal forks of old open-source projects, and when you change jobs, you realize that everyone's using React and all of your experience is with some half-baked alternative to Rails that someone at your last company cooked up in 2008.

Or you could even be a bona fide OS/360 wizard who hasn't touched anything else for the past thirty years, who suddenly finds themselves looking for a new job--not that there's zero demand for OS/360 experts, but it can be very tough to find positions.

Re: Teaching other teachers how to teach CS better

#58

Post by anonymousDan »

enriquto wrote: post #38
throwaway287391 wrote: post #36

Earlier quoted context omitted.

> in groups of two I wouldn't doubt there's good research showing pair programming is a great way to learn, but anecdotally/observationally I really have trouble believing it's effective. In my experience, in at least half of pairs there will be one more skilled programmer and one less skilled programmer and the better one does the lion's share (if not all) of the work -- this is doubly true if the partnerships are r…

I only have anecdotal evidence. But in my lab we have tried all combinations (working in groups of n, for n=1 to 4, randomly assigned or not). All setups may fail, for different reasons, but the setup that is consistently less likely to fail is two students that get along well with each other. The case when one of them is more skilled is actually very good, because then they teach the other one. There's often other w…

Out of interest, do you actually force them to follow pair programming best practice (e.g. periodic switching)? Or just put them in groups of two and let them at it?

Re: Teaching other teachers how to teach CS better

#59

Post by ModernMech »

teddyh wrote: post #51
throwaway287391 wrote: post #36

Earlier quoted context omitted.

> in groups of two I wouldn't doubt there's good research showing pair programming is a great way to learn, but anecdotally/observationally I really have trouble believing it's effective. In my experience, in at least half of pairs there will be one more skilled programmer and one less skilled programmer and the better one does the lion's share (if not all) of the work -- this is doubly true if the partnerships are r…

I always felt cheated when teachers do this. Either I’m the better one in the pair, and I’m forced to waste my time doing the teacher’s job teaching simple concepts instead of learning anything new myself, or I’m the less knowledgeable in the pair, and instead of listening to a professional I’m stuck being tutored by an amateur who doesn’t know how to explain anything.

> I’m forced to waste my time doing the teacher’s job teaching simple concepts instead of learning anything new myself

IMO you can't say you really understand a thing until you've taught it to someone else. Your teachers gave you the opportunity to hone your own teaching skill, something you will use your entire CS career. Just wait until you are a senior dev holding the hand of someone more junior than you. If you think there is a skill gap between you and your peer in the same class, imagine the experience gap between you and someone 20 years younger than you.

Re: Teaching other teachers how to teach CS better

#60

Post by recursive »

teddyh wrote: post #51
throwaway287391 wrote: post #36

Earlier quoted context omitted.

> in groups of two I wouldn't doubt there's good research showing pair programming is a great way to learn, but anecdotally/observationally I really have trouble believing it's effective. In my experience, in at least half of pairs there will be one more skilled programmer and one less skilled programmer and the better one does the lion's share (if not all) of the work -- this is doubly true if the partnerships are r…

I always felt cheated when teachers do this. Either I’m the better one in the pair, and I’m forced to waste my time doing the teacher’s job teaching simple concepts instead of learning anything new myself, or I’m the less knowledgeable in the pair, and instead of listening to a professional I’m stuck being tutored by an amateur who doesn’t know how to explain anything.

This was my feeling too, and so I always found a way to weasel out of groups. In the decades since though, I have come to think that it was a mistake.

In the ways you describe, academic group work is pretty similar to being a professional developer, unless you're in a solo project. The experience of dealing with people would have been more instructive (for me) than whatever ostensible subject material we were covering at the time.

Post reply on HN