I knew this was going to be a busy week, but it wasn't until I looked at my calendar this evening that I saw just how busy. My PDA's calendar (I have an ancient PDA) has this feature where you can see your week "graphically", with bars where you have things scheduled. My blocks for Monday and Tuesday are *solid* from 10am until well into the afternoon/evening (5:30 one day, 4:30 the other). This includes 2 lunch meetings. Gah. And Wednesday is not much better, although at least I don't have a lunch meeting that day.
I remember at one point last year, one of my senior colleagues came in to my office and asked me some question about some future event we were planning, and I said "let me bring up my calendar". When he saw my calendar, he actually gasped out loud. "Oh my god! Tell me your weeks don't normally look like that," he said. "Actually," I said, "this is pretty typical." He was appalled. There was some talk of figuring out ways to lighten my service load, or figure out some way to make my schedule less filled, but as you can tell nothing much came out of that.
I'm pretty good at saying no, most of the time. The problem is that what's important to me is sometimes at odds with what my school thinks I should be doing. For instance, I have assigned service responsibilities---some top-level (school-wide), some departmental. I suppose I could get out of these if I really raised a fuss, but the mentality here is that you do your share to help out. I'd much rather spend my time and energy mentoring students, supervising undergraduate researchers, working on issues that are personally important to me, but if I want to do these, then I have to do them as sort of a "voluntary overload"; they won't get me out of my other service commitments. Which I suppose is fair on some higher level, but what it means is that sometimes I have weeks that look like big blobs of obligations with precious little time for research, for class prep--for eating lunch, even!
I think it's a good thing when our senior colleagues become aware of the "real lives" of junior faculty. We're all way overscheduled, shouldering heavy burdens, asked to do so much while still trying to establish ourselves as researchers and teachers. That's not to say that the senior faculty are not pulling their weight--quite the contrary! But I think they sometimes forget what it's like at the early stages of an academic career, how stressful and hectic these times are, how hard it can be to balance everything. Perhaps if we continue to subtly remind them of this, they will one day help us figure out how to lighten our loads.
Sunday, January 29, 2006
Friday, January 27, 2006
The good, the bad, and the ugly
Shamelessly stolen from New Kid.
The Good
* Recipes from the Moosewood cookbook (Moosewood Cooks at Home, I think). Last night we made the Penne with Sun-dried Tomatoes and Capers (with a few substitutions--canned tomatoes instead of fresh, and spaghetti instead of penne). Yummy! and it was even better as leftovers today at lunch.
* Today I did one of my favorite lectures, which has a really cool demo that I made up. I've used this lecture/demo in several classes at various levels with lots of success, and the students enjoyed it today too.
* Supportive girlfriends. 'Nuff said.
The Bad
* Not being listened to in meetings, especially when it happens in department meetings.
* Writing letters of evaluation. I'm sooo sick of this right now!
* Grading. 'Nuff said.
The Ugly
Student evaluations. As part of the review process, I get to see all of my evaluations sliced and diced in various ways. And aye caramba! I've always heard that there is gender bias in student evaluations, particularly for women in male-dominated fields...I now know that this is in fact true. I never really picked up on it until I saw everything compiled together, but it was pretty obvious. Hopefully the tenure and promotion committee will recognize this too...but this will certainly make the review process more, um, "interesting".
The Good
* Recipes from the Moosewood cookbook (Moosewood Cooks at Home, I think). Last night we made the Penne with Sun-dried Tomatoes and Capers (with a few substitutions--canned tomatoes instead of fresh, and spaghetti instead of penne). Yummy! and it was even better as leftovers today at lunch.
* Today I did one of my favorite lectures, which has a really cool demo that I made up. I've used this lecture/demo in several classes at various levels with lots of success, and the students enjoyed it today too.
* Supportive girlfriends. 'Nuff said.
The Bad
* Not being listened to in meetings, especially when it happens in department meetings.
* Writing letters of evaluation. I'm sooo sick of this right now!
* Grading. 'Nuff said.
The Ugly
Student evaluations. As part of the review process, I get to see all of my evaluations sliced and diced in various ways. And aye caramba! I've always heard that there is gender bias in student evaluations, particularly for women in male-dominated fields...I now know that this is in fact true. I never really picked up on it until I saw everything compiled together, but it was pretty obvious. Hopefully the tenure and promotion committee will recognize this too...but this will certainly make the review process more, um, "interesting".
Blogging about teaching: the upper-level electives
In my last installment in my blogging about teaching miniseries, I'm going to talk about how I approach teaching the upper-level electives. These are courses that are typically taken by our more advanced students: sometimes sophomores, but more typically juniors and seniors, since they are the ones that are most likely to have navigated all of the prerequisite hoops.
In a sense, teaching the upper-level courses is easier than teaching any of the other courses in our curriculum. The topic is very well-defined. The students are somewhat advanced, typically have good programming skills (the "coding maturity" I referred to earlier), and are capable of thinking more deeply about computer science as a field. Usually, if you're teaching an upper-level elective then it's at least marginally related to your field of research, and thus you're fairly comfortable with it. But these same features also can make teaching these courses tricky. How deep, for instance, can/should you go? How much material can/should you cover about a field? How do you reconcile what's important to you--and what you're comfortable teaching--with what the "real world" expects students to know about the field? And how much programming should you expect in an upper-level course, versus covering more theoretical problems? In short, how do you best mix theory with practice in the classroom?
Personally, I tend to teach the electives that have higher numbers of prerequisites, so I have high expectations for my students. I expect them to put more time into their work, and I expect them to have to delve deeper to find answers to the problems I assign. I expect them to be able to make connections to other fields, to apply concepts to completely new areas, and to wrestle with less well-defined problems. Lately, I've been making my expectations more clear up front, so that the students know what to expect going into the class. This minimizes the frustration quite a bit--or at least if the students are frustrated by a particularly hard assignment or exercise, they are more willing to accept the frustration as part of the learning process. (This is one of the key lessons I learned in my first few years here, and one that's served me very well.)
So how do I address the theory/practice issue? The short answer is that I try to work in both. Since the students are more sophisticated programmers, I can assign larger and more complex assignments. I may, for instance, have the students read a real-life design document or specifications document and implement the system that's outlined in there. The neat thing about an assignment like this is that the students have to integrate everything they've learned so far in the CS curriculum. They have to apply good design principles. They have to consider the relevant theory when making design decisions: if some feature can be implemented several ways, what does the theory indicate as the best way to implement it under these circumstances? And they have to deal with things like the fact that these types of documents rarely spell out all of the details, and so design tradeoffs need to be made. In the classroom, I try to split my time equally among theory and practice. We'll discuss theoretical reasons why a particular concept does or doesn't work, and then come up with real-world examples of that phenomenon.
In summary, I find teaching upper-level classes fun and challenging. While I may not spend as much time prepping (learning) the material, I spend more time and energy coming up with relevant assignments and examples, thinking about how my class will fit the students' needs after graduation, and making sure that they continue to develop into deep thinkers and skilled programmers.
technorati tag: teaching-carnival
In a sense, teaching the upper-level courses is easier than teaching any of the other courses in our curriculum. The topic is very well-defined. The students are somewhat advanced, typically have good programming skills (the "coding maturity" I referred to earlier), and are capable of thinking more deeply about computer science as a field. Usually, if you're teaching an upper-level elective then it's at least marginally related to your field of research, and thus you're fairly comfortable with it. But these same features also can make teaching these courses tricky. How deep, for instance, can/should you go? How much material can/should you cover about a field? How do you reconcile what's important to you--and what you're comfortable teaching--with what the "real world" expects students to know about the field? And how much programming should you expect in an upper-level course, versus covering more theoretical problems? In short, how do you best mix theory with practice in the classroom?
Personally, I tend to teach the electives that have higher numbers of prerequisites, so I have high expectations for my students. I expect them to put more time into their work, and I expect them to have to delve deeper to find answers to the problems I assign. I expect them to be able to make connections to other fields, to apply concepts to completely new areas, and to wrestle with less well-defined problems. Lately, I've been making my expectations more clear up front, so that the students know what to expect going into the class. This minimizes the frustration quite a bit--or at least if the students are frustrated by a particularly hard assignment or exercise, they are more willing to accept the frustration as part of the learning process. (This is one of the key lessons I learned in my first few years here, and one that's served me very well.)
So how do I address the theory/practice issue? The short answer is that I try to work in both. Since the students are more sophisticated programmers, I can assign larger and more complex assignments. I may, for instance, have the students read a real-life design document or specifications document and implement the system that's outlined in there. The neat thing about an assignment like this is that the students have to integrate everything they've learned so far in the CS curriculum. They have to apply good design principles. They have to consider the relevant theory when making design decisions: if some feature can be implemented several ways, what does the theory indicate as the best way to implement it under these circumstances? And they have to deal with things like the fact that these types of documents rarely spell out all of the details, and so design tradeoffs need to be made. In the classroom, I try to split my time equally among theory and practice. We'll discuss theoretical reasons why a particular concept does or doesn't work, and then come up with real-world examples of that phenomenon.
In summary, I find teaching upper-level classes fun and challenging. While I may not spend as much time prepping (learning) the material, I spend more time and energy coming up with relevant assignments and examples, thinking about how my class will fit the students' needs after graduation, and making sure that they continue to develop into deep thinkers and skilled programmers.
technorati tag: teaching-carnival
Monday, January 23, 2006
Blogging about teaching: the mid-tier courses
The next installment of the blogging about teaching miniseries is about the mid-tier courses. I define mid-tier courses to be courses that are taken predominantly by majors and that form the "meat" of our major: the classes that introduce our majors to the large topical areas of computer science. These are courses like computer architecture, algorithms, some of the upper-level programming courses, etc.
The goals I have for students in these courses are obviously different from the goals I have for students in the intro courses. The key difference, obviously, is that these students have already committed to the major, so I don't have to do as much "selling"--they already know that computer science is the coolest major. :) What I need to do in these courses is to provide the students with a solid foundation, both deep and broad, in computer science; to get them thinking about the common questions that are threaded throughout all the subfields of computer science; and to prepare them for the upper-level elective courses.
One term that gets thrown around a lot by my colleagues and me when we talk about these courses is "coding maturity". And that's a good way to sum up one of the main goals of these courses: to get the students to a point where they are more "mature" programmers. These courses are all designed to get the students thinking more carefully about how they write programs: how they choose to store and represent data, how they structure their algorithms, how efficiently the programs run under a variety of inputs, how well the program solves the given problem. So the assignments should require the students to write longer, more complex programs to solve longer, more complex problems, to provide them with the practice that they need to develop "coding maturity". Ideally, these assignments should also present the students with compelling problems to solve. These are a bit easier to identify at this stage, since I can assume a baseline level of programming competence from these students.
Even though I don't have to "sell" CS, I still feel compelled to make CS relevant to the students--to remind them, in a way, that computer science does not exist in a bubble, that it touches almost all areas of our modern lives. And this colors my selection of problems, both to assign as homework and to frame discussion and lecture in class. Hurricane Katrina, sequencing the human genome, the design of the Xbox, web site accessibility, security breaches in the school's computer network--these have all formed the basis of recent examples in my classes. It takes a little effort to come up with relevant examples and problems, but the payoff is huge: the students remember the concepts better, because they are tied to something with which they are familiar; and it gets some of them to start thinking about how they can use computer science to make a difference in the world.
One challenge that I have at this level that I don't have (as much) at the intro level is dealing with students who are not really interested in the subject matter. After all, these courses are the required courses for our major, so of course not all students will be equally enthralled by all of them. The best I can do is to make the subject as compelling as possible to the largest number of students (by using interesting problems, for instance). Failing that, I can still make sure that they leave my course with the general skills they need to succeed in the other mid-tier courses and the electives: coding maturity and the ability to reason about computer science problems.
Next up: The final installment in the series--the upper-level electives.
technorati tag: teaching-carnival
The goals I have for students in these courses are obviously different from the goals I have for students in the intro courses. The key difference, obviously, is that these students have already committed to the major, so I don't have to do as much "selling"--they already know that computer science is the coolest major. :) What I need to do in these courses is to provide the students with a solid foundation, both deep and broad, in computer science; to get them thinking about the common questions that are threaded throughout all the subfields of computer science; and to prepare them for the upper-level elective courses.
One term that gets thrown around a lot by my colleagues and me when we talk about these courses is "coding maturity". And that's a good way to sum up one of the main goals of these courses: to get the students to a point where they are more "mature" programmers. These courses are all designed to get the students thinking more carefully about how they write programs: how they choose to store and represent data, how they structure their algorithms, how efficiently the programs run under a variety of inputs, how well the program solves the given problem. So the assignments should require the students to write longer, more complex programs to solve longer, more complex problems, to provide them with the practice that they need to develop "coding maturity". Ideally, these assignments should also present the students with compelling problems to solve. These are a bit easier to identify at this stage, since I can assume a baseline level of programming competence from these students.
Even though I don't have to "sell" CS, I still feel compelled to make CS relevant to the students--to remind them, in a way, that computer science does not exist in a bubble, that it touches almost all areas of our modern lives. And this colors my selection of problems, both to assign as homework and to frame discussion and lecture in class. Hurricane Katrina, sequencing the human genome, the design of the Xbox, web site accessibility, security breaches in the school's computer network--these have all formed the basis of recent examples in my classes. It takes a little effort to come up with relevant examples and problems, but the payoff is huge: the students remember the concepts better, because they are tied to something with which they are familiar; and it gets some of them to start thinking about how they can use computer science to make a difference in the world.
One challenge that I have at this level that I don't have (as much) at the intro level is dealing with students who are not really interested in the subject matter. After all, these courses are the required courses for our major, so of course not all students will be equally enthralled by all of them. The best I can do is to make the subject as compelling as possible to the largest number of students (by using interesting problems, for instance). Failing that, I can still make sure that they leave my course with the general skills they need to succeed in the other mid-tier courses and the electives: coding maturity and the ability to reason about computer science problems.
Next up: The final installment in the series--the upper-level electives.
technorati tag: teaching-carnival
Sunday, January 22, 2006
We interrupt these important pedagogical posts to bring you a meme
Seen everywhere else, most recently at PowerProf's: The 25 Things meme.
1. When you looked at yourself in the mirror today, what was the first thing you thought?
"I'd better get over this damn cold soon b/c I'm sick of looking like Rudolph."
2. How much cash do you have on you?
Probably about $20.
3. What's a word that rhymes with TEST?
Rest.
4. planet?
Mars is pretty cool.
5. Who is the 4th person on your missed call list?
The doctor's office.
6. What is your favorite ring on your phone?
Some R&B-type thing that came with the phone.
7. What shirt are you wearing?
Nike yoga T-shirt.
8. What do you label yourself?
Driven, energetic, happy, healthy (well, except for recently...ack).
9. Name the brand of shoes you've recently worn.
Target slippers.
10. Bright or Dark Room?
Bright. Preferably lots of sunlight.
11. What were you doing at midnight last night?
Snuggling w/ Mr. Jane (awwwwww).
12. What did your last text message you received on your cell say?
I don't usually text message.
13. Where is your nearest 7-11?
I have no idea.
14. What's a saying that you say a lot?
"Basically"
15.Who told you they loved you last?
Mr. Jane.
16. Last furry thing you touched?
My slippers.
17. How Many Drugs Have You Done In The Past three Days?
Just cough drops, although I'm really tempted to hit the Sudafed.
18. How many rolls of film do you need to get developed?
None--my camera's digital.
19. Favorite age you have been so far?
32--it's a power of 2!
20. your worst enemy?
Unsupportive Junior Colleague.
21. What is your current desktop picture?
On which computer? Let's see: wildflowers, a dragonfly, a water droplet on a leaf. (all pictures that came w/ the computers)
22. What was the last thing you said to someone?
"No, I don't think Denver has any more timeouts left."
23. If you had to choose between a million bucks or to be able to fly, which would you choose?
Flying would be cool, but the money's more practical, so I guess I'd take the money.
24. Do you like someone?
Yes. Lots of someones.
25. The last song you listened to?
"Let Go" by Frou Frou (Garden State Soundtrack)
1. When you looked at yourself in the mirror today, what was the first thing you thought?
"I'd better get over this damn cold soon b/c I'm sick of looking like Rudolph."
2. How much cash do you have on you?
Probably about $20.
3. What's a word that rhymes with TEST?
Rest.
4. planet?
Mars is pretty cool.
5. Who is the 4th person on your missed call list?
The doctor's office.
6. What is your favorite ring on your phone?
Some R&B-type thing that came with the phone.
7. What shirt are you wearing?
Nike yoga T-shirt.
8. What do you label yourself?
Driven, energetic, happy, healthy (well, except for recently...ack).
9. Name the brand of shoes you've recently worn.
Target slippers.
10. Bright or Dark Room?
Bright. Preferably lots of sunlight.
11. What were you doing at midnight last night?
Snuggling w/ Mr. Jane (awwwwww).
12. What did your last text message you received on your cell say?
I don't usually text message.
13. Where is your nearest 7-11?
I have no idea.
14. What's a saying that you say a lot?
"Basically"
15.Who told you they loved you last?
Mr. Jane.
16. Last furry thing you touched?
My slippers.
17. How Many Drugs Have You Done In The Past three Days?
Just cough drops, although I'm really tempted to hit the Sudafed.
18. How many rolls of film do you need to get developed?
None--my camera's digital.
19. Favorite age you have been so far?
32--it's a power of 2!
20. your worst enemy?
Unsupportive Junior Colleague.
21. What is your current desktop picture?
On which computer? Let's see: wildflowers, a dragonfly, a water droplet on a leaf. (all pictures that came w/ the computers)
22. What was the last thing you said to someone?
"No, I don't think Denver has any more timeouts left."
23. If you had to choose between a million bucks or to be able to fly, which would you choose?
Flying would be cool, but the money's more practical, so I guess I'd take the money.
24. Do you like someone?
Yes. Lots of someones.
25. The last song you listened to?
"Let Go" by Frou Frou (Garden State Soundtrack)
Wednesday, January 18, 2006
Blogging about teaching: the intro courses, part 2
In part 1 of my blogging about teaching miniseries, I talked about the challenges of teaching the intro course. In part 2, I'd like to talk a bit more about content. The fourth goal I have in teaching an intro course, as I mentioned previously, is "making sure that at the end of the class, everyone has some baseline skill in programming a computer". But what, exactly, does that mean? And how do I reconcile that with the fact that my student population is all over the map, in terms of skills and expectations for the course?
The baseline skill I expect out of my students is this: Can you take a nontrivial problem statement and turn this into a functioning computer program that solves the problem? Are you comfortable designing, implementing, and debugging such programs? This is sufficient for all populations: the students that will never take another course know how to write a basic computer program, and the ones that go on will have a base set of skills that they can further refine in the next classes.
Notice that "writing pretty code" or "writing efficient code" is not a baseline skill. Why? Well, the best I can do at this stage is to model, and discuss, "good" programming practices in class, but there's so much other material and so many concepts that the students *must* grasp before the end of the course that I can't focus on this as much as I'd like. The students for whom those two skills really matter are the ones who will go on to take more CS courses--and the next course in the sequence focuses heavily on good, efficient design of programs, so they will see it soon enough. I also find that some students will naturally pick these good design skills up on their own--if they see good models, they will try to mimic them to the extent that they are able.
But that's all at the end of the course. The trickier question is what happens in those first few weeks---how do I accelerate the class from 0 to 60mph in 5 seconds flat? In other words, how do I move from zero knowledge of programming (I start the class by assuming no one has any knowledge about programming, and go from there) to enough knowledge of programming to have the students start writing programs? Because everyone wants to sit down and start programming right away, of course. But in order to write interesting programs, you need to know quite a bit of syntax and some conceptual stuff as well---the interesting programs have loops (repeat this sequence), and conditionals (if X is true, do this series of statements, otherwise do this other series of statements), plus you really need to know something about variables and data storage and math and....the list goes on and on.
I try to take what a colleague calls a "spiral approach". This means that I introduce things somewhat superficially at first, and then as the students gain confidence and conceptual knowledge, I drill down a bit on these same concepts. So the students will see the same concepts repeated throughout the course--first, very briefly; later, in more depth. There are two benefits to this. First, I can introduce concepts a bit more quickly, because I'm not trying to cover everything about the concept right away. Second, there is built-in repetition, which helps the students remember and internalize the concepts.
As an example, I'll have the students do a hands-on exercise on one of the first days of class--they're in the lab, in front of the computer, learning how to use and interact with a program that someone else wrote that allows them to draw stuff on the screen. I give them a few simple directions for using the program, have them try a few scripted examples, and then let them play around. Some of them stick with the simple things--drawing squares of different colors--but some of them will try to figure out how to draw trees, or houses, or smiley faces. Over the next few classes, we start to delve into the program more deeply: how were we able to specify colors, or sizes of the shapes? (variables) how did we scale the shapes? (math) how can we reuse the same set of instructions over and over? (methods or functions, depending on your programming language) And so I use a simple activity both to get them programming right away (by modifying and adding to existing code) and as a springboard for introducing the main concepts of programming, and I refer back to this initial activity throughout the course.
After the third or fourth week of the class, the students have seen most of the main programming concepts, and most of them either have had their "a-ha" moment or will shortly. And this is when I can start getting more specific and introducing more sophisticated concepts. This is when they really start writing their *own* programs, although I'll often still give them some "starter" code for the trickier things.
So that's an overview of how I teach intro courses in my discipline. Of course there are other courses in this category too--courses specifically for non-majors, that are less focused on programming and more on an overview of CS--but the programming-focused courses are the ones I teach more often, and the ones from which we will draw our majors. And there's a lot I haven't touched on--making compelling assignments, for instance. But I hope this gives you at least some idea of what I do in the classroom.
Next up: What happens between intro and graduation? The mid-tier courses.
technorati tag: teaching-carnival
The baseline skill I expect out of my students is this: Can you take a nontrivial problem statement and turn this into a functioning computer program that solves the problem? Are you comfortable designing, implementing, and debugging such programs? This is sufficient for all populations: the students that will never take another course know how to write a basic computer program, and the ones that go on will have a base set of skills that they can further refine in the next classes.
Notice that "writing pretty code" or "writing efficient code" is not a baseline skill. Why? Well, the best I can do at this stage is to model, and discuss, "good" programming practices in class, but there's so much other material and so many concepts that the students *must* grasp before the end of the course that I can't focus on this as much as I'd like. The students for whom those two skills really matter are the ones who will go on to take more CS courses--and the next course in the sequence focuses heavily on good, efficient design of programs, so they will see it soon enough. I also find that some students will naturally pick these good design skills up on their own--if they see good models, they will try to mimic them to the extent that they are able.
But that's all at the end of the course. The trickier question is what happens in those first few weeks---how do I accelerate the class from 0 to 60mph in 5 seconds flat? In other words, how do I move from zero knowledge of programming (I start the class by assuming no one has any knowledge about programming, and go from there) to enough knowledge of programming to have the students start writing programs? Because everyone wants to sit down and start programming right away, of course. But in order to write interesting programs, you need to know quite a bit of syntax and some conceptual stuff as well---the interesting programs have loops (repeat this sequence), and conditionals (if X is true, do this series of statements, otherwise do this other series of statements), plus you really need to know something about variables and data storage and math and....the list goes on and on.
I try to take what a colleague calls a "spiral approach". This means that I introduce things somewhat superficially at first, and then as the students gain confidence and conceptual knowledge, I drill down a bit on these same concepts. So the students will see the same concepts repeated throughout the course--first, very briefly; later, in more depth. There are two benefits to this. First, I can introduce concepts a bit more quickly, because I'm not trying to cover everything about the concept right away. Second, there is built-in repetition, which helps the students remember and internalize the concepts.
As an example, I'll have the students do a hands-on exercise on one of the first days of class--they're in the lab, in front of the computer, learning how to use and interact with a program that someone else wrote that allows them to draw stuff on the screen. I give them a few simple directions for using the program, have them try a few scripted examples, and then let them play around. Some of them stick with the simple things--drawing squares of different colors--but some of them will try to figure out how to draw trees, or houses, or smiley faces. Over the next few classes, we start to delve into the program more deeply: how were we able to specify colors, or sizes of the shapes? (variables) how did we scale the shapes? (math) how can we reuse the same set of instructions over and over? (methods or functions, depending on your programming language) And so I use a simple activity both to get them programming right away (by modifying and adding to existing code) and as a springboard for introducing the main concepts of programming, and I refer back to this initial activity throughout the course.
After the third or fourth week of the class, the students have seen most of the main programming concepts, and most of them either have had their "a-ha" moment or will shortly. And this is when I can start getting more specific and introducing more sophisticated concepts. This is when they really start writing their *own* programs, although I'll often still give them some "starter" code for the trickier things.
So that's an overview of how I teach intro courses in my discipline. Of course there are other courses in this category too--courses specifically for non-majors, that are less focused on programming and more on an overview of CS--but the programming-focused courses are the ones I teach more often, and the ones from which we will draw our majors. And there's a lot I haven't touched on--making compelling assignments, for instance. But I hope this gives you at least some idea of what I do in the classroom.
Next up: What happens between intro and graduation? The mid-tier courses.
technorati tag: teaching-carnival
Tuesday, January 17, 2006
Blogging about teaching: the intro courses
The story of how I teach intro courses has to start with my own first experience with a programming class in college. In short, it was a complete disaster. Now, I was not a complete newbie--I had taken a few computer courses in junior high and in high school, although none on the "serious programming content" or AP level, so I at least knew a bit about how computer programs worked. And for the first few weeks, everything was fine. But about halfway through the class, we were introduced to a concept--and I don't even remember exactly what it was anymore--that I just could not understand. Unfortunately, programming courses build heavily on previous material, and so this pretty much sealed my doom. Also, the class picks up steam and more material is covered in the second half, so I quickly found myself drowning. On top of everything, the professor was one of those brilliant types that have no business teaching undergrads (i.e., couldn't teach you if you weren't already a programming genius), the TA spoke little English, and I was intimidated by the fact that all of my classmates either (a) seemed to get things much faster than I did, or (b) cheated their way through the class. By some miracle, I got a B in the class--to this day, I have no idea how I pulled it off. But the damage was done: I now *hated* programming, an activity that had only brought me joy in the past.
This experience, more than any other experience I had as an undergrad, colors the way I approach teaching. My number one goal in teaching intro courses is to make sure that my students' first experience with programming is overwhelmingly positive (or as positive as possible). I remember the despair I felt, and I keep that in mind as I introduce concepts, make up homeworks, and talk to my students in class and in office hours. I try to make sure that my interactions with students, and what I do in the classroom, encourages them rather than discourages them.
The first programming course is probably the toughest course to teach. In any given intro class, my student population consists of the following groups (and yes, there is overlap):
* Potential CS majors.
* Students from other majors that are strongly encouraged to take a programming course--typically, math and science majors.
* Students who are taking this just to try it out, because it's different or because a friend recommended it to them, or because they need a math/science class to graduate and this class doesn't have a lab.
* Students who have never programmed before.
* Students who've done a little programming, or hacked their calculators, or something.
* Students who really should be in the next class up, but want to take an "easy" class for credit.
In other words, the students are all over the map in terms of skills and motivation. They all have different expectations. Some of them will never take another CS class. For others, this is the class that will prepare them for the classes to follow. Still others may come in with no expectations but may leave intending to become majors, discovering a passion they didn't know they had for computers.
The biggest challenges I have at this level are (a) maintaining everyone's interest in the material, without losing or boring anyone along the way; (b) making sure that the lesser-prepared students aren't intimidated by the blowhards (many of whom really have sub-standard skills, but they know the lingo and they know how to sling it around); (c) introducing an overwhelming number of concepts in the first several weeks, and making sense out of them; (d) making sure that at the end of the class, everyone has some baseline skill in programming a computer.
One strategy that's really helped for (a) and (b) is "pair programming", which basically means that everyone programs with a partner and each person in the pair splits computer time 50-50. (So one person might be typing and the other feeding her lines or debugging; I've seen pairs go so far as to have one person operating the mouse and the other operating the keyboard!) At the beginning, I take a survey and pair less-experienced students with more-experienced students (and separate the serious blowhards from everyone else). I switch up the pairs throughout the class so that everyone gets to work with different people. This works wonders in several ways. One, the students see that the other students come in with a range of backgrounds and experiences. Two, they see that *everyone* can contribute, even if they "don't know anything" about programming (their words). And finally, I get the more experienced students--the blowhards--on my side: they are "helping" me with the class, "helping" bring their classmates up to speed. Surprisingly, this more often than not works wonders with potential problem students.
(c) is trickier, and so I often pull out the analogy on the first day of class that learning to program is like learning an entirely new language with a completely foreign alphabet and syntax. You have to learn the concepts, but also the syntax and the grammar of the programming language, and just like you can't learn Mandarin in a day, you're not going to completely understand programming in a day either. This doesn't completely remove the frustration from the students' experience in the class, but they do find it helpful when I remind them that this class is challenging by nature, and the fact that they're momentarily confused doesn't mean that they're stupid or not cut out to be CS majors. And I tell them up front that they may feel a bit out of sorts until a few weeks into the course, but that they *will* have that "a-ha!" moment at about that time, and then things will start to fall into place. (And with very few exceptions, this does happen.)
(d) gets more at the specifics of what I teach and how I approach things, topics which I will cover in part 2 of this blogging miniseries. (Particularly since the tone of this makes it seem like learning to program is all drudgery and frustration--it's not!)
Finally, I don't make a secret about my own foibles with programming. At some point during the class--sometimes on the first day, sometimes in the third week when the frustration is really setting in for some students--I talk about that first programming class, and how I almost didn't continue on, and about how I rediscovered my love for programming over time because I didn't give up. And often this is just what the students need to hear to encourage them to keep trying and keep learning.
technorati tag: teaching-carnival
This experience, more than any other experience I had as an undergrad, colors the way I approach teaching. My number one goal in teaching intro courses is to make sure that my students' first experience with programming is overwhelmingly positive (or as positive as possible). I remember the despair I felt, and I keep that in mind as I introduce concepts, make up homeworks, and talk to my students in class and in office hours. I try to make sure that my interactions with students, and what I do in the classroom, encourages them rather than discourages them.
The first programming course is probably the toughest course to teach. In any given intro class, my student population consists of the following groups (and yes, there is overlap):
* Potential CS majors.
* Students from other majors that are strongly encouraged to take a programming course--typically, math and science majors.
* Students who are taking this just to try it out, because it's different or because a friend recommended it to them, or because they need a math/science class to graduate and this class doesn't have a lab.
* Students who have never programmed before.
* Students who've done a little programming, or hacked their calculators, or something.
* Students who really should be in the next class up, but want to take an "easy" class for credit.
In other words, the students are all over the map in terms of skills and motivation. They all have different expectations. Some of them will never take another CS class. For others, this is the class that will prepare them for the classes to follow. Still others may come in with no expectations but may leave intending to become majors, discovering a passion they didn't know they had for computers.
The biggest challenges I have at this level are (a) maintaining everyone's interest in the material, without losing or boring anyone along the way; (b) making sure that the lesser-prepared students aren't intimidated by the blowhards (many of whom really have sub-standard skills, but they know the lingo and they know how to sling it around); (c) introducing an overwhelming number of concepts in the first several weeks, and making sense out of them; (d) making sure that at the end of the class, everyone has some baseline skill in programming a computer.
One strategy that's really helped for (a) and (b) is "pair programming", which basically means that everyone programs with a partner and each person in the pair splits computer time 50-50. (So one person might be typing and the other feeding her lines or debugging; I've seen pairs go so far as to have one person operating the mouse and the other operating the keyboard!) At the beginning, I take a survey and pair less-experienced students with more-experienced students (and separate the serious blowhards from everyone else). I switch up the pairs throughout the class so that everyone gets to work with different people. This works wonders in several ways. One, the students see that the other students come in with a range of backgrounds and experiences. Two, they see that *everyone* can contribute, even if they "don't know anything" about programming (their words). And finally, I get the more experienced students--the blowhards--on my side: they are "helping" me with the class, "helping" bring their classmates up to speed. Surprisingly, this more often than not works wonders with potential problem students.
(c) is trickier, and so I often pull out the analogy on the first day of class that learning to program is like learning an entirely new language with a completely foreign alphabet and syntax. You have to learn the concepts, but also the syntax and the grammar of the programming language, and just like you can't learn Mandarin in a day, you're not going to completely understand programming in a day either. This doesn't completely remove the frustration from the students' experience in the class, but they do find it helpful when I remind them that this class is challenging by nature, and the fact that they're momentarily confused doesn't mean that they're stupid or not cut out to be CS majors. And I tell them up front that they may feel a bit out of sorts until a few weeks into the course, but that they *will* have that "a-ha!" moment at about that time, and then things will start to fall into place. (And with very few exceptions, this does happen.)
(d) gets more at the specifics of what I teach and how I approach things, topics which I will cover in part 2 of this blogging miniseries. (Particularly since the tone of this makes it seem like learning to program is all drudgery and frustration--it's not!)
Finally, I don't make a secret about my own foibles with programming. At some point during the class--sometimes on the first day, sometimes in the third week when the frustration is really setting in for some students--I talk about that first programming class, and how I almost didn't continue on, and about how I rediscovered my love for programming over time because I didn't give up. And often this is just what the students need to hear to encourage them to keep trying and keep learning.
technorati tag: teaching-carnival
Blogging about teaching: the miniseries
I talk about teaching on this blog from time to time, but I don't think I've ever talked about how I teach in any great detail. Putting the review packet together meant that I had to think quite a bit about teaching, though, and on a deeper level than I normally do. And this inspired me to share some of my thoughts with the blog-world.
Over the course of the next week, I'm going to blog about my teaching. I'm going to concentrate on teaching undergrads because, well, that's where my interests seem to lie right now. I'll start with a post or two about intro courses, then move on to the "middle-tier" courses (lower-level electives and required courses) and end with a post or two on upper-level electives.
Why am I doing this? Well, for one, there seem to be quite a few readers of this blog that are from non-techie disciplines, and so this is my way of demystifying what it is I do in the classroom. But I'd also like to use this to start a dialog of sorts: what makes a CS education good, bad, or indifferent? For those of you who teach CS (or the sciences), what have your experiences been? How is teaching CS the same as, or different from, teaching in other disciplines?
So I hope you enjoy reading my disjointed thoughts about teaching, and I hope that you chime in in the comments too!
technorati tag: teaching-carnival
Over the course of the next week, I'm going to blog about my teaching. I'm going to concentrate on teaching undergrads because, well, that's where my interests seem to lie right now. I'll start with a post or two about intro courses, then move on to the "middle-tier" courses (lower-level electives and required courses) and end with a post or two on upper-level electives.
Why am I doing this? Well, for one, there seem to be quite a few readers of this blog that are from non-techie disciplines, and so this is my way of demystifying what it is I do in the classroom. But I'd also like to use this to start a dialog of sorts: what makes a CS education good, bad, or indifferent? For those of you who teach CS (or the sciences), what have your experiences been? How is teaching CS the same as, or different from, teaching in other disciplines?
So I hope you enjoy reading my disjointed thoughts about teaching, and I hope that you chime in in the comments too!
technorati tag: teaching-carnival
Thursday, January 12, 2006
The waiting is the hardest part
So the third-year review materials have been handed in....and now, the waiting game begins. It will be a while before I hear the verdict, but there will be various meetings in between now and then with various people involved in the process, which means I do get a teeny bit of feedback along the way. The first of these is coming up in about a month.
The neat, and unexpected, thing is that finishing the packet, and putting all the materials together, reignited my passion about this job. I realized that I've done some really interesting scholarship in the past few years---and that I'd forgotten about some of it! I can also clearly see the holes in my research life and what I have to do over the next few years to make meaningful contributions to my field, to innovate, and of course to position myself in the best way possible to earn tenure. I revisited some of my pedagogical practices, past and present, and rediscovered what makes me so fired up about teaching. In particular, going through my syllabi was like being on an archaelogical dig--I could see a clear progression of my ideas and an evolution of my teaching style into one that really works well for me. In short, putting this packet together reminded me that I'm not the colossal screw-up I sometimes think I am. :)
I had hoped to celebrate as soon as the packet was handed in, but of course this week has been pretty full with other commitments that were put on hold while the packet was being finished. But I feel like celebrating this moment in my career is important, so I plan to take some time this weekend to celebrate and acknowledge my accomplishments over the past few years---to give myself a pat on the back and say, "Well done!" I've definitely earned it!
The neat, and unexpected, thing is that finishing the packet, and putting all the materials together, reignited my passion about this job. I realized that I've done some really interesting scholarship in the past few years---and that I'd forgotten about some of it! I can also clearly see the holes in my research life and what I have to do over the next few years to make meaningful contributions to my field, to innovate, and of course to position myself in the best way possible to earn tenure. I revisited some of my pedagogical practices, past and present, and rediscovered what makes me so fired up about teaching. In particular, going through my syllabi was like being on an archaelogical dig--I could see a clear progression of my ideas and an evolution of my teaching style into one that really works well for me. In short, putting this packet together reminded me that I'm not the colossal screw-up I sometimes think I am. :)
I had hoped to celebrate as soon as the packet was handed in, but of course this week has been pretty full with other commitments that were put on hold while the packet was being finished. But I feel like celebrating this moment in my career is important, so I plan to take some time this weekend to celebrate and acknowledge my accomplishments over the past few years---to give myself a pat on the back and say, "Well done!" I've definitely earned it!
Tuesday, January 10, 2006
Happy (Inter)National De-Lurking Week!
Update: I forgot to attribute the image in the original post. Doh! The image is from Paper Napkin.
Yes, apparently it's that time of year again! So, if you're a lurker, if you've never commented, now's your chance! You don't have to say anything brilliant (it's not like there's a lot of brilliance going on in these postings anyway, ha ha!), just say hello. Or, if you're really stuck for something to say, here are some ideas (which I'm probably shamelessly stealing from others):
Name a good book/movie you've seen lately.
What's your favorite band/CD/song?
Where's the coolest place you've ever been on vacation?
Looking forward to meeting you!
Monday, January 09, 2006
5 lessons I learned in 2005
A bit of introspection for the year past, a bit late.
1. There is value in letting students see a bit of my life outside the classroom. It's hard to figure out where that line should be between me and my students, but this past year I let down my guard a little more, and it was fine. Students actually enjoy hearing about the paper deadlines I'm rushing to meet, the mishaps in the lab, what I'm listening to--things that make me more human in their eyes. I think they trust me more as a result.
2. Sometimes, the smallest of actions can have the most far-reaching consequences. This applies to both good deeds and unfortunate mistakes. And sometimes, once the damage is done, there's nothing to be done but wait it out.
3. My work is interesting and relevant. People in my field find value in my research and look forward to my results and insights.
4. I am the only one that has my best interests in mind. Until I get tenure, I will have to keep my guard up, measure my words, and sometimes keep my mouth shut, particularly in front of certain people. People often say one thing but do quite the opposite when push comes to shove. Luckily, this past year I also learned whom I can trust, and that I do have people in my life who will listen without judgement and help me navigate the sharky political waters of academia. I appreciate these people more than they will ever know.
5. Sometimes, the things I fear the most actually turn out just fine. Too much energy is spent worrying about things that never come to be or that are out of my control. (I hope that this is true about my review this year!)
1. There is value in letting students see a bit of my life outside the classroom. It's hard to figure out where that line should be between me and my students, but this past year I let down my guard a little more, and it was fine. Students actually enjoy hearing about the paper deadlines I'm rushing to meet, the mishaps in the lab, what I'm listening to--things that make me more human in their eyes. I think they trust me more as a result.
2. Sometimes, the smallest of actions can have the most far-reaching consequences. This applies to both good deeds and unfortunate mistakes. And sometimes, once the damage is done, there's nothing to be done but wait it out.
3. My work is interesting and relevant. People in my field find value in my research and look forward to my results and insights.
4. I am the only one that has my best interests in mind. Until I get tenure, I will have to keep my guard up, measure my words, and sometimes keep my mouth shut, particularly in front of certain people. People often say one thing but do quite the opposite when push comes to shove. Luckily, this past year I also learned whom I can trust, and that I do have people in my life who will listen without judgement and help me navigate the sharky political waters of academia. I appreciate these people more than they will ever know.
5. Sometimes, the things I fear the most actually turn out just fine. Too much energy is spent worrying about things that never come to be or that are out of my control. (I hope that this is true about my review this year!)
Sunday, January 08, 2006
Work soundtrack
I listen to a lot of music, especially when I'm working. Maybe it's the byproduct of growing up in a noisy household, but I find it easier to focus (and stay focused) if there's music on in the background. Since I've been working a lot lately (getting ready for classes, catching up from being sick, the *@#%! review packet), I've been thinking about how the music I listen to takes on the characteristics of the task at hand. And so, as another installment of Get To Know Jane, here's a sampling of what I listen to while I work.
Prospectus-writing: Does it come as any surprise that the predominant mood of my prospectus-writing music is "angsty"? Angsty music seems to invite introspection--and surprisingly, I'm finding that I need "music with words" as I write and revise the story of my academic life. Top pick: The Garden State soundtrack. Runner-up: Tori Amos.
Research: When I need to concentrate, or when I'm working on something that's really challenging, I need something funky yet mellow. Something that won't induce sleep but not something that's going to make me want to start dancing around the office, either. My favorite choices here have an ambient/techno flavor to them. Top pick: Groove Salad (Internet radio station). Runner-up: Enigma.
Programming: For me, programming is an energetic task, and so my music has to match. Having music with words is essential--it sounds strange, but I need the distraction of words so that my brain can continue to make the associations I need to do the logic of stringing together a program. Top pick: Supreme Beings of Leisure. Runner-up: REM.
Class prep: This is the one area that I don't really have one music preference. Typically, though, I'll tend to something more upbeat, but more often than not I'll just put on a mix of things. Top pick: Party shuffle on iTunes. Runner-up: Radio Paradise (Internet radio station).
Scholarly reading/writing: Getting through those dense journal and conference articles, and writing my own dense journal and conference articles, requires more soothing music sans words. Classical-ish music fits the bill perfectly. Top pick: George Winston. Runner-up: Classical piano.
Prospectus-writing: Does it come as any surprise that the predominant mood of my prospectus-writing music is "angsty"? Angsty music seems to invite introspection--and surprisingly, I'm finding that I need "music with words" as I write and revise the story of my academic life. Top pick: The Garden State soundtrack. Runner-up: Tori Amos.
Research: When I need to concentrate, or when I'm working on something that's really challenging, I need something funky yet mellow. Something that won't induce sleep but not something that's going to make me want to start dancing around the office, either. My favorite choices here have an ambient/techno flavor to them. Top pick: Groove Salad (Internet radio station). Runner-up: Enigma.
Programming: For me, programming is an energetic task, and so my music has to match. Having music with words is essential--it sounds strange, but I need the distraction of words so that my brain can continue to make the associations I need to do the logic of stringing together a program. Top pick: Supreme Beings of Leisure. Runner-up: REM.
Class prep: This is the one area that I don't really have one music preference. Typically, though, I'll tend to something more upbeat, but more often than not I'll just put on a mix of things. Top pick: Party shuffle on iTunes. Runner-up: Radio Paradise (Internet radio station).
Scholarly reading/writing: Getting through those dense journal and conference articles, and writing my own dense journal and conference articles, requires more soothing music sans words. Classical-ish music fits the bill perfectly. Top pick: George Winston. Runner-up: Classical piano.
Friday, January 06, 2006
Ego-booster
One of the perks of not being the new kid on the block anymore (no offense, New Kid! ha ha, ok, poor attempt at a joke---hey, it's Friday afternoon, so cut me some slack) is that former students come back to visit me. This afternoon a few of our '05 grads stopped by to say hello. Now I know these students pretty well, since I supervised a project of theirs over multiple terms, but it was still flattering that they made a point of stopping by while passing through town. But the coolest thing is that they (unprompted by me, I should note) told me how much the stuff they had learned in my upper-level course (the one that's related to my research area) was popping up in their current projects at work, and how much they now appreciated what they had learned in that class! Yippie!
It was especially nice to hear that now, during a week where I've spent much time beating myself up over this stupid review. It's so easy to focus on the negative in this job, to stress over article rejections and course evaluations and all the work that's not getting done that should get done...and to forget that sometimes, when we least expect it, we really are making a difference in our students' lives.
What a great way to go into the weekend!
It was especially nice to hear that now, during a week where I've spent much time beating myself up over this stupid review. It's so easy to focus on the negative in this job, to stress over article rejections and course evaluations and all the work that's not getting done that should get done...and to forget that sometimes, when we least expect it, we really are making a difference in our students' lives.
What a great way to go into the weekend!
Thursday, January 05, 2006
Feeling almost human again
Update: Gah, stupid migraine! So close to finishing the prospectus draft, and whammo. Guess it's time for bed, and guess Mentor will be getting the prospectus sometime tomorrow instead of tonight. Wah.
Thanks, everyone, for all your kind comments and feel-better vibes over the past few days. Today was the first day I felt somewhat human again--just a little cough and a few sniffles left over right now, although I was feeling well enough to go into school yesterday for a while as well.
I am wondering how much all of the stress I've been carrying around these past few months contributed to me getting sick. I rarely get sick, as I've mentioned before, but thinking back it seems like most of the times I've been sick can be traced back to stressful times in my life--particularly, when the stress is job-related. For instance, when I was finishing up my dissertation, I had a mysterious cough that lingered for over a month. I even went to the health center on campus (the place of last resort--it was that bad), and the doctors claimed they couldn't find anything wrong with me. Mysteriously, the cough disappeared soon after I handed the diss to my committee. And there are other, similar examples as well.
This is a busy week for me, too, work-wise. My third-year review packet is due next week. My prospectus is not done, and I told Mentor I'd send her a copy a month ago--so that's been a big source of stress and anxiety. There are other deadlines I have to meet between now and the end of next week. And so I panicked a bit when I wasn't better at the start of the week, which I'm sure didn't help things at all. But things are looking up: I can concentrate on tasks for long periods of time again; I spent the morning whipping the prospectus into shape (another hour of work tonight and it'll be ready to send to Mentor!); and tomorrow, with the prospectus out of the way while awaiting feedback, should be free for getting a bunch of other stuff done.
In a way, too, I'm waiting for this whole review process to be over so that I can feel human again. As much as I thought I was ready to undergo this process going into this year, so far it's been like a big sledgehammer hanging over my head. Perhaps this is because there is the real possibility that at the end of this process, my school will say that I'm not cut out for this job. And that all of the hard work I've put in, all of the time I've spent thinking about learning objectives and planning assignments and preparing classes and reevaluating my pedagogy and trying to get this research program off the ground and recruiting students...all of this energy I've put into this position will be for naught. In a sense, I feel like my life will be in this weird suspended state until the decision comes down later this year--and that only after the decision is made will I be able to move on, either here or elsewhere.
Thanks, everyone, for all your kind comments and feel-better vibes over the past few days. Today was the first day I felt somewhat human again--just a little cough and a few sniffles left over right now, although I was feeling well enough to go into school yesterday for a while as well.
I am wondering how much all of the stress I've been carrying around these past few months contributed to me getting sick. I rarely get sick, as I've mentioned before, but thinking back it seems like most of the times I've been sick can be traced back to stressful times in my life--particularly, when the stress is job-related. For instance, when I was finishing up my dissertation, I had a mysterious cough that lingered for over a month. I even went to the health center on campus (the place of last resort--it was that bad), and the doctors claimed they couldn't find anything wrong with me. Mysteriously, the cough disappeared soon after I handed the diss to my committee. And there are other, similar examples as well.
This is a busy week for me, too, work-wise. My third-year review packet is due next week. My prospectus is not done, and I told Mentor I'd send her a copy a month ago--so that's been a big source of stress and anxiety. There are other deadlines I have to meet between now and the end of next week. And so I panicked a bit when I wasn't better at the start of the week, which I'm sure didn't help things at all. But things are looking up: I can concentrate on tasks for long periods of time again; I spent the morning whipping the prospectus into shape (another hour of work tonight and it'll be ready to send to Mentor!); and tomorrow, with the prospectus out of the way while awaiting feedback, should be free for getting a bunch of other stuff done.
In a way, too, I'm waiting for this whole review process to be over so that I can feel human again. As much as I thought I was ready to undergo this process going into this year, so far it's been like a big sledgehammer hanging over my head. Perhaps this is because there is the real possibility that at the end of this process, my school will say that I'm not cut out for this job. And that all of the hard work I've put in, all of the time I've spent thinking about learning objectives and planning assignments and preparing classes and reevaluating my pedagogy and trying to get this research program off the ground and recruiting students...all of this energy I've put into this position will be for naught. In a sense, I feel like my life will be in this weird suspended state until the decision comes down later this year--and that only after the decision is made will I be able to move on, either here or elsewhere.
Monday, January 02, 2006
A sign that the honeymoon is over...way over
Me, this morning, after dragging myself out of bed: God, I feel like crap. I hate being sick. And I look like complete crap too.
Mr. Jane, glancing up: Yeah, you do look like crap.
(gee, thanks, honey.)
Mr. Jane, glancing up: Yeah, you do look like crap.
(gee, thanks, honey.)
Still too sick to be introspective
So I'm still trying (unsuccessfully) to fight off this stupid bad cold/mild flu that I came down with the other day. I've pretty much spent the past few days on the couch, although I was able to muster up enough energy to go out on New Year's Eve (and New Year's Day, although that was a stupid decision--I came home feeling 100 times worse, and with a fever to boot). I finally got enough energy to sit up at my desk for a while tonight, so I'm catching up on blogs and hoping to do a bit of work before I drag myself to bed.
Since I don't have the energy to do a full retrospective of 2005 right now, I leave you with my resolutions for 2006:
1. To do something outside of my comfort zone.
2. To submit a journal article on my current project.
3. To finish 1 crafting project that I should have finished last year, plus one other project I've been meaning to do for a while.
4. To continue to take time for myself: physically, mentally, and emotionally.
Happy new year, everyone!
Since I don't have the energy to do a full retrospective of 2005 right now, I leave you with my resolutions for 2006:
1. To do something outside of my comfort zone.
2. To submit a journal article on my current project.
3. To finish 1 crafting project that I should have finished last year, plus one other project I've been meaning to do for a while.
4. To continue to take time for myself: physically, mentally, and emotionally.
Happy new year, everyone!
Subscribe to:
Posts (Atom)
