Thinking about space, part eleventy-thousand

I’ve posted here in the past about my obsession concern with spaces and what they signal: who’s welcome here, what kind of work is done here, etc. I’ve been thinking about space again recently—specifically, research space and recruitment to the field and how the two intersect.

A bit of background: Last year Carleton started a new computer science summer program for high school students. The program lasts 3 weeks, and consists of classes in the mornings and guided research in the afternoons. I teach an HCI (human-computer interaction) module in this program, and my guided research group works on HCI projects related to my actual research.

Last year, when I taught in the program, I had pretty much the perfect lab space for my guided research group. It was one of our CS labs. Only half the room has computers, and these are pretty nicely spaced out. The room also features windows/natural light, lots of whiteboard space, and a sitting/collaboration/conversation area. The space allowed people to move around freely, sketch out ideas, and step away from the computer from time to time.

lab space sketch

Figure 1: A sketch of last year’s lab space.

 

 

 

 

 

 

 

 

 

Due to room availability and other issues, I won’t have this lab space again this year. Instead, my research group will be housed in our new teaching lab. While this space is great as a teaching space, it’s not so great as a collaborative space. Here’s what the layout looks like, roughly:

lab space sketch

Figure 2: The lab space I’ll be in this year. Much different from last year’s space!

 

 

 

 

 

 

 

 

The computers are in rigid rows on immovable tables. There’s a fair amount of whiteboard space, but it’s all in the front of the room. It’s harder to move around, and there’s no space to step away from the computers.

The worst part for me? No windows! (The horror!)

My challenge is to find a way to turn this space into a more collaborative, welcoming space. Not only do I want to make it more workable for the type of research work my students will be doing, but I also want to make it less clinical/sterile and more warm—because this will be the primary working space for high school students whom we’d like to become computer scientists someday, and there’s not much about this space that says that computer science is fun or welcoming or collaborative.

So how do I plan to pull this off?

  • Removing some of the computers and half of the chairs from the room. This will free up some table space for sketching, conversations, and planning away from the computer, and improve the walking flow around the room.
  • Large sticky note pads and markers, to make up for the lack of whiteboards around the room. I’d love for the walls of the room to be covered with sketches, lists, mockups, user stories, etc. by the end of the program!
  • Designating the front of the room as our large group meeting space. Sometimes we’ll need to discuss things without the distraction of the computers, and it turns out there’s enough room in the front to pull up chairs and chat as a group. (It will be a little tight, but it will work.)
  • Pictures on the walls, to make up for the lack of windows. I’m thinking nature pictures, so that maybe we’ll forget about the lack of windows!

I haven’t been able to do any of this yet since there’s some construction going on in the room, but I’ll be curious to see how things work out next week when I’m able to get in there and start rearranging things, and see if I can make my vision a reality. It will also be interesting to see if these few cosmetic changes will really change the feel and environment of the room, or if the signals in the room will be too strong to overcome. Regardless, it’s an interesting experience and challenge, and I can’t wait to see how it turns out in the end.

The art and science of choosing textbooks

Even after 11+ years of teaching, I find that selecting textbooks for a class is much more of an art than a science. Sure, I can apply “scientific” principles to selecting a textbook—evaluating how certain key topics are covered, weighing the ratio of code to theory, vetting the explanations and examples—but in the end, I never quite know how my choice will go over. In the best case scenario, I identify a book that both my students and I like and find effective. But honestly, if I can at least identify a book that we can both tolerate, I count that as a win. Sometimes, even with my careful selection process, I get things wrong. And sometimes, a book that’s worked wonderfully in the past falls flat with the next group of students.

I found myself in that last situation last spring, when I taught Software Design. In the past, I’ve used a particular textbook for the design patterns portion of the course. I like this particular book a great deal: it’s irreverent and clever, but most importantly, it presents each design pattern through the lens of an extended example, coded up in Java. In the process of developing the example, the students see a lot of code, and are also introduced to the pitfalls and common variations of each pattern. The students also see examples of each pattern in practice, giving them context for the usage of each pattern.

Last year, for the first time, my Software Design students complained about this textbook choice. Loudly. They hated this book. It’s too long, they said. It’s too condescending, they said. It lacks gravitas, they said. (OK, they didn’t say exactly that last one, but that was the gist of the criticism.) Basically, they wanted a textbook that was more textbook-y and less over the top.

I’ve refrained from assigning the Gang of Four design patterns book in the past. Not because I don’t like it—on the contrary, it’s a fabulous reference book, and I do use it often in my own work. I don’t assign it because the usage examples are rather sparse and there isn’t a lot of code in the text. I just wasn’t convinced that it would work in my class. But, since the criticism was so strong last time around, I decided to give it a go this time around and see if I had better success.

The verdict? This text hasn’t worked well at all for this group of students. As I suspected, the students are having a lot of trouble figuring out when or why to use each pattern. The lack of examples and lack of code is negatively affecting their comprehension. (And the few examples in the Gang of Four? My students don’t find them convincing.) I’m having to do a lot more PR work in class to get them on board with the concept of design patterns. I’ve spent almost all my class time in this part of the course lecturing (lots and lots of lecturing, which I typically try to avoid) and walking through examples, when normally I’d set up an example, walk through part of it, and leave the rest to my students to develop, so that they get some much-needed practice with the patterns.

Next time I teach this course (which, sadly, won’t be for at least 2 years), I will go back to the Head First book. I do think some of the criticisms from last year’s students are valid, but if anything this term’s experience has underscored just how important good, extensive code examples are in learning a difficult concept or set of concepts. This experience has also helped solidify in my mind why I choose to use this book, and I’ll be able to make a stronger case for it with the next batch of students.

Now, if I could just find a Data Structures textbook that I don’t absolutely abhor….

 

Teaching a new language in a course, when the language is not the focus of the course

Like many computer science departments, the languages we teach our students vary over time. When I was hired, we taught Java in Intro and C++ in Data Structures (our CS 2 course). The year I started, we moved to teaching Java in both Intro and Data Structures. (Thank god, because my C++ was pretty rusty at that point.) When I returned from maternity leave in 2008, we switched to Python in both Intro and Data Structures. This was absolutely the right move for Intro, as it’s much easier to get up and get going in Python than it is in Java, but proved a bit problematic for Data Structures—not right away, but down the road, as we found that our majors were less willing to learn new languages since Python was so easy and familiar to them, which in some cases really hurt their Comps (capstone) projects. (Image and sound processing in Python? Bad idea!)

A few years ago, we decided to keep Python in Intro, but switch Data Structures to Java. The switch had the intended effect—our majors are more comfortable learning new languages on the fly, because by the time they’ve finished their first 2 CS courses they’ve programmed in 2 languages. But of course we originally switched from Java for a reason—its steeper learning curve. (public static void main(String[] args), anyone?) And so we still run into the issue: how do you successfully introduce Java, or any new language, in an early CS course, when the language itself is secondary to the course?

I’ve taught the course twice now under this “new” format, and I think this time around things with the language transition went much, much better. There’s still a lot I can improve, for sure (more coding in front of the class instead of just giving them some code and setting them loose, more small examples at the beginning), but there were a few things that definitely went better this time around:

  • I spent a full 2 weeks just on Java. Even though this meant I had to cut down on some things I would normally cover (like my beloved Dijkstra’s algorithm, and some of the finer points of hash tables), I felt it was important to give the students enough time to become comfortable, or at least familiar, with the new language before asking them to dive into the course concepts AND implement them in the new language.
  • I started the language transition by providing examples in both Python and Java. I wanted my students to come away from the experience realizing that Python and Java really aren’t so different, and while Java definitely has more overhead, it also has a lot in common with Python. Showing the same code in both languages, and giving them both versions of the code to play with and modify, helped them be comfortable with thinking in the new language. In fact, in many of the early exercises, I encouraged students to write the code in Python first if they were confused, and then translate it into Java. (I also relied on readings that introduced Java syntax and principles in relation to Python: Brad Miller’s Java for Python Programmers, and Ken Lambert’s From Python to Java. The latter is great because it has the same concept presented with side-by-side code examples.)
  • I approached inheritance differently. Inheritance is a topic we all agree that students should be familiar with by the time they finish Data Structures. I used to stress inheritance quite a bit early on, having students write subclasses and interfaces and so on in an early project. This time around, we did some straightforward inheritance examples late in Week 2, with subclasses and superclasses, and discussed a bit about abstract classes, but I limited this largely to in-class exercises. Related to this…
  • I incorporated interfaces throughout the course, as “code templates”. Students find the idea of interfaces confusing, and rightly so. I decided this time around that I was ok if they didn’t fully understand what an interface was or the instances in which we might use one, as long as they could use and incorporate interfaces somewhat competently in their code. So for every ADT we studied, I gave them an interface for that ADT. I “sold” it as a template for what their methods should look like and how they should behave. I used it to illustrate that we can implement ADTs quite differently and they can still function the same way (and that the end user doesn’t have to and shouldn’t know anything about the inner workings of the resulting data structure). I don’t know how much students really understood about interfaces by the end of the term, but at least they were able to competently integrate them into their code. (Bonus: they made grading the projects much, much easier—everyone’s methods had the same signatures!)

There are still challenges when teaching the course in Java: how and when to introduce generics (I tend to minimize these: students can use them, but I don’t require them to implement classes with generics), finding a textbook that I can live with (still searching), etc. And surely as I continue to reflect on Winter Term as I gear up for Spring Term, I’ll remember more of what worked and what didn’t. But overall I’m pretty pleased with the language-related stuff in the course this time around, and will probably use largely the same model the next time I teach the course. (Assuming, of course, we don’t decide on another language switch between now and then….)

The secret life of professors: Winter break edition

Here at Carleton, we’ve been finished with Fall Term since right before Thanksgiving. While most of the rest of the academic world frantically writes, administers, and grades finals, we at least have a respite from the daily demands of teaching. The tradeoff, of course, is that right after Christmas we frantically scramble to get ready for the start of Winter Term, which starts right after New Years, while most of the rest of the academic world gets their respite.

Of course winter break is really only a small break, a break from the daily demands of teaching. Yet the myth persists, even among some who know me well (*cough cough* MIL *cough cough*), that I get to spend my 5-week break lounging on the couch watching Hoda and Kathie Lee, baking cookies, leisurely getting my Christmas shopping done, etc. Nothing could be further from the truth, of course, and in fact I will struggle this year like most years to get all of the holiday stuff done in time for the holidays.

So what is it that I’m spending my 5 weeks doing?

  • Wrapping up Fall Term. The first week+ of break is always spent finishing up the previous term. Lots and lots of grading, for sure, but I also like to take notes on what worked well in each class and what I want to change next time around.
  • Prepping for Winter Term. I’m teaching one class next term (thank goodness), and I’ve taught it before, but that doesn’t mean I can just waltz into class the first day and start teaching. I need to prep my syllabus, plan out all the projects, figure out exam dates, get the first few weeks of readings and reading exercises posted (this is particularly important when you flip your classroom, as I do), determine my office hours, and in general plan out the flow of the class for the term. Plus, since I’m teaching outside the building, I at some point need to take a field trip over to my classroom/lab and make sure all the right software is installed and ready to go.
  • Grant writing/research. This is the biggie. I still need to finish up some simulations that I didn’t get to last month, and then analyze the results. I need to look more closely at the data my students generated last summer and figure out if I can use it, or if I have to run more experiments. I need to revamp and revise the grant narrative, revise some supplementary documents, and add some new sections and language given some new language in the call for proposals. And did I mention I found a bunch of recent research that I have to skim through?
  • Other research activities. As odd as this sounds, I need to start planning for the summer now. I need to figure out how many students I want to hire, determine what I want them to do, write up a job description, recruit, and find them funding. I also need to start thinking about what I want the high schoolers to do and start figuring out how to recruit an undergraduate RA for that program. Plus I have some data lying around (and a rejected journal article) that I need to write up/revise and send out (again) for peer review.
  • Workshops. This week is the week of workshops. Earlier this week I went to one on a graduation requirement that many of our CS courses fulfill. Today and tomorrow I will be attending one on academic civic engagement in STEM. The former was tremendously helpful in helping me understand the requirement further and how the requirement is playing out on the ground, which will help me be a more effective chair as we set curricular designations for our courses. The latter is something I’m interested in for some of the courses I teach (as well as for Comps, our senior design projects). As useful as these are, though, they are time-consuming: all morning Monday and Tuesday, all afternoon today and all day tomorrow.
  • Hiring/chair stuff. One thing I’ve learned in my brief tenure as chair is that there’s always something unsavory or time-consuming that comes up that you have to deal with. Break time is no exception. Plus our application deadline for our TT position is looming, which means I need to both start dealing with the search stuff (figuring out who reads which applications, answering questions, scheduling search committee meetings, etc) and start reading and ranking applications.
  • And I almost forgot, ’tis the season for recommendation letters. Fortunately I’m only writing for a few students this year, but it’s still time-consuming—the drafting of the letter, but also the letter submissions, as each school has their own (different) process for doing things (their own rating scales, their own upload procedures, etc).

Reading this list makes me want to retreat to the couch with a plate of cookies!

There will be small breaks, of course—quick trips to visit family, days of fun with the kiddos when daycare is closed—and for those, the extra flexibility in my schedule really helps. But this, as with all my “breaks”, is definitely a working break, and demonstrates just how many hats I as a faculty member need to wear on a daily basis.

Back to work, then!

Random vignettes (bullets are sooo 2012)

autumn leaves

I.

Knowing that this year would be crazy busy for me, I chose my service wisely. I tried to select things that were staggered throughout the year, so that I could give my time and attention to them without stressing out too much. I tried to avoid January and February since that’s when hiring season will kick into high gear around here. I said no to some opportunities because I knew I wouldn’t have the bandwidth for them.

Even with all this careful planning, several of my service activities are now ramping up all at the same time, and all of them seem to require attention at precisely the same times.

So much for careful planning, huh.

*    *     *     *     *

II.

This term, I’m experimenting with all-electronic grading. I’ve always felt a bit squicky about all the paper involved in take-home exams and essays. But I’ve felt more comfortable grading on paper, so even when students turn in take-home exams or essays on Moodle, I tend to print them out to grade them. Moodle introduced a blind grading feature recently, and with this feature I decided to try and go all-electronic.

My system goes like this: Students turn in exams or essays in either Word or PDF format. If they turn in a Word file, I use track changes to make comments and/or indicate how many points they received on a question. If they turn in a PDF file, I use the annotation features in Preview to make comments, mark up the text, highlight passages, etc. Usually I also have an associated rubric on Moodle, but since I comment on their papers/exams directly I just refer them to the document for comments rather than repeating them in the rubric.

I was worried about the clunkiness of this, particularly with annotating PDFs. But I’ve been annotating PDFs I read for research for quite some time now (also to save paper), so I’ve gotten used to how to annotate in Preview and I have a pretty good workflow. And I’m actually enjoying it quite a bit. I can copy and paste comments between papers/exams (good when many students miss the same question or make the same mistake for the same reasons). I had all of my Networks exams open on my computer earlier, and I found it easy to switch back and forth between them, allowing me to grade like I normally do (one part of a question at a time for each student in the class). I find I make longer and more constructive comments and it takes me less time.

Interestingly, my Networks class appears to favor PDFs while my freshman seminar definitely favors Word docs. I’m not sure why this is.

*    *     *     *     *

III.

Tomorrow I embark on a new-to-me adventure. I’m serving as an external reviewer for a CS department review at another liberal arts institution.

I’m pretty excited about the opportunity. We went through our own department review a few years back (right after we brought our son home), but since I was on leave I had a pretty fractured view of the process. I am looking forward to meeting new people, talking about trends in the field, and seeing how another institution does things.

That said, the schedule for this thing looks pretty daunting! I am an extrovert and usually thrive on interacting with people, but I’m thinking I will need to sit and stare at a wall for a few hours after I get back to my hotel, especially at the end of the first full day. I know that the schedule has to be this way due to the short time frame, but ay caramba, this will test my extrovertedness for sure.

Fostering department culture

One of the top things on my mind since taking over as department chair is culture: specifically, department culture. As chair, I set the tone for the department in various ways. I set the tone when I set the agenda for a department meeting or retreat: the topics I select, and the time I choose to devote to each, signals how much of a priority I think they are to the department. I set the tone when I interact with faculty and students, both new and returning. I set the tone when I represent the department at meetings and such, and when I advocate for the department to administrators and other campus offices and constituencies.

I’ve been thinking about this so much lately because the dynamics of our department are changing rapidly. We have a record number of majors (91 juniors and seniors at an institution of 2000 students) and a large number of non-majors who take or want to take our courses. We have two new full-time visiting faculty members and two part-time visiting faculty members to help us meet our course demand, which means we have almost equal numbers of visiting faculty (4) and tenure-track faculty (5). We’re conducting a tenure-track search this year to grow our department. We’re a little more balanced than we have been in terms of rank, with 2 full, 2 associate, and one tenure-track assistant prof, but the visitors definitely skew us younger. And perhaps the most challenging: we’re spread across 3 buildings, one of which is a 7-8 minute walk from the others.*

So what do I see as the main challenges to setting the tone of the department internally?

  • Keeping everyone in the loop. Up until now, we’ve very much had a “hallway conversation” approach to decision-making. That is, a nontrivial number of department decisions, discussions, etc. happened as a result of spontaneous hallway conversations. This model can work okay when everyone’s physically on the same floor in the same building, but assumes that all stakeholders are present. Even last year when most of us were on the same floor, this model didn’t work well because inadvertently someone (usually staff) was left out and wondering what happened. With faculty physically in different places, this model ceases to work at all. I suspect changing this aspect of culture will be one of the most challenging, just because we’ve operated under it for so long that it’s second nature. But as someone traditionally on the outside of the field, I recognize the harm and bad feelings that result from being left out of important conversations, so I’ll be looking at creative ways to make sure everyone stays informed and involved, no matter where their offices are or what their rank is.
  • Mentoring. We have so many young, early career faculty in the department! Most of our visitors likely have a tenure-track position at a similar institution as their long-term goal. Our tenure-track prof will be going up for tenure in a few years. I want to see all of them succeed. I want to make sure all of them have the tools to succeed. I want to make sure our tenure-track prof is doing all the right things to put her in a good position to earn tenure here, and I want to make sure as a department we’re giving her strong, consistent messages and useful, constructive feedback. I want the visitors to make the most of their time here, to learn as much as they can about teaching at an undergraduate institution, and to grow as teachers and scholars so that they put themselves in a great position to get hired on the tenure-track, here or elsewhere.
  • The student experience. It’s unclear exactly why we have such a large uptick in majors and in enrollments generally. I tend to chalk it up to the fact that we, individually and as a department, are just awesome. Seriously, though, I think we as a department offer students interesting, challenging classroom and research experiences; we do a good job of making our courses relevant to students; we are also approachable and fun and genuinely interested in our students. We don’t provide high barriers to entry, and I think that’s key as well, maybe even more important than the rest: we teach the intro students where they are. Can we continue to do this with such high student-to-prof ratios? Will we see a drop in non-major enrollments given that none of us are advising non-majors anymore, since our major advising loads put us at the advising limit? How can we continue to connect with our students as individuals given our high class enrollments? Finally, how can we make sure we have adequate physical spaces, for classes and collaborations and just general hanging-out, to support the large numbers of students, particularly in a building not designed for such numbers?
  • Balancing the proactive with the reactive. When a department grows and changes as rapidly as ours did, it’s easy to fall into “fire-fighting” mode, running from one crisis to the next. It’s really important to take and make time to step back and consider the larger picture, for the long-term health of the department and the major, but so hard to do when so many little things vie for your attention. But it’s also important to recognize the patterns in the little things that point out larger trends and lead to the larger discussions.

I don’t claim to know all the answers here, and most likely I’ll stumble and fumble as I try to make sense of the challenges, but I do look forward to the challenges and the opportunities as chair to address these. Hopefully I’ll get a handle on this sometime in the next 3 years, before my term is up!

* Those of you on large campuses are no doubt chuckling at this, but our campus is very compact, so a 7-8 minute walk is significant.

Summer program midterm evaluation

We’re halfway through our inaugural summer program for high school students. I am happy to report that I am surviving so far (some days, barely) and mostly having a great time.

I talked a bit about the program in a previous post, but to recap: 31 students, divided into 3 groups. Mornings are class time: each week they take one class for 3 hours each day in a different specialty (this year: human-computer interaction (HCI), robotics, and evolutionary computation), rotating among the specialties each week. In the afternoons, they do research with faculty. So I teach HCI for 3 hours every morning, and in the afternoon I have 11 students doing research with me in HCI. So far the program seems to be working rather well.

It was hard for me at first to figure out how to structure my course and research for the high schoolers. I have zero experience with high school students, so I went into this with more questions than answers. How much did they already know? How quickly could they learn? How would they compare intellectually to Carleton students? What could I realistically expect them to do research-wise in 3 weeks?

I decided to assume that these students would be on par with Carleton students (after all, these are students that we hope will come to Carleton), and structured my curriculum appropriately. I set up my class meetings similar to how I would set up a Carleton class (well, similar to 3 class meetings rolled into one day), with similar content and similar activities. I figured it would be easier to adjust down than adjust up if necessary. One major change: more lecturing, since I couldn’t count on them reading the appropriate material before class. I’m not totally comfortable with that aspect, but consider it a necessary evil.

The research was trickier. I wanted them to do actual research, as in research I’m actually working on right now. But I don’t have time to instruct them in all of the necessary background knowledge, and again, it was unclear to me how their backgrounds would translate into ability to contribute meaningfully to a research project. Also, as I’ve mentioned, my current project is brand-new and I don’t fully understand all aspects of it yet! I settled on having them create visualizations (via web pages) for some of the data we’re currently collecting, and presenting this data in a way that our target demographics would understand and that would teach them about how the system works. I figured they would be able to get at least something up and running by the end of the 3 weeks.

So, how is it going so far?

My instincts were correct for the classroom portion: intellectually, the students are on par with Carleton students. They are bright, engaged, and (mostly) delightfully wacky. They are doing the same level work in class, by and large, that my college students do. The one key difference: it is harder to keep them on task. So, for instance, my college students can typically stay on task for 25-30 minutes, whereas for the high schoolers it’s more like 10-15 minutes. This probably has something to do with different developmental stages. At any rate, as long as I factor this in to my daily class plan, I’m good.

Content-wise: well, it’s always hard to boil down an entire field into 15 hours of class instruction, but I think I did a good job for the most part selecting content. I’d definitely jettison some activities next time and refine others, and choose what to lecture about differently. The beauty of this program, though, is that I repeat the same class 3 times, so I have the opportunity this week to fix the things I didn’t like about how class went last week, and things are already going more smoothly.

The research portion is also going well. I made one major tactical mistake: I decided to give a brief overview of the computer networks portion of the research so that they could concentrate on the HCI aspect. By Thursday of last week, though, it was clear that my high school researchers were struggling in developing visualizations because they didn’t really understand what they were visualizing and why. So I spent all of our research time on Friday afternoon doing Networks 101 and giving a more detailed overview of the project. I told them they could ask any question, no matter how stupid they thought it was—and of course, there were no stupid questions and a ton of excellent questions. We covered a ton of ground, and by the end of the day they felt much more confident about what they were doing and why.

The other issue I’m facing is that I may have underestimated what they are capable of doing. Many are getting a little bored of the prototyping tool and so we decided they should learn HTML and actually code up the sites they’ve been prototyping. That’s been a big hit so far. Some of the groups may also end up doing some more with the raw data than I originally intended, which is also great. I had my undergraduate research students come in this afternoon and “consult” with each group, which I think both my high school students and my undergraduates enjoyed.

The whole experience has been fun and enriching and ultimately is helping me become a better teacher and better research mentor. That said, it is EXHAUSTING. This week is a bit better than last because the research is underway and I’m repeating last week’s curriculum, but it’s still very busy and very packed. Fitting all my other responsibilities, as chair and faculty member and research mentor, into these packed days has been quite the challenge. But at this point, even with the mental and physical exhaustion and the challenges, I would definitely do this again next year, and in fact am looking forward to doing this again next year.

Trusting the process

For the past 9+ weeks, I’ve been following a training plan for the half-marathon I’m running 2 weeks from this coming Saturday. The training plan is a typical one: each week has 4 days of running. One of the 4 days involves speedwork: intervals, a tempo run (i.e. “run at this pace for this number of minutes”), or hill repeats (run up a hill fast, walk down, do it again and again). One of the days is a long run. The long run gets progressively longer, as does the speedwork, as the weeks go by. And the plan ends with a “taper” period: after you’ve spent all this time building up your mileage and endurance, you cut back and let your body rest before the big day.

There are no guarantees, of course: the plan doesn’t guarantee that you won’t get injured or sick, or that you won’t wake up the day of the race facing 95 degree temperatures and 100% humidity and have to throw your time goals out the window. Rather, the idea is that if you put in the work and follow the plan, you put yourself in the best possible position to finish the race and meet whatever other (usually finishing time) goals you have.

It is easy, particularly as race day looms, for you to get cynical and to doubt the plan. How can you really be prepared to run 13.1 miles if your longest training run is only 12 miles? Why aren’t the long runs done at the pace you intend to race at, but rather at a much slower pace? How on earth do 6×400 intervals prepare you to run at race pace? At some point, you just have to trust the process, to know that each piece of the plan each week contributes to your execution on race day, and to go with it.

Trusting the process is something that I do often as a professor. When I teach, I trust that if I’ve prepared properly—digging up and digesting background readings, developing illustrative examples, working through in-class activities, anticipating likely questions and points of confusion—then class is most likely going to go well. I can’t guarantee this, of course—my students might come ill-prepared, or bring low energy to the class, or an activity might bomb in unintended ways—but most often, everything will be fine. In research, unexpected twists and turns often pop up, but if I follow the plan—think carefully and methodically, locate and read the relevant literature, weigh the evidence carefully, analyze and reanalyze the data, be super-observant and dig deeper into the data—eventually I’ll succeed, even if “success” is not how I originally pictured or intended it.

In a way, trusting the process is similar to taking the long-range view while paying attention to the day-to-day details. If you think too hard about the long-term goal, it can seem impossible to obtain. But if you get too caught up in the day-to-day, you can easily get discouraged. When you trust the process, you do the day-to-day while keeping your attention on the long-term goal. One motivates the other.

Trusting the process is something that’s often difficult for new researchers. New researchers may not know or understand the long-term goal. They may get caught up in the day-to-day, and possibly even overwhelmed by it. They may not see how the day-to-day and all the small, sometimes seemingly inconsequential tasks, all work to contribute to the end goal. This can be particularly true of new projects, where perhaps the end goal is still a bit fuzzy or in flux. And teaching trust of the process is tricky, because at some point, the person just has to buy into the idea.

This is definitely happening in my lab this summer, with my brand-new project and new-to-research students. So how am I teaching trust in the process? I’m not sure if I’m doing it well or even passably at this point. What I try to do is remind my students of why we’re doing what we’re doing and continually framing the problem and the research. I do it by being specific about the small tasks we need to do to get there. I remind them of what we’ve done so far and how what we’re doing next both builds upon that and gets us closer to our end goal.

So far the trust is not completely there, but that’s ok. They are skeptical, but game. They ask lots of questions, including lots of variations on “so why are we doing this again?”, which is exactly what they should be asking. They’re starting to figure out the “next small thing” on their own. I may not get them all the way to trusting the process by the end of the summer, but if I can at least get them partway there, I’ll consider that a victory.

Limping into the summer

We’re still in session around these parts—our last day of classes for spring term is tomorrow, followed by reading days and exams, followed by the mad dash to get senior grades done 36 hours after  the final projects come in…good times. This has been a particularly brutal term, work-wise and stress-wise, so I will be happy to see it end.

This week I’m juggling both wrapping-up-the-term activities and ramping-up-for-the-summer activities, which frankly is making my brain hurt. I’m ending the term like I started the term: frantic and behind on my work. I like to try and end each term on a strong note, but this year I am definitely exhausted mentally and physically and feel like I’m limping into the summer instead of leaping energetically and enthusiastically into the summer.

This summer’s workload will be substantial, with five major initiatives (just thinking about it all makes my head hurt even more!). Here’s what I’ll be spending my “lazy” summer “off” doing:

  1. Starting a new research project. I submitted a grant application late last year for a new project. I’m super-excited about the project: it combines my previous research on rich media and quality of experience with some network measurement, human-centered computing, and tool-building thrown in for good measure. But starting a new research project is always a bit daunting: what if it turns out this is a bad idea? what if we don’t get anywhere? where the hell do we start? And starting a new research project with students (see below) is doubly daunting. I have a vague plan of where to start, but frankly part of me is terrified. We could easily spend the entire summer just trying to get things up and running and still not have anything up or running at the end. I think the chances of that are small, but it’s enough to keep me up at night. At any rate, I’ll definitely be busting my ass this summer trying to get this project off the ground.
  2. Teaching in a brand new high school program. Because clearly starting a new research project from scratch is not enough excitement for one summer! Seriously though, Carleton is starting a new CS summer program this year for high school students for 3 weeks. We teach the students in the morning and work with a subset of them in the afternoon, in our research labs, on “real” CS research problems. I am very excited about this program, but know realistically that it will be a lot of work. We had our curriculum meeting today, so I’ve already done a bunch of planning for my classroom portion of the program, but still need to hammer out details about the research problems, as well as the software/programming language. Not to mention that the research problems, as I envision them at this point, rely heavily on progress we make on the new research project leading up to the high school program….yeah, there’s no way THIS could fail!
  3. Supervising 3 undergraduate research students. I took a hiatus last year from supervising students in my lab, mainly because I thought I’d be on parental leave, but this summer my lab will be full of students again. None of the students working for me have experience doing CS research, so my involvement will be very hands-on at the start of the summer. However, most of my former research students had no experience either, and things turned out well, and this group seems really eager and ready to get to work. (Plus I’ve been working with 2 of the 3 of them this term.) The one worrisome part is the new students + new project combination. I think I just need to go in with a flexible mindset and plans B-Z if things go awry. Again, what could possibly go wrong?
  4. Taking over as department chair July 1. And just like that, my service commitments increase exponentially. My big tasks out of the gate will be getting the agenda together for the department retreat in August and sketching out job ads for our tenure track search—and, of course, figuring out how to be department chair.
  5. Planning a brand new course for the fall. I’ve always wanted to teach a human-computer interaction (HCI) course. I sort of did so with the dyad a couple of years back, but this time around I’ll be teaching an A&I (freshman) seminar on the topic. I’m wildly excited about this opportunity, but (a) this is not my area and (b) we don’t have a senior-level class which I can raid for ideas. I met with some great people at SIGCSE this year who gave me some great teaching and course construction ideas, and my high school course in the summer program is on HCI, so I’m not completely starting from scratch. Still, this should be quite the adventure. (And did I mention that by definition this is a writing-rich course? Yikes!)

In addition, I have some assessment tasks to wrap up in July before handing over the assessment reins, and organizing our contingent for Grace Hopper will of course take place throughout the summer. And did I mention I’m running a half marathon in early August?

The good news is, with the exception of #4, everything on my plate this summer is fun-to-me and exciting and intellectually stimulating. Yes, I’ll be working hard, but it’s all on things I’ll enjoy immensely. So that definitely makes things a bit less daunting. That said, my goal is to get through the summer sustainably, without burning myself out….because I’m really going to need to be fresh and well-rested and renewed before the absolute insanity that will be my next academic year.

 

Random bullets of 7th week spring term

  • We’ve now officially reached the point in the term/school year where there is no schedule—there is just running from one crisis to another. I am too tired for planning anything beyond the next half hour.
  • Signs your job might be adversely affecting your family life: You joke about quitting  and your spouse says “can you? really? please?”. Uh-oh….
  • Everyone (neighbors, day care parents, random people on the streets) keeps asking me when my summer starts. This is the problem with the term system: we have 3 more weeks of classes. Heck, I just finished grading midterms! This is the tradeoff with terms: August is awesome, May stinks.
  • 2/3 of the readings in my Software Design class have been, well, let’s say not your typical textbook readings.* The tone is easy and conversational and a bit irreverent, but the content is still pretty hefty. Which is why I chose these readings—they get all the important points across in an engaging but nontrivial way. What I’m finding interesting, though, is how the students are reacting to these readings. A few off-hand comments and questions from a few students indicate that the tone obscures the fact that there’s quite a bit of substance there. This is especially true of the web usability reading. Next time I teach this course, I will make a more conscious effort to point out the theory behind the readings, but it’s been an interesting lesson.
  • We are not quite there yet, but someday (someday!) I will not find it remarkable that I have an all-female final project group.
  • Officially I don’t become department chair until July 1, but it’s kind of already started for me. Students have started coming to me asking all sorts of complicated questions about graduation and major requirements and special cases. I have a hiring meeting w/ some deans later this week. I’m already getting all manner of chair-related emails (particularly about budgets). I’ve started thinking about all sorts of processes and agendas and such. I’m glad for this transition time, but at the same time part of me is like IT’S TOO SOON! AAAARRRRGGHH!
  • One particular chair-related issue that’s keeping me up at night: We have 57 newly-declared CS majors. Yes, you read that number right. I’ll wait for you to pick yourself off the floor…. So, we need to put all these majors in project teams for Comps in 2014-15. How do we do this without completely overwhelming our faculty resources? Great question. Let me know if you figure it out.
  • Next week I’ll be at the NCWIT summit in Tucson. I look forward to the Summit every year (look for live tweets again!)—I always learn a whole bunch of new things, and it’s a great excuse to see the people I see at Grace Hopper and/or SIGCSE again (there is a lot of overlap in those crowds). This year I’ll be running a session in the Academic Alliance meeting along w/ my other team leaders. I’m excited—we have a great plan and great panelists lined up—but also nervous because part of our session involves a software demo. Trying not to panic about the many things that could and might go wrong there…yikes!

* Krug’s Don’t Make Me Think! and Freeman/Freeman/Sierra/Bates’ Head First Design Patterns