So you have a new research question. You’re reading a paper, or a book, or a news article, and a hypothesis forms in your head. Or you have a new idea for resolving an important conundrum in your research.

What do you do?

In startup and business culture (or certain segments of it, at least), there is the concept of the minimum viable product. This is basically the smallest version of a product, stripped down to its barest essentials, to see whether it would gain traction in the market. Create a minimal product and iterate quickly instead of spending a year building something that might not take off.

I think this concept is instructional for research. Minimum viable research would be to ask yourself: what is the simplest thing I can test to see if this idea might go somewhere? Rather than spending a week doing data analysis, is there a 1—2 hour way to see if it might work, or if it is trivially falsifiable? Can you structure your research inquiry so as to fail fast, to not spend excessive time trying to fit a model that just won’t work?

Patrick Volkerding released Slackware 14.1 yesterday. Yep, Slackware is still alive and kicking.

Many years ago, I first encountered Slackware. I was in junior high, and had been using some GNU tools on Windows via DJGPP, but I read about ‘GNOME’ and wanted wanted to try this Linux thing. So I convinced my dad to let me install LoopLinux on the family computer (a 120 MHz Pentium from Gateway 2000).

LoopLinux was a Linux system that ran from a single file on your DOS or Windows filesystem. The installed system consisted of the filesystem file, kernel, initrd, and LOADLIN; it would boot the kernel, mount the DOS filesystem, and mount the Linux system as a loopback filesystem. Once installed, LoopLinux used Slackware packages.

We only had dialup at the time. I stayed up all night the night I downloaded LoopLinux; I’d sleep for an hour or two on the living room couch, then wake up and go check the downloads and see if I needed to start another of the files downloading.

From Twitter this morning: writing tips for academics. Prof. Feamster’s advice in that column is excellent. I would just like to add one thing that I have found very helpful in my own writing: think about what the paper — and each section of it — need to accomplish.

Software engineers are familiar with the concept of requirements: when designing a program, it is important to understand what its users require it to do. If you do not know what the program is supposed to do, and how it relates to the things around it, it is difficult to write a good program. Indeed, it is difficult to even know what a good program would be.

I apply a similar idea to my writing. There are many times when I do not necessarily think about it explicitly. But when I get stuck on a section of a paper, I often find it helpful to think about what that section is supposed to accomplish. I even think about it like a software module: its prerequisites or dependencies (i.e. the things it assumes previous sections have stated or set up) and its outputs (the things later sections will assume it will have done). If I spend 5 minutes writing down what the section has to say, it is often easy to finish drafting the section.

I personally find this more useful than deep outlining. Many people like to outline down to the paragraph level, writing out their paragraph topic sentences. This is good advice, and likely helpful to many writers. But for my own writing, I have difficulty thinking in that way. I find it more useful to outline the sections and subsections of my paper, and then start thinking about each section’s requirements. Sometimes, these requirements may turn directly into paragraphs; other times, they may be merged or split or interwoven. But they’re still useful, and they give me something concrete to think about as I go to implement the ideas with prose.

Those of you in the Introduction to Recommender Systems MOOC may have noticed that I am always in a blue button-up shirt. You may or may not be asking ‘does he have any other shirts?’

I do. I primarily wear the blue shirt in the studio because the video producers have advised us against wearing white (the lights reflect off of white shirts to create a disturbingly angelic glow).

If you’re around GroupLens, or the CS department, you may have noticed that I am (almost) always in a white button-up shirt. You may have asked ‘does he have any other shirts?’, unless you are also in the MOOC, in which case you know I at least have a blue shirt.

Several months (or perhaps a year) ago, Jennifer and I embarked on a plan to standardize my wardrobe. We see minimalism as a useful tool for living the kind of life we want, and a number of minimalist writers we have read have a standard outfit. Also, deciding what to wear in the morning is a pretty low priority with respect to the rest of what I have to do, resulting in wasted decisional energy.¹

If data matters, as it does to most of us computer scientists, protecting it is important. Prompted by Greg Grossmeier’s search for encryption best practices (see also his synthesized advice), I thought I’d document some of the things I do to protect my data.

There are two principal threats I consider here:

Loss

I need to be able to keep my data, even if my computer or other storage media is lost, broken, or stolen. Backups are the principle means of protecting against loss.

Misuse

I’d really rather not have my data used if it falls into the wrong hands (e.g. my laptop gets stolen). Aside from general paranoia reasons, I have financial records, class assignment solutions, and things like that on my hard drives that shouldn’t really see the light of day without my authorization.