I had the great pleasure to visit my extended family in the Philippines over Christmastime last year, after more than a decade since my last trip out there. During a rare moment when I wasn’t either stuffing my face with amazing food or chatting up one of my dozens of cousins, I was amused to hear that some thought I’d been working as a professor at Harvard. That’s hilariously flattering, but I’ll have to disappoint those relatives by setting things straight and saying no, I’m not that ambitious (or “wicked smaht,” as they say in Boston). Still, although I have no Harvard plans at all, I am in the very fortunate position to conduct research professionally alongside a team of very sharp and accomplished colleagues.

My business card says that I’m a research software engineer at Dude Research*, a small applied R&D group inside a major technology company. Unlike most of the organization, we don’t directly work on products and services meant to hit the market soon. Instead, we explore emerging new ideas that could be of great value to the company five, ten, or more years down the line. My focus area is usable security, specifically on protecting mobile devices without requiring the user to do anything special or even be aware of it.

So what the heck is a “research software engineer” exactly? It depends heavily on the organization’s mission. In one of the other labs where I interviewed, the job was to aid their research in fungus genetics by writing software to manage and analyze gigantic biological data sets (apparently fungi are really complicated!). This is more on the “support” side of things, where the research software engineer builds specialized tools that scientists need for their investigations — usually in disciplines that don’t explicitly overlap with computer science. Some background knowledge of the research domain is necessary, but that isn’t the biggest concern for the software engineer in this environment.

On the other hand, I have a “hybrid” role as both a programmer and an investigator at Dude Research. This is because my experience in building and testing systems lines up pretty nicely with the domain the company occupies. I often switch between the two roles in a fluid and complementary way; one moment I might be reading through academic papers to identify which ideas aren’t fully fleshed out yet, the next I could be implementing a new feature to try things out, then finally I’m parsing through the results of my automated experiments to figure out the next move. The job can be summed up simply as “explore, build, test, document, repeat.”

It’s also “hybrid” in that it combines some of the best perks of academia and industry: I enjoy near-total control over how my work is carried out, while being backed by the generous resources and stability of a major company. When I first began developing the rough proof-of-concept for the system the company wants, no one dictated how they wanted this to happen, other than just “get it done.” Team meetings and funding worries are not part of my day. My attention is almost entirely put towards working out new ideas, with the ultimate goal of sharing results with the research community, securing patents for the company, and proposing new products built on our research findings.

This sounds like a pretty attractive spot, and I think it really is. How can someone interested become a research software engineer? Based on what I see in my group, there are generally two paths in: either as an entry-level job for newly-minted PhDs, or as an advancement opportunity for people with experience rigorously developing and testing concepts in software. My colleagues around my age (late 20s) and all our interns are in the first group; they recently completed their doctoral studies or are slated to finish soon. However, I fall into the second group myself. I never pursued a PhD, though I do have documented research experience from completing a Masters. My previous job was developing highly realistic naval systems simulations at APE-LAB, where I was lucky to be assigned to a team that taught me great practical software engineering methods. Off hours, I dabbled in a couple side projects, like an Arduino-based Bluetooth door unlocker and a security review of an experimental voting system at a nearby university.

Like a lot of things, it boils to down to credibility. Given the inherent reality of failure in research, management has no choice but to place a lot of trust on the team. When pursuing a position like this, you have to minimize the risk you bring to the table. You not only have to show that you have the skills to do the job, but you need tangible evidence that you’ve basically already done it all before, at least in parts and chunks. That means things like authored papers and reports to prove that you can communicate, and designs and prototypes to show off your technical chops.

Do it right and have a bit of luck, and you too can get a similarly sweet gig, like mine at Dude Research.

sweet dude

* I’ll refer to any previous or current employers by false names, just to make it clear I don’t represent any of them here

Would you like to know more?

Image credits