By the numbers

As chair, I spend quite a bit of time with numbers of various sorts. There are budget numbers and enrollment numbers. There’s the number of sections of courses per term and per year. Relatedly, there are FTE numbers, or how many warm bodies do we have to teach courses and how many courses are they teaching at any given time….you get the idea.

At this time of year, when sophomores declare their majors, I hyper-focus on numbers related to the sophomores. This includes the number of students who’ve declared as computer science majors, the difference between the size of this year’s class and the previous few years’ classes, the percentage of women and underrepresented minorities, and the “yield” from certain courses, among others. Looking at these numbers gives me the opportunity to assess the state of the department on a mini-scale: a quick way to determine if we’re where we want to be and heading in the right direction.

In many respects, our numbers are excellent. My quick and possibly inaccurate sampling of the usual suspects indicates that we are now the largest department on campus in terms of majors in the sophomore, junior, and senior classes (tied with Biology), and that we have the largest number of majors in the sophomore class (followed by Biology and Economics, who if memory serves are tied). At the time of this writing, we have 50 majors, which is right in line with the past 2 classes (55 in the current junior class and 54 in the current senior class). I suspect we will stabilize in the mid-50s once the double majors declare—there are some omissions from our current list that I’ve already talked with about double-majoring, so I am just waiting for them to come to me with forms in hand at some point over the next few weeks.

There is one number of which I am insanely proud: I taught a first-year seminar in the fall of 2013 on Human-Centered Computing, and 7 of the 16 students in that course (who are now sophomores) declared as computer science majors. I was hoping for a good yield from that course, but frankly I was stunned at just how high the yield was! What an argument for the importance of teaching courses outside the major sequence. (Note to self: remember this when putting together the 2016-17 schedule!)

There are some numbers that concern me. Our major population is diversifying, but we could definitely be doing much better in this regard. Also troubling: after 2 years of 30-35% women majors, our sophomore class is just 20% women. Again, these numbers might creep up a bit once the double majors declare, but the percentage is not going to change significantly.

The decrease in the percentage of women has me pondering the possible reasons. Has there been a culture shift in the department? Are we doing something differently in Intro or in our “first-tier” required courses (data structures, math of CS, organization and architecture) that we weren’t doing 3-4 years ago? Are the larger class sizes off-putting more to women than to men? Are there things that we’re neglecting to do, now that we’re swamped with students, that we used to do, to foster community? (For instance, I used to send short, personal emails to Intro and Data Structures students encouraging them to take more CS courses, but I don’t always remember to do that to the same degree as I did in the past. What effects does this have on retention in the major?) In short, what’s changed?

Another factor I pondered on my walk across campus to class today: what effect does having senior faculty teach some of those “key” courses have on recruitment and retention? Now, we have a vibrant cohort of assistant professors and visitors who are doing a fabulous job, and many of them are teaching those key courses. But I think it’s important, for many reasons, to have us old fogies the senior, tenured folks at these entry points, too. And that’s the problem: we are so busy and so over-committed as a senior group that we’re teaching many fewer courses. For instance: There are 4 tenured professors in my department (2 full, 2 associate). The normal teaching load per tenure-track professor is 5 courses a year (2-2-1 or some variation). So among us, we should be teaching 20 courses. Next year? We are teaching 11. One person is on sabbatical all year, one is essentially teaching half-time because he was elected faculty president, and two of us have a course release (me for being chair, another colleague for chairing a large campus committee). And two of us are leading senior capstone groups as one of our “courses”, which means that we’re teaching 2 fewer “classic” courses. And because of scheduling and expertise constraints, with maybe 1-2 exceptions we’re teaching all upper-level courses.

So what are my take-away points, after this navel-gazing romp through the numbers?

  • We have a vibrant department. Our enrollments are healthy and strong, and this is translating into majors. And our majors are awesome—I’m very excited about our newest class!
  • We need to continue to prioritize “outreach” in terms of first-year seminars and similar courses. It’s definitely worth it, even it if means offering one fewer course for our majors per year.
  • We need to take a closer look at our culture. I’d like to informally talk to students to get a sense of what’s happening “on the ground”. In particular, I want to chat with the leaders of our 2 student groups, particularly our Women in Computing group, and our SDAs (student departmental advisors) and get their thoughts on what we’re doing well and what we might do differently.
  • Similarly, we need to individually look at what we’re doing as faculty to encourage our students to explore computer science, and make sure all those best practices we’ve honed over the years are still in play.
  • Frankly, I’m not sure what to do about the overcommitted senior faculty issue. I sense this issue is not going to go away anytime soon—to be honest, I’d be shocked if one of us old fogies is not tapped for an administrative post in the next 3-5 years. But are there ways we can work with the faculty affairs committee, for instance, to ensure that we can both serve the college *and* staff our courses appropriately? (For instance, could this committee check with departments before allowing a nomination for a major campus position to move forward, to make sure they are not inadvertently causing a staffing crisis for that department? In short, could opportunities be timed better for *all* parties involved?)

The CS department is a totally different place now than when I first arrived. We worked hard as faculty to grow what we hope is a welcoming, open, fun culture. I am confident that we can continue this moving forward, but just as it took lots of energy and commitment to get us here, so too will it take energy and commitment to keep us here. I hope we’re up to the task.

Reuniting with an old familiar course after a long layoff

As you could probably tell from the radio silence, things have been crazy around here. December and the first part of January were a blur of grant writing (and frantically finishing up simulations/analysis to generate data for the grant proposal) and job applications, and oh yeah, some holidays and travel. And in the midst of this craziness, class prep for a course I last taught in Spring Term 2012 (almost 3 years ago!): Intro to Computer Science.

Intro CS used to be my bread-and-butter course. I taught at least one, and typically 2, sections of intro each year through most of my time here. Intro is probably one of the most challenging courses to teach, partly because students come in with wildly varying backgrounds and partly because there’s so much to learn and grasp early on—the learning curve can be steep, and trying to keep track of all the syntax while also learning to think in a completely different way about problem solving is tricky and can be daunting. But it’s precisely because of the challenge, and because the students learn so much and grow so much over the course of the term, that it’s one of my favorite courses to teach.

Recently, we’ve handed over much of the teaching of intro to our visiting faculty. Part of this is because we often haven’t hired our visitors by the time we have to craft the next year’s schedule, so it’s easy to assume that whomever we eventually hire can teach intro. Part of this is also to give our new and visiting faculty a break—by teaching multiple sections of a course over the year, they are doing fewer new-to-them preps, which eases their burden. And our visitors tend to do a nice job with the course. The price of this, unfortunately, is that old fogies like myself don’t get the pleasure and the privilege of introducing students to the discipline like we used to.

Last year, when I was making the schedule for this year (one of the “perks”(?) of being chair), and weighing everyone’s teaching preferences, I saw that I had an opportunity to teach a section of intro, so I scheduled myself for one of the sections.

The re-entry has been a bit rough. Fortunately a lot of what I used to do and a lot of my old intuition about how to approach various topics has come back as I’ve reviewed my old class notes and my sample code. We’ve switched from Python 2 to Python 3 since I last taught, which I’ve taken as an opportunity to rewrite most of my sample code (which also helps with the recall). However, I tend to over- or underestimate what we can get done in the course of a 70 minute class (mostly overestimating at this point), and I’ve forgotten just how much trouble students have with a few key concepts early on in the course. My timing is off, too—I feel like I’m spending too much time explaining things and not leaving enough time for coding and practice in class—but I think I’m starting to get a better handle on that mix of “talk” and “do”.

There have been some benefits to the long layoff, though. I have some new ideas that I’ve been trying out—for instance, starting class by having students work on a problem by hand for 10-15 minutes, to get the intuition behind whatever we’re coding up in class that day—that I might not have considered if I was teaching intro more consistently. I’m reading the textbook more carefully (because none of the readings are familiar anymore and I’ve switched textbook editions), so I have a better sense of the level of preparation students have when they come into class after completing the daily targeted readings and practice problems. I’ve done more live-coding in class, because as I’ve been re-working my code examples I’ve noticed places where it would benefit students to see me code and think out loud in real time, rather than just walking them through pre-written code. Basically, I get to see the course with fresh eyes, without all the stress of it being a completely new prep.

So I’m immensely enjoying the intro experience again, and while on balance the layoff was partly beneficial, I hope that I don’t go quite such a long time between teaching intro sections again.

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.