Showing posts with label education. Show all posts
Showing posts with label education. Show all posts

11.05.2009

Responses to Teach For America pre-interview readings

I applied to Teach For America last week and I made it to the phone interview phase, which will be Monday for me. Before the interview, there are a couple of short articles you're supposed to read. To help organize my thoughts, I will discuss them a little here. Comments welcome, of course.

The first article is all about the Achievement Gap, which basically means the fact that students in certain groups (namely, those from low-income families, African-American, and Hispanic students) tend to perform worse than others, according to several different measures of performance. It cites lots of statistics to demonstrate the problem, and then tackles the questions of why the gap exists, and what we can do about it.

There are many reasons given but the one most relevant to a TFA applicant is of course the quality of teaching. According to the article,
[S]tudents in high-poverty, high-minority schools have less access to highly qualified teachers than do students in low-poverty, low-minority schools. Secondary students in high-poverty schools are twice as likely as those in low-poverty schools to have a teacher who is not certified in the subject he or she teaches. Students in high-poverty, high-minority schools are also more likely to be taught by an inexperienced teacher. Furthermore, teachers in high-poverty schools reported less favorable working conditions than teachers in wealthier schools. Teachers from high-poverty schools were more likely to report that student disrespect and lack of parent involvement were problems.
Makes sense to me. I was very fortunate to attend a nontraditional private school up through 6th grade and then the Manhattan Beach school district after that, both of which encouraged lots of parent involvement, as well as parental financial support. Of course it made a huge noticeable difference to the students, by providing for great art and music programs, relatively happy teachers, etc. Plus parent involvement goes a very long way toward getting students to be engaged with their classes and homework.

I also really like the point about teachers having a credential in the subject they teach. I can't imagine teaching, say, English or History, at any grade level. I suppose I would be capable of doing it if necessary, with the right kind of support. But why would you put me in that position? I don't have much of a passion for history or literature, so I would make an uninspired lesson plan, and then follow it mechanically with far less enthusiasm than someone who majored in that subject, or at least something closely related to it. If a student asked a question that was outside the planned curriculum, I would encourage their curiosity, but I would probably be very little help in answering it myself. It would be very hard for me to show the students the connection between the current lesson and future lessons or careers. (And effective learning is all about students drawing connections between things. That's one of the many things that Carl Wieman talked about when he came to USC -- something else I've been meaning to blog about.) I think people often forget how perceptive students can be. You can bet they know the difference between a historian (or mathematician, or scientist, or musician, or whatever) sharing their love for their chosen field, and someone who is "just" a teacher, plodding through the same old three-ring binder full of lecture notes, year after year.

Okay, you say, you're passionate about Physics. You're really interested in the cutting edge research and string theory and all that. But is it really possible to be that passionate about boring, first semester Newtonian mechanics? Absolutely. I think it's awesome how a few simple equations can describe all kinds of different phenomena in the real world. If you don't buy that, then at the very least, you can remember how interesting it was when you learned it for the first time, and be excited that you have the chance to pique the interest of a whole room full of new students. This is more or less what I said in my TFA application: The achievement gap is depressing, yes. But what disappoints me more (maybe just because I have more first-hand experience with it) is that things I find so intriguing (such as Physics) are so immensely boring for a lot of people. When I tell people I'm a Physics major, they always say things like "Oh God, I hated Physics. I was terrible at it!" This makes me incredibly disappointed, not because the person has "failed" in some way--many of these people are very successful in some other field--but because Physics is really cool and it saddens me to think that people are unable to see how cool it is. I think getting people interested is probably half the battle in getting them to achieve at a higher level. If you truly care about what you're learning, it's easy to be motivated enough to excel at it.

The other article is called Assessment Through the Student's Eyes, and it's all about how assessment affects students' emotions and self-confidence, which of course affects their performance. If they do well on tests and homework, they are pleased and encouraged and tend to keep doing well. If not, they just think "I don't get it" and become less and less motivated, so their scores stay low.

Okay, so what do we do about it? The article is mostly about what it calls "assessment for learning" as opposed to "assessment to verify learning." The assessment methods should be developed by both the students and the teacher, rather than just the teacher. They should be descriptive and contain clear indications about what the student can do to improve. If you're too lazy to read the whole article, I would recommend you skip down to the "scenarios." They show how you can keep students motivated (without just giving everyone an A), and they seem like great examples to follow. I've had a couple of great experiences that follow this philosophy pretty closely.

The private school I went to (then called Via Pacifica, now called Del Sol) didn't have grades, in either sense of the word: No A's, B's, or C's, and also no first grade, second grade, etc. Instead, students were divided into four groups (called "pods" for whatever reason) called the "explorers," "discoverers," "investigators," and "voyagers." People unfamiliar with the school would always ask me, "Well... how do you know if you did well, if you don't have grades?" It seemed like a strange question at the time, because we actually got more feedback than in many public-school classrooms. On writing assignments, we would sit down and go through them, paragraph by paragraph, explaining things that were unclear and figuring out how we could have written them more clearly in the first place. In math, we would identify any mistakes and confusing concepts, and continue to work on them until everything was clear. In fact, the math classes seemed to mimic the article's second scenario pretty closely. Last time you got, say, an 87% on a math test, did you look through it and find all your mistakes, so that you could take it again and do better? Probably not, because there is no incentive to do so in most classes.

The other experience I'm reminded of is last year in Quantum Mechanics with Dr. Richard Thompson. We had homework and tests just like any other Physics class, but after an assignment was returned, we were expected to go back and correct all the mistakes on them. It may sound a little draconian ("Do it again, and don't come back until it's perfect!") but it meant that we would really understand everything in one chapter before diving into the next one. Of course, mistakes ranged from simple sign errors to bigger conceptual misunderstandings, but in each case, we would find the mistake, with the professor's help if necessary, fix it, and then write out the rest of the problem. Once you got used to it, it was a very satisfying system, in which you knew that you really understood everything you'd learned, even though you may have messed it up on an assignment or in the high-pressure environment of an exam.

These two experiences reinforce what the article said: Assessment can and should be used, not just to evaluate the performance of students and teachers but to provide useful feedback to the students that will help them understand what to do as they move forward, and motivate them to do it.

Again, comments are welcome. Wish me luck on the interview!

5.12.2008

Writing "code"?

My friend from freshman year, Elliot, has recently started a new blog, Anyone Can Code. I guess he's going to teach some programming courses over the summer, partly because he, like me, doesn't like the way most of the courses he's taken at USC have been taught. And because he believes that, well, anyone can code.

His first post on the Anyone Can Code blog lamented the people who are somewhat interested in computer science, but think they can't code. I've always thought that "people who can't do math" were just people who had terrible math teachers and never took them time to learn any math on their own. There isn't really anything wrong with this, but it's now become relatively socially acceptable to know almost no math. It's also socially acceptable to know literally no coding, since most people never take any computer science classes.

I've digressed a little, but the point I wanted to make here is that perhaps referring to programming as "coding" is not good for making it accessible to the general public. Code, in everyday language, is a message which is unreadable until a person or machine performs some kind of operation on it to decode it, so that humans can read it. Back in the days of punchcards, that may have been somewhat accurate, but now writing computer programs is (or at least should be) almost the opposite. You write down what you want the computer to do, in as clear and straightforward a way as possible. Then the computer compiles or interprets it, which is when it becomes completely unreadable. But the programmer isn't writing "code". They're just writing down a set of instructions, in another language. So maybe instead of "coding," we should look at programming as writing in another language. Because that's all programming languages are--they're just languages, where the rules of grammar must be followed much more strictly than in languages like English or Spanish.

Oh great, you say, so coding is just like learning a language, except with even more emphasis on grammar? Sounds lovely. Well yes, but there's very little emphasis on learning new vocabulary. In fact, most of the important words in most languages are actually words you already know. And the grammar rules are much clearer and completely unambiguous, especially in languages like Ruby and (from what I hear, although I haven't used it myself) Python, which were deliberately intended to be easier to use. I think Elliot is right that anyone can code. It doesn't mean everyone will find it fun. But if we stop thinking of code as "code," perhaps everyone will be able to do it.

4.10.2008

Star shapes

So I skipped Philosophy today and went to my CSCI 101 midterm pretty early. Before it started, I was talking to Ashley and Rollerblades Kid (I call him that because I don't know his name, but he uses rollerblades as his primary mode of transportation) about the impending midterm, and computer programming in general. Ashley has no programming experience other than this class, and she was telling me how she had been having trouble on a recent assignment with opening an input file. The relevant code would go something like:

ifstream fin;
string filename;
/* ... */
cout<<"Please enter filename: "; cin>>filename;
fin.open(filename.c_str());

I don't think I ever figured out, based on her description, what she had done wrong, but she said she contacted a friend who works at Google, and her friend had told suggested some sort of modification using character arrays in place of strings. It makes you wonder why, when C++ was designed, they didn't rewrite ifstream::open() to accept strings. I mean, you could just do:

void ifstream::open(string filename) {
open(filename.c_str());
}

C++ just seems so user-unfriendly after playing around with things like Javascript and Ruby. It would be interesting to learn the history of various languages, because programming languages do grow and evolve like spoken languages, but there are also some clear differences between the way they evolve. In any case, I suppose they use C++ for the 101 class because it's well established, and the people running the department probably aren't familiar with a lot of the newer languages anyway. Plus, C++ forces you to think a little bit about the way the computer deals with data, internally, when you pass things by reference, or try to access an array value that's out of range. I suppose that would be helpful when you get to classes on data structures. (One of many classes, by the way, that I should be taking this fall, but can't because it conflicts with a required physics class.)

However, Ashley is a chemical engineer. Many of the people who take this class are business majors. They're not taking a data structures class, and have no desire to become programmers of any kind. There really ought to be another class for such people. In fact, sometimes I think a few basic programming skills ought to be required of all students. However, I would never wish this particular class upon the student body at large. This other class would be like Physics 100, which I gather is a physics class for people who really don't like physics. It would probably be taught in some version of BASIC, maybe VBA since it's infinitely more useful for many people than any other language. Ideally, it would be something where students can type things in at a command line, rather than having to write, compile, fix compiler errors, recompile, test, fix runtime errors, recompile, etc. There would probably be no need to deal with OOP, but maybe they'd touch on it at the very end.

As it is, no one is going to learn anything from a single class like CSCI 101, especially when we spend more time worrying about things like header files than we do actually writing code. I guess that's the whole point of Ruby. The programmer's job is to write code, and the interpreter takes care of everything else, like memory allocation. Anyway, I have a few problems with the way our class is taught, as well, but I'm sure I'll post about that another day.

What I wanted to post about was actually an exchange with Rollerblades Kid. I was complaining about what I called "bullshit" on the test. I tried to reproduce one from today's test from memory, but Blogger tried to interpret the << operator as the beginning of an HTML tag and it got all messed up. In any case, we have a couple of functions that have a more or less random assortment of +'s, -'s, switch statements, if statements, arguments being passed by value/reference, etc. They don't correspond to anything real at all, it's just arbitrary data manipulation. We have to trace through the program, then write down the output it would generate. Admittedly, these problems are pretty simple, and I guess they're okay for test questions, but it completely goes against the principles of good code writing. You can't use descriptive variable names when your variables do not in fact describe anything.

In any case, Rollerblades Kid didn't seem that concerned with this type of problem, because he was used to them from the AP Computer Science test (which I didn't take), but he and Ashley both objected strongly to "Star shapes" problems. The kind which are supposed to print output like:

*
**
***
****
*****
******

or

*
***
*****
*******
*****
***
*

I must admit that, in modern times, when we have the ability to use "real" graphics, there is no need to learn this particular skill. Yet for some reason, I find it much less like a pointless busywork assignment than the "bullshit" trace problems. I think that's because it solves a real problem. Not real as in real-world. Just real as in, there's an actual problem with a non-trivial solution, and the code is that solution. Yes, it's a problem you may never face, but the same could be said of so many problems you're asked to solve as classwork. Still, it's hard to explain just what it is that, to me, makes Star Shapes problems seem not to be completely worthless. You can actually learn something about good programming style from such problems. But of course, there is absolutely no guarantee that will actually happen.