Addicted to Flipping (week 4)

In theory I was supposed to return to regular lecturing this week, but it didn't happen. It might have to happen this week, but right now, I am addicted to flip (and I have a sense that my students are too).

Tuesday I had scheduled for peer design reviews. Let me tell you a bit about how the course works, so that this all makes sense. The three meaty assignments of the course ask students to 1) implement user processes (fork, exec, and a handful of other useful system calls, etc), 2) add virtual memory, and 3) make a simple file system recoverable by adding logging to it. The students work in pairs and are left to both design and implement solutions themselves. We ask them to first submit a design document. The teaching fellows review the design documents carefully and then interview each team, giving useful advice, pushing them on how much they have really thought about what they need to do, clarifying any misunderstandings, and otherwise acting a bit like a project manager.

Historically, design documents vary widely in quality. A few are always nicely done, thorough, well thought out, and complete. Many are usually superficial, because the students are still struggling to wrap their heads around what they are supposed to do. TF feedback is invaluable.

So, this year, before handing the designs in to the teaching fellows, we scheduled in-class, peer design reviews. Each team met with one other team and exchanged designs and then spent an hour discussing and questioning each other on the design. The questions and discussions we heard sounded quite good -- people were asking all the right questions and the teams were pushing each other in just the right way.

At the end of the class, one student made a point to say that he thought the class had been incredibly useful. We will be getting the final designs this evening, so I won't know until next week whether this resulted in qualitatively better designs, but I remain optimistic.

But I suppose my real addiction came out Thursday. Since they are now deeply enmeshed in Assignment 2, as part of my contract, I will not ask them to prep before class. In general, I assumed that meant I would return to lecturing, but as I surveyed my notes on various advanced scheduling algorithms, I couldn't quite see me or the class getting excited by a lecture on this stuff. So, I took a risk.

I prepared four presentations on some scheduling algorithms (a Solaris style Multi-level Feedback Queue scheduler, the Linux completely fair scheduler, a BSD-style fairshare scheduler, and a lottery scheduler). Then I created six roles: four engineers, each of which is partial to one of the schedulers, one product manager and one engineering manager. Each role had some "private" information and the roles and information were on pieces of paper stuck in paper cups, 6 to a table. Students formed groups of 6, selected a role from the cup and then spent about an hour in a design discussion. Given their target platform (which only the product manager started out knowing), they had to select a suitable scheduler.

My goal was that rather than having me go through the plusses and minuses of each approach, they would be forced to compare and contrast and figure out when each one was good/bad. Then each team presented their target platform and their selection, with justification. We wandered around and answered questions and also assumed some other roles: CEO who has an opinion about everything, but isn't technical, VP of marketing who fundamentally distrusts engineers, and the head of QA who would be responsible for testing their systems.

Once again, it's difficult to tell, but my sense is that they covered the important points and each has a deeper, more gut-level understanding of the various approaches. Only time will tell!

Next: Unflipped! (March 4, 2013)

Not Flipping Out (week 3)

We've just completed our third week of the semester and my flipping experiment continues. In honor of flipping the class, we will now refer to CS161 as CS191.

I'm still a fan.

There were no enormous disasters this week nor were there any sudden breakthroughs (I fully expect that simply due to this new course structure, one of my students will inadvertently do something to win him/herself a Turing award, but not quite this week.)

So, this week I will write about four happy and unintended consequences of this new arrangement.

1. Flipping as an Equalizer

Students enter courses with different levels of expertise and experience. This is always a challenge as some students constantly feel behind and others sometimes feel bored (although rarely do students feel bored while trying to get OS/161 to fork processes). With the flipped arrangement, I can break up the material into distinct topical areas with videos per topical area, and students can pick and choose which ones they need to watch. They can check out the web work and see which questions they know without viewing anything and which ones indicate they may need to view a video or do some more reading. My sense is that this acts as an equalizer. It's not perfect, but it's definitely better than a more traditional lecture where at least one student is lost and another is bored.

2. Maximizing Teaching Utility

I feel like an idiot for not having realized this before, but flipping lets instructors spend time with the students who can benefit most from that time. When I try to run an interactive lecture, I typically end up engaging with the students who are most comfortable and most expert. After all, they are the ones most willing to speak up in class. They are also usually the ones most willing to ask questions. Sure, I can look at the class and try to detect overall class confusion, but do I always catch the student who is really confused? I think not.

In contrast, when I and my teaching staff^* wander around the room, we spend time with the students who are struggling or who have questions. We check on groups and cheer on those who not only have fork and exec working, but have implemented job control, backgrounding, programmatic scripting, and twelve other features in the past ten minutes. Yes, we're excited for the students who excel, but we can be more useful in making sure that all the students are succeeding. And by and large, at the end of the session, every student has experienced some form of success. I am pretty convinced that few students walk out of a normal class feeling successful. They may feel like they were in a good lecture; they may have enjoyed it; but I don't think they feel that they were personally successful. In contrast, getting your shell to fork and exec, proving a scheduler optimal, or deriving a good scheduling routine can let you feel like you've actually accomplished something.

3. And then I travel ...

As much as I hate it, I do sometimes have to travel during the semester and miss classes. While I have talented colleagues and wonderful teaching staff who fill in for me on those occassions, I don't like it. This February is the worst -- I have three trips I have to make. Under normal circumstances I should have missed four classes, but I couldn't do that so I jiggered the trips so I will only miss two (which means I missed NetApp University day for the first time, which made me sad).

All that said, being away is not nearly as disconcerting as it is under normal circumstances. First, I can check on the web work so I have first hand knowledge of how everyone is doing. Second, I have already prepared the material I wanted to present, so that isn't very different. Third, although I cannot wander around class, I have four or five teaching staff fully engaged in the class time activity and they are wandering around talking with students and getting firsthand feedback on how things are going.

Normally, when I've missed a class and I ask how things went, I get something like, "I think it went OK." This is a truly honest reply, because someone giving a guest lecture has very little feedback on how things actually went. This time, however, I got, "Very well. I guess main things I noted:

1. People seemed good conceptually; questions I got were insightful.
2. People had a lot of trouble with the proof, so I eventually told them to move on to the design problem and come back to the proof if they weren't done.
3. I had time for one group to present their scheduler idea and it was essentially good (a min-heap with priority proportional to sleep time).
4. I had time to show the bounded priority queue idea and explain that the distribution of jobs is usually thought of as multinomial. (The group that came up with the min-heap scheduler included a math student who was trying to show it was somehow optimal for a power law job distribution, which was pretty neat).
5. I think some people may have been working on A1 in class, but I'm not sure that's bad."

I have a much better sense of what was covered, how students are doing, etc. Yes, it took more work before I left, but it was entirely worthwhile.

4. My Teaching Fellows seem more engaged and happier

^* At Harvard, teaching assistants are called Teaching Fellows. This is a moniker that arose when most such people were graduate students and the stipends they received were part of their fellowship. Technically, when undergraduates assume these roles, they are teaching assistants and not teaching fellows, but drawing such distinctions would be silly, so the culture is that we call all such people Teaching Fellows, or more colloquially, TFs. Apologies for not clarifying that earlier.

In a conventional course, the TFs are pretty disengaged from lecture. I usually want them to attend (mostly to fix things I botch up), but since they've all taken the course before, they spend much of class tuned out and doing their own thing (defeating the purpose of my having them here in the first place). However, in the current setup, the TFs are fully engaged. They are wandering around talking to students, fixing things, and actually teaching. Since most of them take these jobs because they enjoy that sort of thing, they are spending more time doing the part they like (let's face it, none of us are that excited about the grading part). In general, they seem happier to me and more interested in what's going on in the course.

And, at least to me, they say that the class time is fun. This too strikes me as a good thing.

Next: Addicted to flipping (February 21, 2013)

Flipped Again (Week 2)

Last week I was full of euphoria; this week not so much. I'll cut to the chase before diving into details. First, teaching this way takes at least three times as much preparation as teaching "the regular way." I still think it's worth it, but I can tell that it's going to take its toll. Second, in a programming course, preparing pre-class work and in-class work is a detail-oriented process, and if it goes wrong, it can go badly wrong. Third, I am hoping that full transparency, honesty, and a lot of humility will help to mitigate the disasters that can happen as a result of the previous item.

Part One: Time Intensity

Regardless of how I teach, I try to prepare thoroughly. When I lecture traditionally, I hand out notes, so students have the outline of what we're covering, but I leave a lot of blank space that I try to fill in collaboratively with the class. However, I always have the main points jotted down on my notes, so I make sure to cover the things I want to cover. After class, when I discover errors or things that didn't go well, I either fix the notes then and there or leave myself notes for next time. In either case, my notes and lectures are constantly evolving and changing.

So, how does that kind of preparation translate into my current situation? First, taking last year's notes, updating them, and then preparing the audio track requires at least a factor of two more time, perhaps even more now that I'm thinking deeply about it. Applying the same fixes I would have applied were I teaching conventionally takes about the same amount of time it would have. But then I start recording audio tracks. In my case, I'm using discrete audio files per slide, attaching them to the powerpoint, and then converting that powerpoint deck to a movie. The logistics of all this are tedious and take time, but that's not interesting (e.g., the PPTX->movie conversion really only works well using software that runs only on Windows; it produces enormous files, which I then translate using a different tool; these large files get moved around, etc).

The more interesting is what goes into preparing the audio bits. Since students will be listening to these on their own, they don't have the opportunity to interrupt and ask clarifying questions. We do have an interactive message board, and the students are taking good advantage of it, and the TFs and I are working hard to be responsive, but it's not the same as saying, "Excuse me, I didn't understand that." OK, few students ever actually say that in class, but when you can see them, you can frequently figure out that they are thinking that. In lieu of that, I think very carefully about what I want to say, how I want to say it, and then I record. I'd say right now about one in three times I am happy with my first take. One in three times I need a second take. One in three times I do many, many takes. So far, the videos have mostly come in around 30 minutes, so we're talking a couple of hours when you add in recording with incorporating the audio track, setting options, fixing things, etc.

But once I've completed the audio track, then I can really begin. Next I think about what I want them to take away from the video and I translate that into pre-class work. I think I am posing somewhat more challenging pre-class questions than one normally associates with this task, because I use those results to help me identify what issues are really confusing people. (I spend an hour or two in the morning before lecture reviewing answers, analyzing responses to the various questions, discussing them with my staff, and figuring out whether I want to a) simply post answers, b) go over problems in class, or c) do nothing.) In any case, I spend somewhere between 30 and 60 minutes thinking about and writing pre-class work.

Then I begin working on the in-class component. In our case, this involves writing code. Writing code always (always, always) takes longer than you expect. Testing is key. However, since my pedagogical thinking evolves as I am working through the assignment, sometimes I don't always use the practices. This brings me to item two on today's list.

When Disaster Happens

We had no fewer than four different types of disasters happen all in the span of a single 90 minute class (of which 30 minutes was consumed discussing pre-class work). There are many things to learn from this experience, so I'll walk you through what happened in potentially gory detail.

1. Pre-class work

It turns out that unless students were clairvoyant and could read my mind, there was much ambiguity in the questions as I wrote them. Both TF feedback and the analyzed data supported that claim. So I took the first 30 minutes of class to go through the questions and discuss the different interpretations and how those interpretations led to different answers. My assessment is that while it didn't feel good to be me, the end result was actually pedagogically constructive. We ended up talking about a number of important concepts and assumptions as a group, and I think we raised issues that, in past years, never surface, are never addressed, and manifest in difficult-to-debug code later in the semester. It will be difficult to do any kind of hard empirical analysis of this (although if people have ideas, I'm all ears), but my sense is that we had a deeper discussion about synchronization than typically happens.

2. Preparing for in-class work

After that, we turned to the class work. I had prepared the exercises as a separate branch, with the intention that they could play with it in class, and it would not in any way interfere with their own work, and afterwards they could either keep it or toss it without any effect. Great idea in theory. In practice, due to a combination of miscommunication, my own experience with the particular source code control system we're using (there were good reasons to change, but it's not one I've used extensively), and pretesting the process on a tree that was not identical to what the student's had, we ended up having them execute a command that, well, um, kind of messed up their tree.

3. Dealing with the in-class disaster, or "Another Disaster in the Making"

When then insued was sheer insanity. Over the course of the next 15 minutes, we frantically proposed multiple different ways of fixing people's trees. The TFs, students, everyone had an opinion, and we kept posting them. This was just dumb. We should have stayed calm, figured it out, and then dealt with it. But no, we freaked out -- all of us!

Finally, I went around the room and checked on every person to make sure that they had a working tree. That seemed like a good idea. Hoewver, then the fun really began.

4. The Crowning Touch

As they started working on the problems, they discovered truly, horrifically idiotic bugs in the code. How did that happen? I really tested things. I really did. Honest.

Ah yes, I'd done a couple of those last minute, "Hey -- this will make things easier to debug!" fixes and of course did not rerun the tests. That will teach me. Class ended with me feeling like I'd wasted a lot of truly valuable time and the students probably wondering what on earth they'd signed up for.

Transparency

So what do you do after a class like that? Well, I tried really hard to do better on Thursday. Although I did forget to have people put their names on the pre-class work, I didn't make any monumental errors. I did however, address the situation head one. This is what appeared at the beginning of Thursday's work:

First, let me start out with an apology -- we did not use your time efficiently on Tuesday, and that's a violation of the "contract" I made. I hope you all believe it certainly wasn't my intention, but that doesn't excuse it. I must, and will, do better. There are a number of ways in which things went badly, and rather than focusing on what they all were, I'd like to focus on how to avoid them. Thanks to Carl, we have a nice simple mechanism in place to help us prevent git shenanigans. Please refer to the Piazza posting. All that said, one takeaway is that at some point in the semester, if you find yourself in the midst of a git disaster (e.g., you and your partner cannot figure out how to resolve conflicts, get each other's changes in exactly the place and way you want them, etc), don't panic. There are ways out. Stay calm, learn to read git commit logs so you can figure out where things have gone astray and patiently try to fix them (we did not demonstrate the "patiently" part yesterday -- we frantically tried N fixes in a course of N-1 minutes trying to muscle through it; not a good strategy). So, as promised, today's exercise is simply to finish what we started Tuesday, ideally with significantly less drama!

I also tried to use the experience as a teaching moment, even if it was at my expense, so I also wrote:

There was another bone-headed error that got in here -- I will explain how this happened, just as a warning about "last minute changes." I had completed the problem, implemented a solution, tested it, and was happy. I then removed the synchronization to commit. "But wait!", I thought, "It's too difficult to debug, because there was no way to determine which TF is handling which student's question. The printout simply isn't helpful enough. I'll add a tf array so I can print out a TF number and that will be easier to debug." So I tossed it in the TF array at the last minute, and (here's the boneheaded part) did not rerun all my tests. So, take this as, "Don't do that!" No matter how minor the change you think you're making is, you have to rerun your tests. Especially if you're tired, that "simple" fix is undoubtedly wrong in at least three ways. Mea culpa. This was the second patch (semprob2.patch ) sent via email. Apply that patch too.

The Conclusion

So after all that, how did Thursday go? Remarkably well. The students seemed to accept my direct apology and commitment to do better. Perhaps some of them will chime in on their perspective (perhaps not; the one who are really upset will wait until the semester is over, and I understand that). And, by the end of class, all the students were animatedly and happily chatting about whale-mating. It was good to hear!

Next: Not Flipping Out (February 16, 2013)

CS161: One Woman's Adventure with a Flipped Classroom

For many years I have wanted to make my operating systems course, CS161, more interactive. I try very hard to engage students in the classroom, but let's be honest -- when they have been up all night trying to get their operating system to spawn processes, they just aren't really up to talking much in class. And when they do, it's the same set of characters and it's difficult to figure out if the rest of the class is really following along or is totally lost. At the same time, we know some typical student behavior that makes the course more difficult than it needs to be. Shockingly, even though we give students three weeks to complete assignments, they leave 99% of the work until the last week (day). That makes for a rather painful semester. Similarly, we ask them to write design documents, but many sit down to write them the night before without fully understanding what they are trying to do. And when we ask them to read the code and answer questions, they tend to gloss over most of the code and whip off quick answers.

I've always been tempted to try some newer classroom techniques, such as Peer Instruction and Flipped Classroom. I've just always been a bit afraid of balancing the potential for deriving greater benefit from class time versus dumping too much work on them.

So this year I took the plunge. I decided that I would flip the classroom for the first two to three weeks, return to a more conventional classroom while the students are deep in the most challenging programming assignments, but flip at key times, when I believe that there is real value to doing so.

I decided that I wanted to blog about this to record my observations, but also to invite students to chime in if they are so inclined. I also welcome comments from alums of the course or other others with concrete experience with related activities.

I am now one week into the semester, so we've done this for two classes. So far, I am wildly enthusiastic. It's scary, but it seems that we've already observed some tangible benefit (unfortunately, I do not have a good way to quantify/evaluate this).

Day 1

Historically I try to do a class-wide exercise where I draw the POSIX API or the programmer view at the top of a page and the reality of the hardware at the bottom and together we fill in what has to happen in between. My goal is to help students understand what the operating system must do and what they will be building over the course of the rest of the semester. As per many class exercises, a few students dominate such discussions.

So, this year I presented about 20 minutes of overview -- what the course was about, what I expected of them, what I promised in return, and then I turned them loose on three instances of the design problem (corresponding to the three main programming assignments). The TFs and I then wandered about the room, checking in, asking them questions, and helping out when necessary.

I quickly identified group(s) that were confused and were having difficult getting started. As other groups were happily making progress, and there were TFs talking with other groups, I was able to devote a significant and focused amount of time working with the groups that needed or wanted my attention. Instead of spreading attention around a class, dominated by the most confident and extroverted, I could provide focused attention where it could do the most good. Different groups addressed questions at different levels of detail, and that was OK. When I heard groups say things like, "You need page tables here," I stopped them and asked, "But what is a page table?" I wanted to force them to think through words they may have heard and make sure they really understood what had to happen.

After they worked for 30-40 minutes, I brought the class back together again and had groups present what they'd done, building upon each other, with my translating to some extent. I also assured them that we didn't expect them to complete this exercise perfectly -- after all, if they already knew how to do it, they'd have little use for the rest of the semester.

To me, it felt pretty good. The only tangible data I have is that a few students, who started off saying that they weren't really planning on taking the course because there were three other CS courses meeting at the same time, signed up. Pre-term planning number pegged the course at 37; we had about 60 students the first day; 47 registered. This is larger than the course has been in 15 years! And, it's important to realize that 15 years ago, there were no other undergraduate systems courses to speak of, so choices were significantly more limited.

Day 2

I took the material that I usually cover the first week and turned it into two videos (all the materials I'm talking about are linked from our syllabus here). For pre-class work, I had them do part of what we ask them to do for the first assignment -- get their work environment set up. Then, we spent class time letting them configure and build kernels for the first time. A few people ran into difficulty, and this was the beauty of doing it in class -- we could help them right then and there, making sure that they weren't stuck. So, within 10-15 minutes, every single student had configured and built a kernel. How great is that?

Next, we let them start answering code-reading questions (typically included as part of the first assignment as well), encouraging them to discuss the trickier ones amongst those at their table. Here is the thinking: most student spend little time actually reading the code, and when they do read it, if they are confused, there isn't much they can do except post a question (always a bit scary), email a TF, call a friend, beat their heads against the wall. However, by having them start in class, they had friends right there to work through the code with them. Some groups worked pretty independently, other groups worked completely together (two people in front of one terminal), others did a combination. Once again, the TFs and I circulated, answering questions, asking questions, encouraging discussion, etc.

They are each supposed to write up the answers to the questions to turn in, but they should have made significant progress on the assignment already.

On to week two!

Next: Flipped Again (February 7, 2013)

Gender and Swag

Each year when the Grace Hopper Conference happens, there is the inevitable discussion about the swag (the freebies in registration packets) given out. I have to confess that the first year I heard that companies gave out nail polish and "girlie" things, I was totally offended, but that was before I attended Grace Hopper. After attending, my whole attitude changed. Engaging in this year's debate made me stop and think a bit more about the phenomenon.

The high order message is that if you have not been to Grace Hopper, talked with the attendees, and experienced the event, you cannot even begin to comprehend it, so commenting on the appropriateness or inappropriateness of some of the details is risky.

This year, those not in attendance found it "offensive" that some of the swag included nail polish, a sewing kit, and a whistle. What I found interesting about these three particular selections is that those discussing them felt that they were sending a message that "you should look pretty," "sewing is for girls," and "if you don't carry a whistle, you'll be raped." I found these comments fascinating, because in at least two of the cases, my reaction was totally different. A whistle? Great -- I just had to buy half-dozen of those, because my son and I use them to referee soccer. And a sewing kit? Excellent -- I always scoop those from hotels so that I can fix a button or have a safety pin when necessary. Neither of these felt "girlie" to me -- they are items used by both genders in my household. Nail polish? Not my thing, but if it were clear, it would be way high on my list of handy things around the house.

I started thinking about some of the other swag I'd gotten at Grace Hopper in the past: I still use my NetApp manicure set (it lives in my office and I've had both men and women borrow the nail clipper), NetApp lip gloss -- a bit shiny for my taste, but still useful in dry climates. Girlie? Not really. A large nail file -- don't recall who gave those out, but it got used by everyone in our house. A collection of highlighters, tape measures, small toolkits, etc -- one from NSA, one from ACM. Love them all.

But let's imagine for a moment that I did think some of these items were targeting me as a woman, how would I feel? I thought about this long and hard and I realized that it's actually a feature not a bug. The thought process goes like this.

If you are purchasing swag for Grace Hopper, you know something about your attendees -- they are women. Why not put things in the bag that you think they might like? You needn't limit yourselves only to things that have to do with technology. After all, the most common conference giveaway is a T-shirt. Last I checked, that had nothing to do with technology, it was clothing. People asked, "What message are these companies sending?" I think the message they are sending is, "We know you are women and we're happy to put our name/logo on items that might appeal to you, because we value you."

Let's contrast that with the message sent when you give me a men's T-shirt. To me it says, "Hey -- here's a piece of clothing that isn't going to fit you well, but you are such a minority that it isn't worth my time to get a woman's shirt." Yeah, it really feels that way. When we ran Sleepycat and bought polo shirts, from day one we asked people to request a size and gendered shirt. Guess what -- not a single woman ever requested a men's shirt. Not ever. Our little company of 25 could afford both the time and cost (which was 0) of ordering both men's and women's shirts, but fortune 500 companies can't?

I still recall a conversation with a company, who I will politely not name. It went something like this:

• University relations person: Can you help us recruit women? We get so few women applying for engineering positions.
• Me: Is that a men's polo shirt you're wearing? (Said person was female and wearing a university relations polo shirt.)
• URP: Yes.
• Me: What kind of message do you think that sends? I think it says that your company has so little respect for its female employees that you make them wear men's clothing as a uniform. I think that sends a message that most women don't find attractive.
• URP: Well, there are so few of us that it would cost more to order both men's and women's shirts. [Note: I don't know about all vendors, but when I order logo wear from Land's End, they do not charge me based on the gender of the shirts, they charge me based on the total number of shirts.]
• Me: Are you really telling me that can't afford to buy women's shirts?
• URP: Silence.

To the best of my knowledge, said company still makes its women in University Relations wear men's polo shirts.

I can hear you, "Is this really what we should be worried about? Women can and do wear men's T-shirts all the time." Yes, we do. But why? Because historically, T-shirts were men's clothing and it took decades for manufacturers to realize that your standard men's T-shirt is about as flattering to a woman as a burlap bag. Yes, I do like baggy T-shirts to sleep in and to wear to the gym, but these are probably not the most effective locations to give visibility of the T-shirt's message to the rest of the world (I work out alone in my basement 99% of the time). But if I were getting dressed to attend a function, even if it were casual, I would not wear a baggy men's T-shirt. I might, in fact, wear a women's T-shirt.

Then I got thinking more about that nail polish. OK, I don't wear nail polish (those of you who've seen my nails will immediately understand why). But wait, I am one of those women who already feels comfortable in this field. Maybe part of being a women in CS is that you don't (or can't) like nail polish or want to wear it. Maybe, the idea here is that we need to tell women that even if you do like nail polish, this field is for you. Yes! That's the part that everyone seems to miss -- outreach is designed to help those who see our field and think it isn't for them reconsider. So when companies put their names and logos on products that appeal to the women who are not present in our community, maybe, just maybe, it should be viewed as an invitation to those women. "C'mon. We're not so bad. You really can be the person you want to be and still feel comfortable in this field."

It reminds me a lot of clothing. I frequently wear dresses and skirts (yes, you may all gasp now). This is actually a conscious decision on my part. It's not that I like dresses all that much (although I've grown fond of them over time) -- it's my little message to young women out there. It's supposed to say, "Yes, you can be a girl and an engineer! You don't have to look like and dress like the guys." Now, it's certainly OK to dress casually, but that message already comes across loud and clear. The other message does not. So, that's where I come in. I have no idea if it matters or not, but I do recall a young woman telling me that a male colleague at her first job after school told her that, "She dressed too nice." (She was a tech consultant who liked to wear skirts.) If she'd never seen me wearing a dress/skirt, would she have spoken with me about it? I don't know, but I told her that as long as she was dressed professionally, her colleague was way out of line -- looking nice and/or caring about your appearance is not a crime.

So, no, I do not find it offensive that when companies put things in a bag for women at an event for women that they select items they think might appeal to some women, who we don't frequently find in our community. Nor does it offend me that one of the most popular social events at Grace Hopper is a dance party. And guess what -- a lot of people attend. Attendees describe it as one of the best parts of the conference or one of the things they most look forward to. I'm going to guess that the typical conference attendee from the conferences I attend would have a very different reaction to a dance party.

Let's try another thought experiment. What would a typical attendee at OSDI (or your favorite systems conference) think if a company handed out skirts instead of T-shirts? I'm guessing most people would think it ridiculous. And if you think it's ridiculous, but T-shirts are OK, then you're saying it's OK to give out swag specifically designed for one gender, but not OK to give out swag specifically designed for the other. And you might rationalize it and say, "Yeah, but skirts are appropriate for so few attendees ..." And then you'd be sending the message that those very attendees don't matter.

Stranger in a Strange Land: An Engineer at the B-School

I am an engineer. I like problem solving; I like to build things. I can also read financial statements and understand terms such as ROI (return on investment), EBITDA (earning before interest, tax, depreciation, and amortization), and break-even analysis. So, when offered a chance to co-teach at Harvard Business School, I leapt at the opportunity.

I was nervous at first. After all, I'd heard all about "the case-based method" and knew that HBS offered its new faculty courses on how to teach this way. I figured it involved many secret handshakes, implicit knowledge and many other mysteries that we in engineering had never seen. Alas, just a few weeks into the semester, I no longer feel like a stranger in a strange land -- there is much at the B-school that is familiar, but also much that is different, and perhaps, worthy of importing into SEAS.

Let's start with the similarities. It turns out that teaching via the case-based method is really quite similar to teaching a paper-based graduate seminar. The students are expected to read the cases (papers) before class, and class is an interactive discussion about the subtleties of the case (paper). In my classes, the story is frequently in the graphs and tables, known as the experimental results. In cases, the story is in the financial statements and market research. Is the company making a profit? (Does the suggested technique improve performance?) Where do they make their money? (Which part of the design is responsible for the improvement?) How well does the business align with existing forces? (How practical is the proposed solution?) And as we see on the engineering side of the river, there are frequently no right answers. Smart people can hold different opinions and interpretations. But, in both places, the intellectual content and the quality of the discussion relies on deep, technical analysis.

Conclusion? Intellectually, there are more commonalities than differences between my two current homes.

Culturally, however, there are differences. Now, before I start, let me disclose that I am doing a very bad thing here: I am generalizing from a single data point, that of the class of my esteemed colleague Regina Herzlinger. However, one of the case writers, who had been at the school for four years, assured me that these features were universal. Now that we've had full disclosure, let's move on to those differences.

The first thing you notice entering a classroom at the B-school are the laminated name cards. Each person has one and the tables are constructed so that you can easily display your name tag. This means that the faculty learn their students' names and the students know each other too. Our class attracts students from many other Harvard schools (the Kennedy School of Government, the Medical School, The School of Public Health, etc). Once everyone has a name tag, boundaries disappear, and the group becomes an entity of its own. The students own their nametags and bring them to each class. If someone forgets one, you'll often see them creating a makeshift one. I confess that I noticed this at a few events I attended at HBS several years ago, and I've been doing it in my classes ever since. However, since it's not part of the culture, I end up owning the nametags and bringing them each day. And after a few weeks in a small course, I typically know everyone and nametag usage drops off. But, what would it be like if we totally changed the culture in engineering and everyone did this and students had nametags for all their classes? Could we change the culture in the entire college????

The next thing you might notice at the business school is that at the beginning of each lecture, the professor will introduce guests. Guests might be friends accompanying students (which means that the students have checked with the professor and told him/her that they are bringing someone to class), executives from the companies being discussed in the day's cases, and the case writer (the research analyst who wrote the case). When guests are introduced, there is applause. It's a lovely way to make the guests feel part of the group as opposed to uncomfortable outsiders.

Then class begins. If you look around the room, you will be hard-pressed to see a laptop. Instead, you see people's faces. The students are paying attention to the discussion. No one is reading email, cruising facebook, or even checking their smart phones. What a difference from your typical college or engineering course (or faculty meeting -- I wonder what those are like here). When the professor solicits input, while there may be initial silence, within five or ten minutes, half the class are raising hands to offer their perspectives on the case. Cold-calling is OK, but is often unnecessary. Sometimes students give answers that aren't quite right, but you'd never know it. There is little direct attack although there are polite suggestions of alternatives. It's also both comforting and disconcerting to see someone else use the same tactics I use when discussing research papers. "Do you agree with him/her?" "Is there anything else you noticed?" However, there is significantly less "pulling of teeth" to get people to engage, and even though there are about 75 students in the class, it seems like all of them participate in meaningful ways. It's quite impressive.

I am also pleasantly surprised to see how often conversations around ethics come up. One of the ways that we evaluate ventures in this class is through a framework that includes the phrase, "Do good, do well." The message, oft repeated, is that only businesses that are genuinely doing good for the world are viable. A business that makes money, but doesn't actually deliver on the public good front is voted off the island.

In a similar vein, current events are sometimes part of the class. In one case, the day after we discussed it, the former CEO of the company was indicted for allegedly receiving kickbacks. This led to a discussion about ethics and came back to details in the case that hadn't quite made sense. The message? Pay attention to details. Do your due diligence. Don't enter into arrangements if something doesn't seem quite right. In other words, if something seems too good to be true, it probably is.

The last thing I'll comment on may be pecuiliar to this course -- after all, we're not talking about innovation in general, we're talking about innovating in health care. It's possible that healthcare attracts a different type of person. I've met with many students in the class, usually to discuss the business plans they are developing for this course. They are a sincere, passionate bunch, who are looking for a way to make a difference; not a way to make a buck, but a way to make the world a better place. Their backgrounds are as varied as their business plans, but each one has done something interesting since graduating from college and is determined to do something both interesting and good.

The business school is a quite wonderful place; I'm grateful to feel less like a stranger there now.

One Woman's Culinary Adventures

Ever since my son became gluten and casein insensitive three and a half years ago, I've pretty much cooked without gluten and dairy (except for the periodic bread-baking for my daughter -- if you'd like a lovely sourdough starter, holler!). On top of that, I love belonging to a CSA (community supported agriculture) and I take it as a personal challenge to use all the lovely produce I get each week from lindentree farm. If I can't, I feel that I've somehow failed. So you can think of each week as a series of iron chef episodes featuring a different vegetable.

Over the years, I've learned to use up weekly bunches of kale, even kohlrabi (I'll get to those in a later blog entry), and a wide variety of common and uncommon greens, but I've never really come to terms with parsley. Nearly every place you look, the way to consume lots of parsley is to make tabouli, but that requires bulgur wheat and that's a non-starter in a gluten-free household. Last year I tried gremolata, but truth be told, I was the only one willing to try it and I didn't really care for it very much. In a pinch, you can clean and freeze parsley and use it thoughout the year. However, as an indication of how much parsley we eat over the course of a year, I've still got frozen parsley from last summer.

So, this year, I set out to make a parsley-full salad -- something resembling tabouli, but edible by everyone in my household. I call this gluten-free tabouli (the recipes I found online for this vary in their ingredients, from cauliflower to soy granules to gluten-free textured vegetable protein, none of which really appealed to me).

Ingredients:

• 1/2 cup millet
  
• 1/2 cup quinoa
  
• 1 cup water
  
• 1 cup orange juice
  
• 2 large tomatos
  
• as much chopped parsley as you'd like
  
• 3-4 scallions or some chopped onion (or as much as you'd like)
  

Cook the grains in the water and OJ (rinse grains first then add liquid, bring to a boil, reduce heat to low and simmer 20 minutes). Chop the parsley, onions and tomatos. Mix everything together and add salt and pepper to taste. I'm sure that tabouli bigots everywhere will stick their noses up at this, but I think it's pretty good and it uses up a fair bit of parsley.

Stay tuned for an upcoming edition when I write about 101 ways to use up a prolific summer squash garden.