Geeky fun: The “sound” of different sorting algorithms

One of the topics every computer science student learns is sorting algorithms:  different mechanisms to put pieces of data in order.  It is sometimes difficult to get students to understand the differences and nuances between algorithms.  For instance, both insertion sort and bubble sort put things in order in roughly the same time, so why do we consider insertion sort better than bubble sort?

Visualizations are a great way to get this point across, but someone has taken this idea one step further and has come up with a way to make, in essence, sound maps for the different algorithms!

The post linked above also links to a heapsort sound map, and goes into a bit more detail about how the sounds were generated.

I think my favorite is bubble sort:  it sounds like Pac-Man!  In general, it’s neat how each sorting algorithm does in fact have its own sound.  I will definitely use this the next time I teach sorting!

(h/t Jack Goldfeather for the link)

(Academic) new years resolutions, 2010-11 edition

Here at Carleton, we still have a few weeks to go before the start of school, but school has been on my mind lately because things are definitely gearing up around here.  The start of a new school year is the time I choose to make resolutions, because this time of year feels more like a fresh start than January 1 does.

In last year’s resolutions post, I knew exactly what I wanted to focus on:

…I have one resolution:  To find the sweet spot in my own life that allows me to work productively and sustainably.  To figure out how to work effectively and efficiently and to make the time for my family and for taking care of myself.  To not end the term, or the school year, in a frenzied and frazzled state, but rather to work calmly, consistently and productively.  To find a balance that makes me happy and fulfilled, but still allows me to get my job done to my satisfaction.

I can’t say I did perfectly in this area, but I can say that I have a better awareness of where my time goes, and even if I don’t always do a great job of prioritizing, I’m getting much better at it—and much more willing to focus my energies on what’s important to me.  I’ll give myself a B- for last year.

This year I’m in a much more settled state:  I have tenure.  (I have tenure!!)  My research is in a very stable state and is progressing wonderfully.  Most of the courses I’m teaching this year are ones I’ve taught many times before.  I feel much more comfortable in my own skin, career-wise.

And yet, looking ahead, this is going to be a very challenging year.  With tenure comes greater responsibilities.  My service load is especially heavy this year.  I want to keep my research momentum going—-and it’s time to start thinking more long-term as well, and figure out just where is all this research going?  And of course there’s teaching:  I’m here because I want to teach, I want to be an excellent teacher, and I want to give my students the best class experience possible.  Tenure brings freedom to, for the first time, freely and critically evaluate what I want to do in the classroom—but this, too, is a great responsibility.

So with this in mind, I have three resolutions for the academic year—and, coincidentally, each one touches on a different aspect of my job:

1. (teaching) To become a better storyteller. This is something I blogged about earlier this year.  Stories, particularly the stories behind the people who invented the algorithm/hardware/programming language we’re discussing, the technology we take for granted, etc., can be a very powerful way to put CS into context.  I’ve concentrated, in the past, a lot on current news stories to present context, but history lessons can be just as powerful.
2. (research) To figure out exactly “what I am”. My research straddles a few subfields.  I’m fine with that, but it sometimes leads to problems when figuring out how to pitch my work, where to send my work, etc.  It also means that I don’t really feel like a part of any one community:  I’m not “really” a networking researcher, or a multimedia researcher, or an HCI researcher, …. This year I’d like to get a better sense of what spaces and subfields I’d like to inhabit, and become more involved in those communities.  I’m hoping this exercise will also help me do some strategic long-term research planning—where do I want my research to be in 5, 10 years?
3. (service, kind of) To keep things in check. I hesitate to use “balance” because it can be a loaded term and I know balance is kind of a pipe dream this year.  Instead, I just want to make sure that I keep my service responsibilities, along with everything else, manageable, so that I can also enjoy my family and my down time and the other things that are important to me.

What are your resolutions for the new school year?

Five things that helped me survive summer

A couple of days ago over at ProfHacker, there was a post (by all the contributors) listing five things—technologies, activities, random items, etc—that helped them get through the summer, made them more productive or happier, etc.  (Suprisingly, I haven’t seen too many other academic bloggers pick this up, other than here.)  I thought this was an interesting exercise and decided to give it a whirl.

So, here are my five things:

1. Google Docs. This has been indispensable for my work this summer.  I’ve always had a very hard time getting my research students to maintain up-to-date notes and documentation about their work.  This summer, we decided to use Google Docs for this purpose.  It is so nice to have a complete record of all of our notes, crazy ideas, paper drafts, etc all in one place, all easily accessible and editable by everyone.  I’m also using it in two other collaborations—planning a linked course for Fall 2011, and planning a regional conference.  I’m not sure how I effectively collaborated without it!
2. Running/daily exercise. I’m one of those people whose brain cannot function if the body has not been moving.  I need exercise to keep my sanity and keep my head clear.  This summer has been one of the few in recent memory that I haven’t been injured or sick or otherwise unable to run for part of the summer, and it’s been wonderful rediscovering the joy of running.  It makes getting up at the buttcrack of dawn much more bearable.
3. A super support system. Peer mentors are a powerful thing.  I have a wonderful group of women whom I meet weekly for coffee.  Sure, many of these “working sessions” (ahem) turn into gossip fests, but they are also places for encouragement and butt-kicking.  We share each others’ successes and brainstorm ways to get each other unstuck.  We share information and strategies.  We keep each other sane, on-track, and laughing.
4. A great group of research students. Selecting research students is always something of a crap shoot:  just because a student is bright in the classroom doesn’t necessarily mean s/he will be good at research, because the skill sets are somewhat different (a point I discussed in a previous post). Over the years, I’ve been mostly lucky in this regard.  This summer, my students have been especially strong.  They work very well together as a group, and individually as well, and have pushed our research way beyond what I expected this summer.  Most days now they shoo me out of the lab so that they can get work done!  Working with them has allowed me the time and space to concentrate on other aspects of my work as well, and to think more clearly about the future of my work.
5. Interlibrary loan and ebooks (tie). I am almost certain that I have checked more out of the library through interlibrary loan this summer than I have in my previous 7 years at Carleton combined.  And this summer, I bought my first ebooks (because I was too impatient to wait for the paper versions to ship, but still).  Recently I’ve expanded my view of which subfields relate to my research, and by expanding my view, I’ve discovered a whole new set of literature that will help push my research forward (and possibly in all-new directions!).  I’m now way behind on my reading, but I’m also looking forward to scholarly reading in a way I haven’t for a long time.

Not making the list, but honorable mentions, include taking time away from Carleton (sometimes you just need to get away), rediscovering the joy of entirely free weekends and mostly free evenings, and my iPhone, which allowed me to go away for a week and not bring my laptop with me.

What helped you survive the summer?

Summer in the lab: the homestretch

It’s week 9 of my 10 weeks with my student researchers.  Where has the summer gone?  Seriously.  Things are wrapping up in the lab—my students are busy analyzing the results from our experiments a few weeks ago and writing up their results, which will eventually (hopefully) be woven into one or more conference papers.

As I’ve mentioned in previous posts on student research, one of main goals as a research advisor is to help my students become more self-sufficient, able to come up with questions and lines of inquiry on their own and follow up on them.  My students were put to the test last week in this area—I took the week off to visit family and purposely did not bring my laptop with me (and checked email minimally).  So how did they do?

Awesome!

• I did not get a single email from them all week.  Not one.
• I left a ridiculously long to-do list, and except for the last item (which was really pie-in-the-sky thinking), they made not just progress, but good progress on the rest of the items.

• They had to give a talk at an undergraduate research symposium.  I saw a very rough version of the talk the Friday before I left, but that’s it.  They wrote the presentation completely on their own, and from what I’ve heard they did a great job with it!
• I have had minimal meetings with them this week, because they are too busy/engrossed in their analyses and writeups.  On Monday, my first day back, we spent much of our meeting time having them run ideas by me about things we could do with the data—some of which I, honestly, never considered.  Together we came up with a complicated analysis to attempt—I sketched out a very rough idea of what I wanted, but they did all of the leg work in figuring out how to actually do the analysis.

So I’d say my students are pretty self-sufficient now.  I’m so proud of the work they’ve done this summer and with how far they’ve come.  I’m really looking forward to seeing their results, and their interpretation of these results.  They’ve really done a lights-out job moving the project forward this summer.  I hope they are as proud of their work as I am!  (And yes, I plan on telling them exactly that!)

Asking the right questions

Hard to believe, but it’s the end of Week 7 of the summer in my lab.  We’ve been very busy recently:  earlier this week my students ran some experiments (which they designed completely by themselves!) with human subjects, and they are now busily analyzing the data.  They’re giving a talk, all by themselves, next week.  And I’ve had them start writing up their results, with a conference paper as the eventual end goal.  So things move ever onward.

Brigindo at Dirt and Rocks has a really interesting post from earlier this week about helping (doctoral) students “find the story” in their research:  learning to frame their data correctly, to tell the correct story, and above all to start asking better questions.  This post really resonated with me.  My students are now knowledgeable enough to know what they are doing and why, but they are still learning how to ask the right questions.

Here’s an example.  We have a testbed network set up on which we run our experiments.  The network has a router running netem, which is software that allows us to essentially emulate the Internet:  we tell it how much data to lose, or how long to delay data, or how much data to let through, etc.  As part of the experiments we just ran, we set netem to lose certain percentages of data at different times.  At the same time, at each test computer we measured the actual amount of lost data using a program called ping.

When we looked at the results, my students noted that the measured data loss was off from the data loss percentage we applied.  Their immediate reaction was to assume that either the ping data was wrong, or netem was wrong.

This highlights a couple of thorny aspects of shaping the thinking of undergraduate researchers from “classroom thinking” to “research thinking”.  First, students are used to a more black-and-white view of the universe:  if one answer is right, then all other answers are wrong.  This of course is not how the universe works, and in fact research questions may have many right answers, or none at all.  In this case, both netem and ping may be “right”, or “wrong”, and what they are probably seeing is an artifact of the probabilistic nature of computer networks.

Second, students are not used to context switching between the big picture (what problem are we trying to solve and why?) and the smaller details (run this experiment, collect this data, do this analysis).  Again, what are students more familiar with?  Doing smaller tasks covering one or maybe a small handful of skills.  In research, you need to have an eye on both the big and small pictures, on the details and the trends.  To do so, you have to be able to take a step back from the data, or your observations/analysis of the data, and ask the right, framing questions.

The latter is probably the most difficult skill for new researchers to learn—heck, even the most experienced researchers can experience such tunnel vision from time to time.  I end up teaching by example in this case:  my students present their observations and analysis, and I ask them leading questions to get them to think more deeply and broadly about the data/results/whatever.  I ask them to think about what the results could mean, to get them to explore different explanations and hypothesis.   My hope is that by seeing me do this, they will eventually learn how to move beyond their initial reaction to and assumptions about the data and be willing to explore it in more depth or with a different lens.

In this case, I directly challenged their assumptions, and asked them to think a bit about the possible reasons for the discrepancies.  I also asked them to consider what an “acceptable” amount of error would be:  if the measured and applied losses are only off by 1%, is this a deal breaker or is it within the realm of plausibility? I could have just as easily told them “nah, this is normal” and be done with it, but I’d rather have them spend the extra time and come out with a deeper understanding of what’s happening than to have them blindly trust what I tell them.  Because critical thinking and the willingness to consider multiple possible explanations is a vital skill for any researcher, and one that requires practice, practice, practice.

An interesting publishing model

There’s been some renewed discussion in the blogosphere and CS media lately about the broken model of CS publishing. In the latest issue of Communications of the ACM, for instance, Moshe Vardi’s editor’s letter discusses hypercriticality, or the tendency of some reviewers to be overly and needlessly negative, and how this is harmful to our field:

We typically publish in conferences where acceptance rates are 1/3, 1/4, or even lower. [Actually, the top conferences in my field have acceptance rates closer to 10%!---acd] Reviewers read papers with “reject” as the default mode. They pounce on every weakness, finding justification for a decision that, in some sense, has already been made….If the proposal is not detailed enough, then the proposer “does not have a clear enough plan of research,” but if the proposal is rich in detail, then “it is clear that the proposer has already done the work for which funding is sought.”

What is to be done? Remember, we are the authors and we are the reviewers. It is not “them reviewers;” it is “us reviewers.”…This does not mean that we should not write critical reviews! But the reviews we write must be fair, weighing both strengths and weaknesses; they must be constructive, suggesting how the weaknesses can be addressed; and, above all, they must be respectful.

A mailing list I’m on pointed me towards this blog post, lamenting the state of systems-level HCI research (basically a good discussion of what type of work is “valued” by a subfield, and how this plays out in the review cycle—I can certainly relate!), and concluding with the following:

What is the answer? I believe we need a new conference that values HCI systems work. I also have come to agree with Jonathan Grudin that conference acceptance rates need to be much higher so that interesting, innovative work is not left out (e.g., I’d advocate 30-35%), while coupling this conference with a coordinated, prestigious journal that has a fast publication cycle (e.g., electronic publication less than 6 months from when the conference publication first appears). This would allow the best of both worlds: systems publications to be seen by the larger community, with the time (9-12 months) to do additional work and make the research more rigorous.

These are all great questions and valid points, but it’s easy to just wring your hands and say “oh well, I need the publications so I’ll just play by the rules” rather than trying to change the system.

But one conference seems to have been paying attention to the discussion.

VLDB, a databases conference, is trying out a new reviewing model, attempting to combine the best features of journal pubs (multiple reviews and rebuttals) and conference pubs (timely publication, quick(er) turnaround time).

PVLDB uses a novel review process designed to promote timely submission, review, and revision of scholarly results. The process will be carried out over 12 submission deadlines during the year preceding the conference. The basic cycle will operate as follows:

A Rolling Deadline occurs on the 1st of each month, 5:00 AM Pacific Time (Daylight Savings observed according to US calendar).

· Initial Reviews are intended to be done within one month, and they will include notice of acceptance, rejection, or revision requests.

· Revision Requests are to be specific, and moderate in scope. Authors will be given two months to produce a revised submission.
· Second Reviews are intended to be returned within one month, after which a final decision will be made. Second reviews are to directly address the authors’ handling of the requested revisions

What’s more, they also address some of the points made in the first two articles I linked to, and common complaints about the review process (emphasis mine):

The revision process is intended to be a constructive partnership between reviewers and authors. To this end, reviewers bear a responsibility to request revisions only in constructive scenarios: when requests can be addressed by specific and modest efforts that can lead to acceptance within the revision timeframe. In turn, authors bear the responsibility of attempting to meet those requests within the stated timeframe, or of withdrawing the paper from submission. At the discretion of the Program Committee, mechanisms may be employed for reviewers and authors to engage in further dialog during the revision period.

This is a really fabulous idea. There are still issues—you trade off between submitting early in the review cycle (and getting more feedback) and having a long turnaround time to publication, and it’s unclear if people will still wait until the “hard” deadline (March 1) to submit their work. But if it works, this could really revolutionize how we think about both conference and journal publishing.

(Oh, and it appears they have a semi-loose connection/agreement with a journal, encouraging submissions of extended version of the conference papers—not clear if these will be “fast-tracked” at all, though.)

I will be watching what happens, and hope that the VLDB organizers prepare some sort of summary of what worked well and what could be improved (and whether this actually works!) so that other conferences can adopt and adapt this particular model.

What are you searching for?

If you’re visiting this blog, most likely something about writing conference papers or Moodle, apparently.

I love numbers and stats and trends and all that fun stuff, so about once every other week I take a look at my blog stats.  I like to see where people are coming from (referrals), what posts they’re reading, etc.  (My favorite discovery:  If you put “getting things done” in your blog title, you get a lot of hits!)

The most fun part, though, is looking at the search terms people use to get to this here blog.  So, what are the most popular search terms of all time for this blog?*

1. Searches for me directly (N=59).  This was by far the most popular search item.  I had to laugh, though, about the 2 people who found me by searching for my URL.  Um, if you already know my URL….oh, nevermind.
2. Moodle (N=37).  People came here to complain or learn about font sizing in Moodle.  Well, at least I fulfilled the first wish…
3. How to write a conference paper (N=34).  Um, yeah, I hope those people weren’t looking for actual advice on that one…
4. This is what a computer scientist looks like (N=16), and variations thereof like “how to look like a programmer” and “how to look like a scientist”.  I’m probably not the world’s authority on either, since no one believes me anyway when I tell them what I do for a living!
5. Barbie-related searches round out the top 5 (N=14).

And here are some of my favorite random searches that led people here:

• why do computer scientists like mountains.  Good question!  I know I like mountains, but I can’t speak for all computer scientists…
• becoming a computer scientist when older.  Not sure how I am the authority on this, since I went straight through to grad school….although I did take a bit of a break before becoming a professor…
• good problems to talk about.  I kinda dig this one.  I hope these 2 people found something to talk about!  (But as we all know, writing good problems is hard.)
• innovative female design.  Again, another cool search term, and I wish I had more interesting links than these—but I guess it’s a start…

However you got here, whatever led you to this blog, thanks for stopping by and reading!

(And on a totally unrelated note:  I’ve been very bad about putting up any sort of blogroll, but I’m going to put one up Real Soon Now.  So if you’re a regular or semi-regular or hey, even a drive-by reader and you’d like to be on the blogroll, leave a comment.  Thanks!)

* I’m not exactly sure how WordPress calculates these—for instance, none of the GTD-related searches are showing up in these stats, and that’s been a fairly popular search term this week.  So these may be a bit inaccurate or out of date.

Publishing calculus

For those of you reading this blog who are not academic computer scientists:  In CS, most of the publishing is done through conference proceedings.  Conference submissions, unlike in many other fields, consists of full-fledged papers which undergo a single cycle of peer review with an up-or-down decision at the end; these full papers are then published as such in the conference proceedings.  The conference paper cycle is preferred because the time-to-publish is much, much faster than journals—which is much better suited towards the fast-paced nature of CS research. However, journal publications are still required and necessary for tenure and promotion at most places.  And, at least according to conventional wisdom, journal articles are seen as more “complete” records of research results (often a journal article will combine and build upon results from several conference papers).

Because the journal review and publication cycle can be so slow compared to the conference review and publication schedule, conferences have become highly competitive—in fact, the top conferences in CS, most would argue, are more selective and more prestigious than most CS journals.  The slow journal publication timeline, some argue, has led to the proliferation of CS conferences (and the reduced value of attending conferences, which in many cases these days consist mostly of those presenting papers), which, some argue, leads to even slower timelines for journal publishing.  (There was a lot of discussion around the blogosphere and in the Communications of the ACM about this very issue last year [see these editorials]—John Dupuis at Confessions of a Science Librarian has a great set of posts summarizing the discussion here and here.)

This leads to some interesting calculus when it comes time to publish and submit some results.  If something is brand-new and never published, clearly it goes to a conference.  Conventional wisdom might say that if it’s building upon something you’ve published at a conference, or building upon several other papers, then send it in to a journal.  Or should you, particularly if you know it might be years before your paper sees the light of day, if at all?  Should a journal still get your best and most complete work, or is it worth instead sending it to a highly competitive conference?

I currently have a journal article under submission.  I originally submitted it in 2008.  It has already gone through three cycles of review (original submission plus 2 revisions), and yet it is no closer to being published today than it was 2 years ago.  The main contributions of the work have already been disseminated via a couple of conference publications, but there is still substantial new work represented too—although this work is now more than 2 years old.  The project has moved well beyond what’s represented in that journal article.  And yet, it continues to live in that special purgatory—not rejected, yet refusing to be accepted.

At this point, I will probably submit it for one more round of review.  I could submit it to another journal, but there are problems there, too.  I’d probably be looking at another couple of years to a decision, and I have no idea if another journal would be more or less likely to accept this article for publication.  Plus I’d have to deal with a whole new set of reviewers and editors, some or all of whom might have much different ideas about how I should present and frame my work for their journal.  Also complicating things is the fact that my work straddles just enough subfields, and is unconventional enough, that finding an appropriate journal is tricky.  (Since my research falls into subfields X, Y, Z, and a bit of Q, X journals often say “this is really Y work”, Y journals say “nope, this is Z work”, etc.)

So the thought has crossed my mind, more than once, that perhaps I should forget about publishing this work in a journal and just repurpose it into one or more conference papers, and target highly selective conferences.  That way I still get “credit” for publishing in a top location without the super-long peer review cycle.  The fact that I’m even considering this shows you how weird and messed up the whole publishing model in CS has become.

The problem is that even though I have tenure, I still do need the journal pubs if I want to be promoted to full professor.  So most likely I’ll continue to jump through the hoops to get my work published in a journal—even though by the time that happens, if it happens, the work will be out-of-date.

The question is:  will this article be published before I’m ready to send out my next journal article?  I wish I had a more definitive answer than “maybe”.

Self-sufficiency vs. getting things done

It’s Week 4 already for my research students, and summer research is in full swing.  My students have spent much of their time so far working on some data collection and data analysis tasks, and had their first opportunities to do some technical writing (which will be good practice for the conference paper they will write at the end of the summer).  They’ve learned a few new programming languages (Java, Perl) and modified code written by others (and not very well commented).  They’ve hit a lot of dead ends and experienced a lot of “huh, that’s odd” moments with the data.

In short, they’ve had a pretty full research experience already!

As a research mentor, I’m facing a couple of key challenges at this point in the summer:

1. Helping my students to become more self-sufficient, while still encouraging them to ask questions
2. Carving out time to get my own work done, while still being an effective mentor to my students

The first challenge is particularly tricky when working with students who are not familiar with the whole “doing research” drill.  Doing research means that we’re working with questions without answers, essentially working at the edge of our knowledge of a field.  Students are used to problems that have “correct” solutions, and are used to having someone to turn to (a professor, a classmate, the almighty Wikipedia) for that answer.  Students new to research will sometimes become paralyzed with the unknown, and instead of trying something will either do nothing, or will ask questions too often (confirm everything before trying, for instance).

My responsibility is to get them to try out ideas before asking me questions—in essence, getting them to trust their instincts, and to develop a research instinct in the first place.  So, for instance, when a student comes to me and says “the program doesn’t work and we don’t know why”, instead of running down to the lab, I’ll ask if they’ve isolated the problem to a particular section of the code.  If they’ve isolated the problem, I’ll give them a few things to try—or, better yet, I’ll ask them “what do you think you should try next?”  By not rushing to bail them out, and by forcing them to confront their demons, they become more willing and able to do the initial legwork on their own, and end up coming to me with more interesting questions because they’ve already answered some of them on their own.

The flip side is knowing when to spend the time walking them through the answer.  This afternoon, for instance, I decided to sit down with one of my students and walk her through a particularly tricky section of code which had to be modified.  Sure, I could have said “here is the API, figure it out yourself”, but I sensed that both of us would be more productive if I put in the face time with her.  And it turned out to be the correct thing, because we discovered the code in question is quite inefficient, and put fixing the code on our to-do list.

This leads, though, to the second challenge:  working with 4 students, I am less in control of my schedule than I’d like, because I never know when I’m going to have to spend the afternoon in the lab with them, or when a technical problem they can’t fix is going to crop up.  I am queen of the daily to-do list, but lately much more is not getting done and migrating from daily list to daily list.  I need to carve out some time that I know I won’t be interrupted so that I can work on the bigger/more intellectually challenging tasks, and balance those with the smaller, more deadline-driven tasks.  I’m also experimenting with putting specific blocks of time on my calendar for specific tasks—we’ll see if that works better this week.  I think I also have to be a bit more realistic about what can get done in a week, and be satisfied with that.

The challenge in the comming weeks, for me and my students, is maintaining momentum and morale, as the project intensifies and the problems get harder.  Hopefully we’ve laid a solid enough foundation in these first few weeks to maintain both.

Summer in the lab

The exams and projects have been graded, the grades have been submitted…it’s summer!  And summer around here means…research!  And research students.  So I thought it was a good time to write a “state of the lab” post, which I haven’t done in a while (possibly ever).

This summer I have 4 students working in my lab.  None of them have ever done research before, and none of them have taken any classes related to my research area—they are all fairly new to CS.  So as a research mentor and advisor, I have a bunch of tasks to accomplish this week:

• Get my students up to speed on the project.  In order to understand what they’ll be doing, they have to understand what we’ve already done, as well as the motivation behind this work in the first place.  This year I spent a lot of time the first day talking about the history and evolution of the project, to give them a sense of “place” and context for the work.  They also read past papers written by the research group as well as at least one paper from a lab doing related work—this gives them a sense of how different researchers approach the same problem.  Finally, they take a look at the code and data (at least a small subset) that we’ve written/collected so far, to get a sense of what they’ll be working with all summer.
• Get my students up to speed on the relevant background material.  As I mentioned, none of my current students have taken a course in computer networks.  So on Day 1 I gave them a crash course on networks, and the next day they had a crash course on streaming video.  In addition to (textbook) readings, this year I also gave them some of the labs that my networks students do in class, so that they could practice with the concepts as they read.
• Get them to touch a piece of the project.  I feel it’s really important for the students to develop a sense of ownership over the project as soon as possible, so that they feel invested in it.  This year, I’m having the students analyze some data that I’ve recently collected but haven’t had a chance to fully analyze.  Not only does this task get them working with Actual Data, but it helps me see how they’re thinking about the project, too, through the decisions they are making about the analysis.
• Teach them the tools they’ll be using on the project.  We use a lot of different software on the project:  packet sniffers, routing tools, version control, and 2 different IDEs.  So part of this week was spent practicing with these tools, so that their use becomes second nature.

Yesterday, we took a field trip up to Macalester to meet with CS faculty and research students from Macalester and from St. Olaf.  Each student gave a short talk on their summer research.  It was neat to hear about the research happening at our peer schools and to get the students together to meet and network with each other.  Even though my students had only been on the job for 3 days, they gave a great talk on the project!  They clearly understand the project and the work, and I’m excited about what they’ll be able to accomplish as a result.  (I think my “state of the project” talk on the first day really helped them put their talk together—they were able to clearly articulate why we were doing this research, as well as how what they’ll be doing will fit in to the project as a whole.)

Next week, the students will get to delve into the code base for the project, and start changing the design of our measurement tool.  I’m especially excited about this part of the project because it’s been on my to-do list for quite some time.  I’ve already had some good preliminary discussions with my students about the experimental design, and I suspect that these discussions will help guide the software redesign.  Hopefully the tone, and framework, I’ve laid down in the first week will help the students to make good progress next week, and in the coming weeks this summer.