This semester I designed and deployed a new course on the internet in a flipped format. Despite nominally being a seminar, the course enrolled 440 students and met in two large groups. To pull this off, we had to overcome many challenges—some that were anticipated, others that caught us by surprise 1. Overall the course was a lot of fun. Here’s my attempt to share a bit of what we learned along the way.
This is the first part of a planned three-part series. Part one focuses on the infrastructure and management challenges of flipping a large course. Part two will discuss activity design and deployment. Part three will describe the video delivery system we built. Read more…
At the extremes, there are two ways to approach tenure. You can conform to the norms established for junior faculty. Or you can be yourself. I’m happy that I set my own course, and proud of the way that I divided my time between research, teaching, and service.
I was fortunate to spend last Thursday and Friday at Google participating in the Google Mobile Faculty Summit. It was my first trip to the Googleplex and I came away impressed both with the work that Googlers are doing and with the obvious contributions the research community has made to these new mobile technologies. In more than a few cases, talented Googlers are doing the other 99% of the work required to bring promising ideas contributed by the research community to fruition. Here’s a write-up that hopefully conveys my excitement without violating the NDA that I didn’t sign…
TL;DR: if you know what university overheads are, are an academic computer scientist in the U.S., and want to take the overhead survey to facilitate a meaningful comparison between different universities, the link is here. Otherwise, if you want an introduction to the arcane word of university finances—or just to enjoy an inquiry into the same—read on.
Bring a few faculty members together, and the topic of research funding usually comes up. And when the topic of research funding comes up, the topic of university overheads 1 frequently comes up. In my experience, this is something that faculty like to complain about, and a part of the challenge to funding university research that makes us look enviously at our colleagues at industry research labs. But I also think that there’s a lot to complain about, so let me try to hit the low points.
Recently I’ve been considering two important challenges to university computer science education. The first is how to deal with rising enrollments. The second is how to improve diversity within CS. As a result of thinking about both of these goals, I’ve realized that they are linked in a way that has important consequences—particularly for efforts to improve diversity. Put simply, improving diversity in computer science requires universities both grow their undergraduate programs and disproportionately attract underrepresented students. And the fact that improving diversity is coupled to growth can make things more challenging for many departments that are struggling to grow—including mine. Click here to read more about this connection and its implications.
I’ve been trying recently 1 to avoid serving on technical program committees, particularly for conferences in sensor networking—an area I’m no longer working in. But when I received the invitation to review papers for RealWSN, I was intrigued. After carrying out my own personal experiment with reverse-blind reviewing for the past few years, this was the first time I have observed an entire workshop giving this approach a try. Maybe reverse-blind reviewing is about to go mainstream—and if so, it’s about time.
Many congratulations to Romit Roy Choudhury, the 2015 recipient of the SIGMOBILE RockStar Award 1. This award is relatively-recent but has a strong history, having previously been given to Lin Zhong (2014) and Suman Banerjee (2013). It’s great for the SIGMOBILE community to recognize early career success (although all recipients were tenured by the time they received it), but the award has a terrible name. Let’s change it!
A few months ago Eyal de Lara approached me about editing a column for the SIGMOBILE GetMobile magazine, which is replacing a previous incarnation known as the Mobile Computing and Communications Review (MC2R) 1. I considered the offer for as long as I was able, because there were two very good reasons to say no. First, I don’t need anything else to do. Second, I don’t need anything else to read—at least not about mobile systems. I’ve heard that concern echoed by others who, like me, take their work-related magazines 2 on the shortest-path trip from mail slot to recycle bin. But in the end I did end up agreeing to edit a new column. Given that the main goal of this post is to convince some of you to contribute to this new endeavor, let me try to explain why.
(Or how I’ve learned to stop programming (mostly) and embrace being a sometimes designer, sometimes manager, sometimes pep talk deliverer.)
In the fall of 2009, as I was preparing to graduate, I went on a series of self-funded university visits 1, each consisting of a talk and multiple one-on-one meetings with faculty members. While I had previously met many faculty at conferences, this was the first time that I had encountered them in their more natural setting—in their labs and offices, teaching and working with their graduate students. And so it was the first time that I was exposed to what I now hear fairly regularly, with varying degrees of regret and resignation, particularly from colleagues working in computer systems and networking: "I wish I had more time to write code. I’m just a manager now."
I really liked to program, to build things, to hack. (And still do.) I was also interested in becoming a professor. But I didn’t interpret those complaints from systems faculty as a warning about my own prospective career path. Instead, I remember feeling annoyed. "You knew what you were getting in to", I thought. "Do your job 2." I had an advisor who liked to try to help out with our projects, and it didn’t always work out well. As a student, finding bugs in your advisor’s code was naturally a bit nerve wracking, and at times his internal programmer would cause him to exercise an unhelpful amount of low-level control over the code that his students were ultimately responsible for writing and maintaining.
I’m remembering these feelings now, having recently gone through the transition from programmer to manager myself—my pivot, as the industry jargon goes. Like others before me, I’m finding leaving my development role behind both frightening and disorienting. But I think it’s a good thing for my group, and so I’m trying to adapt to my new role. Here’s the full story.