Tuesday, March 31, 2009

Game Design Concepts: an Experiment

For those of you who I met at GDC and found their way here, welcome!

One thing I talked to a lot of people about is an experiment I'm doing this Summer, called "Game Design Concepts."

This is a free online class that I'm going to teach. It is not affiliated with any college or university, and not for credit. It will be taught through a combination of blog, email and wiki. It contains all of the information (and then some) in one of the game design classes that I normally teach in a classroom in exchange for tuition money. But I'm releasing it for free this Summer.

The subject of the course is, as you might expect, game design. The intended audience is:
  • Students who are interested in game design, and either are at a school that doesn't teach it well or doesn't teach it at all (or maybe you just want a second opinion).

  • Teachers, especially those who teach game design. You can compare my material with that of your own class. Maybe you'll find some useful resources that you didn't know about, and maybe you'll be able to offer me some hints in return.

  • Game developers who aren't designers. In a lot of companies, game design is still considered something of a "dark art" and those who aren't designers are often curious about how game design is done. In a few hours a week, this whole other field can (hopefully) be demystified.

  • Game designers. Do you have an interest in contributing to education? Do you want to know what it is that the next generation of designers -- the ones who are likely to report to you in 4 to 6 years -- are being taught in the classroom? This is a way to find out, and contribute your own experience in the process.

  • Anyone else with an interest in learning more about game design. For example, parents or grandparents of game designers who are curious about what these kids are doing; or hardcore gamers who want greater insight into the design decisions that make their favorite games so great.

If I've got your attention and interest, the blog is at gamedesignconcepts.wordpress.com and all updates (including instructions to register) will be posted there.

Tuesday, March 17, 2009

Gearing up for GDC

It's that time of year again. I can't believe it starts in less than a week.

If you're going to GDC this year for the first time, here's a link to my advice for what to bring with you. And here's another link to Darius's store of GDC advice. Be prepared!

If anyone wants to meet up, there are three easy places to find me. First, I'm speaking at the Game Education Summit on Monday. Second, I'll definitely be at the blogger group gathering on Thursday. Third, it's tradition by now that I'll be up early for breakfast on 3rd floor of Moscone West each morning, at the tables right near where the escalators dump you out. Look for the guy who has board and card games.
Posted by at 3 comments:

Sunday, March 15, 2009

Culture Shock: Learning Disabilities

Autism. Aspberger. OCD. ADD. ADHD. Tourette's. Bipolar. You name it, someone in the game industry has it. Probably several someones, and probably at least one someone who is incredibly successful.

For this reason, it's hard for me to even call these "disabilities" -- given that the word "disabled" literally means that the person is not able to do something, and clearly it is possible to make games regardless of what psychological label might be applied to someone. But then, I'm not a psychologist.

For the most part, people in the game industry don't care if you've been diagnosed with anything, as long as you can help them make great games. You could be criminally psychotic for all we care, as long as it doesn't impact the development schedule. (Okay, I exaggerate. But only slightly.)

So, it took me by surprise the first time a student gave me this little slip of paper from the campus office of disabilities, several years ago (I've since gotten used to this ritual; it seems there's always at least one per class, and usually more).

For those of you who have not taught before, here's how it works: the student brings you this paper that gives you (as the teacher) no practical information, except to tell you that the student requires some special privilege (commonly, extra time and privacy when taking exams). You have to sign it -- in all the places I've taught, I've never been allowed to keep a copy -- and then the student takes it back. Presumably it gets filed somewhere, I don't know.

And then, naturally, you forget about it, because you're not allowed to keep a copy. Until exam time comes, and you remember that two of your students have special requirements, but you can't remember which students (many students with so-called "disabilities" are quite high-functioning), and one of them might have dropped your class a few weeks back anyway. Oops. I've been doing this for a few years and I still manage to screw this up most of the time.

The most frustrating thing, though, is that you're given no information about how to teach more effectively. I understand and accept that we're dealing with confidential information on a need-to-know basis, and I will often be getting the bare minimum of relevant information. But this conflicts with a desire to teach properly, and if I know that (for example) talking more slowly or repeating myself will help or hurt the situation, or if making my lecture notes available is useful, or if I should avoid calling on a student in class because it would embarass them... well, it'd be good to know, but there's no way for me to find out without a confidentiality breach.

The obvious thing to do in these situations is to talk to the student directly, and simply ask if there's anything you can do... but often the student doesn't know, because they aren't a professional educator.

Best solution, I suppose, is to take matters into my own hands. Read books on as many of these disabilities as I can find, particularly any that might give clues on how to teach better, and hope for the best.
Posted by at 4 comments:

Thursday, March 12, 2009

Last-Minute Begging

I see this happen from all kinds of people.

Students: "I know I haven't turned in half of the assignments and I haven't been in class for the last month and this is the last week of the term, but I'm failing the class and is there any way I can do something for extra credit?"

Professors: "I know grades for this term were due a few weeks ago, but I've been so busy with other things that I never got around to sending them in. I hope that didn't inconvenience you by preventing your graduation, or making it impossible for you to get a final transcript for that job you're applying to. I'll get it in this week, I promise!"

Professionals: "I know you asked me how I was doing on my task list every week for the entire project and I've said fine, but I realize now I'm three weeks behind and we've got a milestone due tomorrow. Can I get some help?"

For some reason, some people have a really hard time saying that they're behind until it's too late to do anything about it. And yes, I've been guilty of this in the past, which makes me quick to spot it in others.

Now if only I can find a way to convince students of the danger of this without them having to live through the hell-stress of being about to fail, before the lesson sinks in...
Posted by at 1 comment:
Labels:

Wednesday, March 04, 2009

IDEO's Ten Tips for Teachers

Brenda pointed me at this article about creating a "21st century classroom experience." This has nothing to do with game design per se, except that just about all of these tips are restatements of basic game design principles, suggesting once again that game design is applied education (or maybe it's the other way around).

Summary of the tips and their context as a game design teacher (several points in the article are restatements of one another, so I collapsed them):
  • Don't just push information. Encourage students to think critically by creating an environment where the students can (and want to) ask questions. Translation: let the player actually play in your game world. How fun would a game be if it just told the player to enter a certain code and then asked them to play it back?
  • Make it relevant. Don't just explain arbitrary facts, put it in the context of how they're actually used so the students can see a connection between theory and practice. I've already written about that a couple of times.
  • Soft skills are important. What will really make the difference is your students' abilities in leadership, empathy, communication, teamwork, and other things that are hard to measure on multiple choice exams. This is why games like The Sims and World of Warcraft are popular, despite them not having distinct measurable goals.
  • Allow for variation. Education isn't one-size-fits-all; different students have different levels of ability and prior experience. Translation: include multiple difficulty levels in your game.
  • Give practical experience, not just theory. The article goes so far as to say that teachers are "designers" so apparently I'm not the only one saying this. Translation: if it's nothing more than a series of cut scenes, it isn't a very fun game. Or, as Sid Meier has famously said, "if the designer is having more fun than the player, you have made a terrible mistake."
Posted by at 4 comments:
Labels:

Sunday, March 01, 2009

Teaching Iteration and Risk-Taking

There is an inherent conflict between the nature of classes and course objectives, when it comes to designing a game as a class project.

The best way to learn to design games is to make a rapid prototype, fail miserably, figure out what you did wrong, and try again. Repeat until you get it right. In order to do this, the student has to feel like it is okay to take risks, that it is perfectly acceptable (even expected) to try crazy stuff that may simply not work out.

But of course, this is for a grade. Enter the fear of failure. Or, it's not for a grade at all. No threat of failure, but likely no effort put in by students on an "optional" project. Is there a way around this paradox?

Here's the method I'm currently using:
  • My non-digital game design project has four milestones. The first is just a high concept, target audience, basic information (number of players, etc.) and some core mechanics. The second is a rough but playable prototype. The third is a playtested prototype, with the mechanics finalized or close to it. The final milestone is a polished product.
  • All milestones are graded. Early milestones are easy points -- just turn in something, anything, as long as it works. Later milestones are graded based on the quality of the design -- you'd better have done some iterations.
  • For the future, I'm thinking that early milestones should be worth fewer points than later milestones. This puts less importance on early work and more focus on the final product.
  • On the days where milestones are due, students bring their works-in-progress to class and present the work for peer review. This also gives me a chance to see how the projects are progressing. In the future, I should probably just give a grade right then and there for the early milestones.
  • Make it clear to students from the beginning that the more they iterate on their project, the more they playtest, the more they fail and then change, the better their final project will be. Unfortunately, this is one of those things they might just have to find out the hard way for themselves. I'll try bringing in a student work from an earlier course (with permission) in its various stages of completion, to show just how much difference playtesting can make.

Saturday, February 28, 2009

Blogging on Applied Game Design

In addition to this blog, Brenda has given me the ability to post on the Applied Game Design blog, so I will occasionally make posts over there about the theory and practice of game design.

Why not just post here? I want this blog to remain a resource for students and educators about teaching game design, and my own rantings on how to actually make better games are best done elsewhere.

Any post over there by 'ai864' is me. I've already made my first post.

I will still be writing here about teaching game design, of course.
Posted by at 1 comment:

Wednesday, February 25, 2009

Theory of Fun back in print!

Raph Koster's A Theory of Fun for Game Design has been out of print for a few years, making it obnoxiously difficult for anyone to actually buy it for less than 200ドル or so.

Happily, it is now back in print for about 15ドル.

I suspect a lot of teachers will suddenly be adding another book to their required texts next term...
Posted by at No comments:

Global Game Jam article on Gamasutra

For those of you who are wondering what was going on during the Global Game Jam, Stephen Jacobs wrote up a fantastic blow-by-blow account of the action. His article is on Gamasutra.

I'm even quoted a few times in the article.
Posted by at 1 comment:
Labels:

Friday, February 20, 2009

Sometimes, I teach a little too well...

The other day, I met some people who are thinking of hiring a game designer, I mention that I'm available for contract work.

One of my students who was present stepped in front of me and mentioned that he's also available, and cheaper to hire than me.

I know that I always say to pay attention, be observant, be ready to pounce on an opportunity... and apparently some of them actually listen. I'm thinking that, in the long run, this is probably a good thing.
Posted by at 1 comment:

Wednesday, February 18, 2009

Summer Internships

The question was recently raised on the IGDA Game Educators mailing list: how can students find summer internships in games? If you're a student, this is probably on your mind; if you're a professor, students will probably ask you. I posted a response there, but I thought it's worth saying here.

First, let me say that internships in the game industry are rare. This is not about game companies being mean, or hating students. It's because game projects typically take longer than a summer, and development teams don't particularly like it when a key project member leaves in mid-project. It also takes people time to ramp up, which means just around the time the intern is finally able to contribute something to the team, they leave. Also, interns take a lot of management time that a typically-overworked producer does not have, so many studios decide that it's just not worth it.

This is not to say that internships don't exist, merely that the companies that offer them tend to be low-key about it (lest they be flooded with tens of thousands of resumes from eager college students). That means they aren't advertising, so you have to find them other ways (see below).

My advice to students seeking summer employment:

First, do your homework. Research a lot of game companies, go to their corporate websites and see if they have internship programs. Best bets are local companies, since realistically you aren't going to get housing or relocation expenses (some companies won't even consider you for an internship unless you live in the area). Be willing to look at lesser-known companies (not just the big names that you drool over), and look in related fields like serious games -- fewer students are looking there, so there's less competition.

How do you find local developers? First, check GameDevMap. Second, check if there's a local IGDA chapter. Third, check Google with a search string that implies game developers in your local area. Fourth, check with your school's career services office... but you probably won't find anything there that you couldn't have found on your own, which is why I list it last.

Some "internships" may not be listed as such; rather, they may be called "QA" positions that just happen to span the summer term.

If you can't find anything in games, consider a related industry. Programmers can do a programming internship at any software company and still gain valuable experience. Artists could work in fields like advertising or industrial design.

If you absolutely can't find any paid work, finances permitting, "hire" yourself full-time to work on your own game projects! Force yourself to work 40+ hours per week on your own game, as if you were at a full-time job. (This works even better if you have some friends you can team up with.) Keep your scope small, so that your projects are achievable. The point here isn't to "start a game company" or "make a great game and sell it" -- the point is to get valuable experience making games. If your project sucks, that's fine, as long as you learned something from the process. If your project does end up being awesome, enter it in the IGF student showcase, which is just as juicy a resume bullet-point as an internship (if you win).
Posted by at 1 comment:

Sunday, February 15, 2009

Does "online" mean "automated"?

It seems to me that every school that offers online courses does things a bit differently. For the classes that I teach online, I try to have as much interactivity as I have time for. I'll post on discussion boards, I host virtual "office hours" through an online chat program, and I send out regular emails with my own personal spin on the topic. I also offer feedback through grading papers, even if it takes me longer.

I realized today that in theory, the entire thing could be automated:
  • The course content is all online, so there's no reason why I need to add anything to it. Let the students read it on their own without the professor offering any extra commentary.
  • The discussion boards are for students to interact with each other, not the professor. When "participation" is one of the grades of the course, there are tools where you can get post counts, average length of post, and all kinds of usage stats without ever having to actually, you know, read what one of those student people is actually saying.
  • Papers can't be automated easily, but if you design the course you could go light on those assignments and heavy on multiple-choice and fill-in-the-blank quizzes which can be graded by a computer system.
  • Instead of holding regular "office hours", simply post your phone number and let students call if they need help with anything. You know they never will, whether it be from feelings of politeness or intimidation.

Not that I would ever teach this way, mind you. I don't think it's really teaching if I'm not involved, it's more like a long, drawn-out certification process.

On the other hand, it's easy to "teach" a class this way, so I'm sure there are people out there who do it like that. Some might just be overwhelmed with other things in life so they fall back on something easy. Others might be greedy and want extra pay for next to no effort. Still others might think this is what online classes are supposed to be, that once you get a computer involved it somehow means humans should be removed from the equation.

I suppose the lesson here for students is: buyer beware. Make sure that you're getting your money's worth when signing up for an online class, and make sure you know what kind of instruction and personalized attention you can expect. If all you're looking for is a few quick credit hours without having to leave your dorm room that's one thing, but if you're actually looking for an education then do your due diligence. (Put at least as much effort into shopping for a class as you might into getting a high-end stereo system for your dorm, since that's probably about what you're paying.)

Interestingly, I think there's a parallel here with outsourcing in the game industry, in that many companies that think "outsourcing" really want the thing they're outsourcing to be automated (and they find out to their chagrin that game development is not so easy a process to automate).

Posted by at 3 comments:
Labels:

Wednesday, February 11, 2009

What is the teacher's most valuable IP?

I have an ongoing discussion with several colleagues about the basic question of where a teacher's value lies. This is particularly important in a field like game design, where a new professor is likely going to be the only one in the department with any game-related expertise and will therefore be doing some curriculum development, some course content development, and of course the actual teaching.

There seem to be two schools of thought with respect to this.

The first model, I'll call "value in output." The professor is a machine that converts money and coffee into curriculum and course materials. The real value is in these secrets of the field that the professor distills into small documents like lesson plans and curriculum documents. This is valuable information that must be protected. You can tell the schools that think this way because they have something in their contracts that makes sure the school gets IP ownership of the professor's work, or (at the very least) they would be very much against a professor releasing this material to the public, or taking it to another school.

The second model, I'll call "value in person." The idea is that it is the professor who is valuable, not the work. A skilled professor can always create more classes, revise the curriculum or what have you, and it is therefore the human being that has value. An analogy would be valuing the goose more than the golden eggs. You can tell the schools that fall into this category by their willingness to release their course content online, give their professors more control over their own work output, and are generally happy to just sit back and do nothing as long as the profs are bringing glory to the school.

We have this in the game industry, too. Where is the value in a game: the IP, the code base, or the development team? Depending on a publisher's viewpoint, they will treat their developers very differently.

If you're a teacher or a developer, think for a moment about how your school (or your publisher) sees you and your contributions. Is there more focus on your work output, or your ongoing ability to produce that output? Which view is superior? If the answer is "it depends," what does it depend on?
Posted by at 4 comments:

Saturday, February 07, 2009

Speaking Schedule

Yesterday, I was in Savannah giving a presentation with Brenda at SCAD to other educators about the use of games as a teaching tool. It was intended as a combination of my earlier Origins presentations and our Game Design Improv event.

I learned something interesting here: when talking about games in education, I take for granted that most of the time I'm talking to educators who already play games heavily (or teach game development), so the use of games in the classroom is not a hard sell. In this case I was speaking with professors from art history, photography, audio, film, media studies, and several other fields that are not directly related to games. We spent a lot of time discussing whether games were worthwhile for classroom use at all, and if so in what situations. It was a wonderful discussion that really challenged us all, and it's a discussion I'm not used to having. I was also impressed by the high degree of game literacy from these professors who were not gamers; participants referenced a number of game industry personalities and important games. Apparently it's not just game designers who study other media; they're paying attention to us, also.

Coming up, I've got a few speaking engagements. I'm speaking at GDC, both times during the Education Summit. I speak twice: I'm doing the next iteration of Game Design Improv with Brenda, and also speaking with Susan Gold and Gorm Lai about the results of the Global Game Jam.

The month after that, I'll be at GDX (here's last year's site, the new one isn't up yet), speaking about the relationships between art history and game design -- basically, why game designers should take at least one art history class, and why they should pay attention. (Short answer: because we may feel like games are a new medium and we're blazing new trails, but an awful lot of what we're doing with games-as-art is stuff that the art world already addressed hundreds of years ago, and we need to understand this so we don't keep reinventing the wheel.)

Monday, February 02, 2009

Running for IGDA Board

The IGDA elections are underway, with four board seats open. I've thrown my hat into the ring.

If my personal statement sounds like something that resonates with you, I'd appreciate your vote. And if you're not a member of the IGDA... well, this is as good an excuse as any to join.

Thanks for your support.
Posted by at 3 comments:
Labels:

Wednesday, January 28, 2009

Global Game Jam this weekend

After many months of planning, site wrangling and organizing, the Global Game Jam will take place this weekend. We have 54 host sites in 51 different cities, 24 countries and 14 time zones. We're currently looking at somewhere in the neighborhood of 2000 participants. It's pretty amazing how big it's grown in just the last few months.

I'll be providing realtime support to the sites for the entire weekend (minus the time when I'm sleeping) from my home office in Columbus.

If you're not already signed up, see if there's a location near you.
Posted by at No comments:
Labels:

Tuesday, January 20, 2009

Awkward Moments

A short collection of social awkwardness as experienced by a game-designer-turned-educator, in no particular order:
  • Having several students admit that they played a game you worked on, when you know the game in question wasn't particularly good. (Additional awkwardness: when the game in question is M-rated, and you know that the students were underage when they played it.)

  • Giving a game design constraint for an in-class exercise, and repeatedly being asked questions about the exact boundaries of the constraint... and realizing simultaneously that my students are trying to weasel out of the constraint (and that I should be annoyed), and also that my students are trying to precisely define the constraint (which is an important skill for game designers, and something I should be proud of).

  • Witnessing a student fall asleep in class, and hoping that it's because the student got no sleep and not because I've really become that boring. (Additional awkwardness: waking the student up, and hoping that I done it in a way that I haven't cruelly humiliated them.)

  • Assigning a homework that's not only easy but actually fun, and seeing that half the class didn't bother to complete it. And then wondering if my definition of "fun" has changed.

  • Writing something out (an assignment, a syllabus, an email, etc.) that I thought was clear as could be, and having students not understand it. This either means I'm not as good a writer as I thought, or that my students aren't functionally literate, or that my students are lazy... and no matter which it is, there's nothing I can be happy about.
Posted by at 9 comments:

Wednesday, January 14, 2009

Book Writing: Tips, Tricks, Cheat Codes

Because we're both game developers, Brenda and I conducted a post-mortem of the book we wrote. Because many professors write their own textbook eventually, I thought it might be nice to share what we learned with you. (After securing the go-ahead from Brenda, of course.)

To protect the innocent, I won't say what we got "right" or "wrong"... but this is what we learned, for better or worse.
  • Write with a co-author that you already know you work well with. I really can't stress this enough. Aside from halving the amount of work you have to do, it's great to have someone to bounce ideas off of, and it's kind of like having an extra technical editor for free. It's also a lot harder for the project to stall when you know that someone else is counting on you (a friend and colleague, not just some monolithic book publisher).
  • Use some kind of version control system. It doesn't have to be as elaborate as Visual SourceSafe or CVS, but you will be making many changes and revisions to documents, and you will want to have a history in case you need to reference that paragraph that you deleted three months ago and now you want to use it in a different chapter. We found that simply numbering the documents (Chapter01_v1.doc) was sufficient.
  • Use the Track Changes functionality in Word. It's great. It's like a version history built-in. Use the comments to communicate with your editor and other authors.
  • If you're working with another author, use Google Docs for preliminary work. It's a free, convenient way to share chapters, and if you're on an instant messaging program (or on the phone) you can even edit the same document at the same time. You can always add any special formatting later, after importing into Word.
  • Keep track of the current status of each chapter (not started, rough draft complete, final draft complete, submitted to publisher, accepted by publisher) in an Excel document. Update it whenever you finish anything. This is especially important if working with another author, so you know who is currently editing what (you run into a lot of "did you finish this chapter and it's waiting for me to review, or were you still working on it?" questions).
  • Choose your book topic carefully, and whenever possible write about what you already know. Everything that you have to research takes extra time, and a book where you have to research everything will take a lot of time.
  • When you're working with the publisher on the initial schedule, build time in the schedule for iteration. There are a lot of tasks that affect the entire book (consistent formatting, terminology, overall structure and other things) that you'll want to change several times as you write, and the easiest way to do this is just to make one final pass over everything at the end... rather than making these changes several times over the course of the project. But you only get to do this if there's time, and if you're rushing to meet the deadline then the whole thing can look a bit sloppy.
  • As a corollary, keep a list of open issues for the book, so that nothing falls through the cracks. Keep it updated whenever you run into a problem that you want to defer until later, and reference it when you're doing revisions.
  • Find people to review different parts of your book (friends, colleagues, grad students... anyone who you think would give you good feedback for any particular chapter) and start that process early. If you're writing a textbook intended for classroom use, teach a class from an early version to see how it will actually function (think of it as a "beta test").
  • Get constraints from your publisher early on regarding number of chapters and pages, and find out the approximate ratio of pages in Word to printed pages in the book (a ten-page Word document might be twice as many pages in the book because of extra whitespace added to sections so the paragraphs aren't split between multiple pages, or to allow extra space around figures and photo images). This prevents you from finding at the end of the project that you suddenly have to add or cut a bunch of content.
  • While I'm on the subject of images, get your images early. Securing the rights to photos of people, screenshots of games, company logos, and so on takes a lot of time.
  • Develop a system for references to other parts of the book (for example, "See Chapter X, Page Y" when you don't know what the final chapter and page numbers will be). If you use actual numbers, you'll just have to end up changing them later... and woe to you if you accidentally miss one.
  • Create a core statement for the book up front. Do you want to write in a professional or casual tone? Do you want to focus more on content or concepts? What is the underlying theme, the one thing you really want the reader to understand when they're done -- the common thread that ties everything together? Revisit your core statement when you're reviewing or revising your chapters.
  • Clear your schedule if at all possible. Writing a book takes a lot of time, and if you're trying to balance that with teaching classes, doing freelance work and remodeling your kitchen, you are just not going to have the energy. If you minimize your downtime and interruptions, things will go more smoothly.
  • Do your due diligence with publishers. If you've got a great idea for a book, then it should be a great idea no matter who the publisher is. Seek publishers who have a line of successful books in your field, so that you can get some decent cross-pollination with readers of other books in the same series. Look for publishers with wide distribution networks. Think of whether your publisher has the means and understanding to promote your book (or, whether they're willing to let you do some self-promotion). Find out who your editor(s) will be, and how much experience they have (if any) in your field; if you've written a book before, you may be able to request a specific editor for your book. At any rate, there's no reason why you should just take the first offer that comes along and accept all terms without negotiation... any more than you would with a job offer.
  • Keep backups of everything. If all of your work is on your home computer hard drive and that hard drive crashes five days before the next scheduled milestone submission to the publisher... well, I'm sure you can imagine.
  • And lastly, don't expect to get rich as a book author, any more than you would as a game developer. The advance you can expect as an author is not very much when you compare to the amount of time you're going to spend on the project. Yes, you can make a lot of money if your book sells well enough to earn you royalties, but that is the exception and not the rule. This doesn't mean you shouldn't write a book... but if you write one, do it for reasons other than money.

If there are any other textbook authors in the audience, please comment and share your own tips.

Posted by at 2 comments:

Thursday, January 08, 2009

One Easy Step Towards Interactive Teaching

I've said before that classes are more interesting to students if you can make them more game-like, i.e. to give the students some interactivity (if not actual decision-making) rather than just lecturing at them.

If you're a teacher who is used to just speaking at your students and want to break yourself of the habit, here's an easy experiment for you to try in your next class:

1) Look over your lesson plan, and pick out one thing that is ambiguous, unknown, open to interpretation, or otherwise has no "right" side or answer. (Example in a biology class: the definition of the term "life".)
2) Design an open-ended question about the thing you chose. (Continuing the above example: "How would you define the term life?")
3) At some point in your lecture, ask the question to your class, and wait for the students to try to answer. If it takes a few seconds before you see any raised hands, that means they're actually thinking about your question, which is a good sign (or it means they're asleep, which is a sign that you've been lecturing for too long). Sometimes students will raise their hand to elaborate on (or even disagree with) a previous student's answer; encourage this, as you're creating an interactive dialogue among your students. If one student gives an answer and no one else feels like adding to it, challenge it yourself; play devil's advocate. But if at all possible, confine yourself to a role as moderator; if you chose a good question, your students will do your work for you.

You might notice a few things about this method:
  • It gives your own voice a much-needed rest in the middle of a long lecture :-)
  • Your students will actually be paying close attention.
  • Your students will actually be thinking. In class, no less.
  • As often as not, one of your students will say something particularly insightful that makes you think.

If you try it and like the results, increase the number of questions. Personally, my classes are usually about two hours, and I shoot for a goal of at least three discussion-questions per class. But if you're not used to it, you can work up to this one question at a time.

Posted by at 3 comments:
Labels:

Tuesday, December 30, 2008

One Myth About Teaching

I was confronted with the opinion the other day that teachers are overpaid because they only have to work 9 months out of the year but get paid for a full year. I'm pretty sure the person who expressed this opinion has never actually met a teacher before, but it seemed like a thought that a lot of people might have. So, I thought I'd set the record straight.

First, a teacher in any field typically gets paid a bit less than a working professional in that field, even though they have to know just as much (if not more). This is why a lot of teachers feel underpaid for their work -- because with their qualifications, they could make more if they weren't teaching.

As for being underworked, I know of very few teachers who sit idle on summer/winter break. In my own experience, the time fills up fast:
  • There's a lot of prep work to do for classes before they start: revising syllabi and course content, evaluating new textbooks, and keeping current with industry trends all take time.
  • If you're teaching any brand new courses, you have to develop everything from scratch, which typically takes about as much time as teaching the course itself (i.e. one new course = two old courses, in terms of time commitment).
  • Keeping professional skills sharp is important. Over breaks I usually end up doing some kind of freelance contract work.
  • Ever heard of summer and winter classes? A lot of teachers hold classes over these supposed "break" periods.
  • And of course, during the academic year teaching is a lot more than just a 9-to-5 job. In theory you're supposed to have a 40-hour work week, which is 4 or 5 classes if you're full time (that includes face time in lecture or lab, and also out-of-class time spent grading). But in addition to that, you have other duties: academic advising, office hours, faculty meetings, and (if you're really unlucky) being on a committee.

In reality, teaching is more than a full-time job.

Does that mean that these thoughts of "lazy" teachers who only work "30 weeks out of the year" are completely inaccurate? Unfortunately, no. It is possible to reduce the workload. You can hold office hours for your classes simultaneously, and then use the time to get other work done if no students show up (although this means you'll end up treating students like they're interrupting you when they show up for scheduled office hours). You can just copy your course notes from earlier classes without updating them, which reduces prep time to almost zero (but then you cheat your students out of a modern education). You can set up your assignments so that they're easy to grade (but anything easy to grade is usually not that meaningful -- for example, you can tell a lot more about a student's understanding by reading an essay than you can get from a multiple-choice question, but multiple-choice is easier to grade).

So, it is possible to have lots of time off, work 40 (or fewer) hours per week for 30 weeks a year, and have the rest of the time free to... um... do whatever teachers do when they're not working. But so far, the only way I've found to do that is to cheat your students. If you want to be a good teacher, forget any thoughts you had of annual three-month vacations...

Posted by at 4 comments:
Subscribe to: Posts (Atom)

AltStyle によって変換されたページ (->オリジナル) /