Shriram Krishnamurthi at Brown wrote today about his pivot into CS education research. I found the whole article fascinating to read, but found this paragraph at the end intriguing as I am thinking about my research agenda over the next few years:

When I became a professor, I decided it would be good to take on “five-year plans”: pick a topic and work with it for about five years (with a trailing year or two to disseminate results). That’s long enough to really get into its guts, understand it at depth, make real contributions, but also not become stale. (And most of all, not become too attached to my insider status, which would breed conservatively sticking to it and cranking out papers with rapidly diminishing returns.) I’ve done that now on five projects, and it’s worked well for me. This would be my sixth five-year project. In some ways, this is the most terrifying one because it’s the one I’m least prepared for: when I read @markguzdial’s writings, I feel I’m not just a novice, I’m trying to reach a different planet. But I’ve muddled through before, and I’m excited to try doing so again.

We talk about 5-year plans a lot in academia; forming one is common advice to new faculty. But I think this is the first time that I have seen the suggestion of thinking of a career as a sequence of 5-year plans that don’t necessarily all focus on the same agenda.

I’ll be thinking about this as I work on my 5-year plan.

I’m looking forward to going back to RecSys this year, reconnecting with old colleagues and meeting some new ones.

I also am involved with a couple of papers this year and will be presenting one, as well as serving as publicity co-chair.

IN RE the Jello Research Challenge:

Sometimes people need directions when making jello.

But there are so many ways to prepare jello, and different directions for different dishes.

What if your dishes could track what you’ve done with them and use that information to help you find more relevant jello instructions?

In my previous post, I mentioned that we’re using Jupyter notebooks for a lot of our data analysis, even in R.

This post is a quick ‘howto’ for doing such analyses on remote compute severs (in the university data center, Amazon or Azure clouds, or whatever).

During my two years at Texas State, I’ve been engaged in a bit of an experiment on statistics & data analysis tools. Some of my graduate students have been using R for data analysis, but some have been working with the PyData stack. I’ve also been learning PyData, doing some new analysis or data processing in it and trying to convert a few old analyses.

I learned R in grad school, and used it throughout my Ph.D work. My R style dramatically changed over time, as I learned ggplot2, then data.table, and finally plyr and dplyr. I’d like to think that I’ve become fairly proficient at R. I even like the language.

But Python is a far more usable general-purpose language. If we can do the things that we currently need from R, in a reasonable fashion, then using it decreases the number of different things that students need to master to contribute to research. There are a few things it just can’t do yet — I have yet to find a structural equation modeling package for Python — but the core capability is there for most of what we do.