Although I made the move to industry a bit more than five years ago, I still serve on program committees and review articles for journals and the like. So it's painful for me to see some of my academic colleagues totally botch it when it comes to doing industry-relevant research. Profs, grad students: we need to talk.
(Standard disclaimer: This is my personal blog and the opinions expressed here are mine alone, and most certainly not that of my employer.)
Of course, many academics do a great job of visionary, out-of-the-box, push-the-envelope research that inspires and drives work in industry. I'm talking about stuff like Shwetak Patel's increasingly insane ways of inferring activities from random signals in the environment; Dina Katabi's rethinking of wireless protocols; and pretty much anything that David Patterson has ever done. Those folks (and many others) are doing fine. Keep it up.
But the vast majority of papers and proposals I read are, well, crap. Mostly I'm involved in mobile, wireless, and systems, and in all three of these subfields I see plenty of academic work that tries to solve problems relevant to industry, but often gets it badly wrong. I don't quite know why this happens, but I have some ideas of how we might be able to fix it.
Now, I don't think all academic research has to be relevant to industry. In some sense, the best research (albeit the riskiest and often hardest to fund) is stuff going way beyond where industry is focused today. Many academics kind of kid themselves about how forward-thinking their work is, though. Working on biomolecular computation? That's far out. Working on building a faster version of MapReduce? Not so much. I'd argue most academics work on the latter kind of problem -- and that's fine! -- but don't pretend you're immune from industry relevance just because you're in a university.
My first piece of advice: do a sabbatical or internship in industry. It's probably the best way to get exposed to the real world problems -- and the scale and complexity -- that you want to have as inspiration for your work. It drives me insane to see papers that claim that some problem is "unsolved" when most of the industry players have already solved it, but they didn't happen to write an NSDI or SIGCOMM paper about it. Learn about what's going on in the real world and what problems are both being actively worked on, and what will be important a few years down the line. If you buy me a beer I'll spend a lot of time telling you what's hard at Google and what we need help with. Hint: It ain't yet another multihop routing protocol.
And by "industry", I do not mean "an academic research lab that happens to reside at a company." You can spend time there and learn a lot, but it isn't getting quite the level of product exposure I have in mind.
For this to work, you have to work on a real product team. I know this sounds like a waste of time because you probably won't get a paper out of it, but it can be an extremely eye-opening experience. Not only do you start to understand the constraints that real products have -- like, oh, it actually has to work -- but you also pick up on good engineering practices: bug tracking, code reviews, documentation. You get your hands dirty. You might even launch something that other people use (I know, crazy, right?).
Second: don't get hung up on who invents what. Coming from academia, I was trained to fiercely defend my intellectual territory, pissing all over anything that seemed remotely close to my area of interest. Industry is far more collaborative and credit is widely shared. If another team has good ideas, and can help you achieve your goals faster, join them -- and build upon that common success. So much bad academic work seems to boil down to someone trying to be so differentiated and unique that they paint themselves in a sparkly, rainbow-colored corner that, yes, ensures you stand out, but means you're often going about things the wrong way. Unfortunately, the publish-or-perish culture of academia often forces people to add arbitrary differentiation to their work so they can't be accused of being derivative. That's too bad, because a tremendous amount of value can be derived by refining and improving upon someone else's ideas.
Third: hold yourself to a higher standard. Program committees can be brutal, but I don't think they go far enough when it comes to setting the bar for real-world relevance. Collecting data from a dozen students running your little buggy mobile app is nothing compared to industry scale. Even if you can't get a million or a hundred million people using your app, what would it take? Wouldn't it have to work on a lot of different phone platforms? Not badly impact battery life? Actually be secure? Use a server running somewhere other than under a grad student's desk? Possibly have a unit test or two in the code?
Now, I know what you're thinking -- all of this is a distraction, since you don't need to go this extra mile to get that paper submitted. That's true. But if you're trying to do industry-relevant work, it helps to look at things through an industry lens, which means going beyond the "it ran once and I got the graphs" prototypes you're probably building. Why doesn't Google just rewrite Android in Haskell, or why doesn't Facebook just throw away their filesystem and use yours instead? Maybe it has something to do with some of these annoying "engineering problems".
Finally, try to keep an open mind about how your research can have impact and relevance. A lot of academics get so laser-focused on impressing the next program committee that they fail to see the big picture. It's like being a chef that's only out to impress the restaurant critics and can't cook a decent goddamn hamburger. My PhD advisor never seemed to care particularly about publishing papers; rather, he wanted to move the needle for the field, and he did (multiple times). Over-indexing on what's going to impress the tiny set of people reviewing SOSP or MobiCom papers is a missed opportunity. Racking up publications is fine, but if you want to have impact on the real world, there's a lot more you can do.
(Standard disclaimer: This is my personal blog and the opinions expressed here are mine alone, and most certainly not that of my employer.)
Of course, many academics do a great job of visionary, out-of-the-box, push-the-envelope research that inspires and drives work in industry. I'm talking about stuff like Shwetak Patel's increasingly insane ways of inferring activities from random signals in the environment; Dina Katabi's rethinking of wireless protocols; and pretty much anything that David Patterson has ever done. Those folks (and many others) are doing fine. Keep it up.
But the vast majority of papers and proposals I read are, well, crap. Mostly I'm involved in mobile, wireless, and systems, and in all three of these subfields I see plenty of academic work that tries to solve problems relevant to industry, but often gets it badly wrong. I don't quite know why this happens, but I have some ideas of how we might be able to fix it.
Now, I don't think all academic research has to be relevant to industry. In some sense, the best research (albeit the riskiest and often hardest to fund) is stuff going way beyond where industry is focused today. Many academics kind of kid themselves about how forward-thinking their work is, though. Working on biomolecular computation? That's far out. Working on building a faster version of MapReduce? Not so much. I'd argue most academics work on the latter kind of problem -- and that's fine! -- but don't pretend you're immune from industry relevance just because you're in a university.
My first piece of advice: do a sabbatical or internship in industry. It's probably the best way to get exposed to the real world problems -- and the scale and complexity -- that you want to have as inspiration for your work. It drives me insane to see papers that claim that some problem is "unsolved" when most of the industry players have already solved it, but they didn't happen to write an NSDI or SIGCOMM paper about it. Learn about what's going on in the real world and what problems are both being actively worked on, and what will be important a few years down the line. If you buy me a beer I'll spend a lot of time telling you what's hard at Google and what we need help with. Hint: It ain't yet another multihop routing protocol.
And by "industry", I do not mean "an academic research lab that happens to reside at a company." You can spend time there and learn a lot, but it isn't getting quite the level of product exposure I have in mind.
For this to work, you have to work on a real product team. I know this sounds like a waste of time because you probably won't get a paper out of it, but it can be an extremely eye-opening experience. Not only do you start to understand the constraints that real products have -- like, oh, it actually has to work -- but you also pick up on good engineering practices: bug tracking, code reviews, documentation. You get your hands dirty. You might even launch something that other people use (I know, crazy, right?).
Second: don't get hung up on who invents what. Coming from academia, I was trained to fiercely defend my intellectual territory, pissing all over anything that seemed remotely close to my area of interest. Industry is far more collaborative and credit is widely shared. If another team has good ideas, and can help you achieve your goals faster, join them -- and build upon that common success. So much bad academic work seems to boil down to someone trying to be so differentiated and unique that they paint themselves in a sparkly, rainbow-colored corner that, yes, ensures you stand out, but means you're often going about things the wrong way. Unfortunately, the publish-or-perish culture of academia often forces people to add arbitrary differentiation to their work so they can't be accused of being derivative. That's too bad, because a tremendous amount of value can be derived by refining and improving upon someone else's ideas.
Third: hold yourself to a higher standard. Program committees can be brutal, but I don't think they go far enough when it comes to setting the bar for real-world relevance. Collecting data from a dozen students running your little buggy mobile app is nothing compared to industry scale. Even if you can't get a million or a hundred million people using your app, what would it take? Wouldn't it have to work on a lot of different phone platforms? Not badly impact battery life? Actually be secure? Use a server running somewhere other than under a grad student's desk? Possibly have a unit test or two in the code?
Now, I know what you're thinking -- all of this is a distraction, since you don't need to go this extra mile to get that paper submitted. That's true. But if you're trying to do industry-relevant work, it helps to look at things through an industry lens, which means going beyond the "it ran once and I got the graphs" prototypes you're probably building. Why doesn't Google just rewrite Android in Haskell, or why doesn't Facebook just throw away their filesystem and use yours instead? Maybe it has something to do with some of these annoying "engineering problems".
Finally, try to keep an open mind about how your research can have impact and relevance. A lot of academics get so laser-focused on impressing the next program committee that they fail to see the big picture. It's like being a chef that's only out to impress the restaurant critics and can't cook a decent goddamn hamburger. My PhD advisor never seemed to care particularly about publishing papers; rather, he wanted to move the needle for the field, and he did (multiple times). Over-indexing on what's going to impress the tiny set of people reviewing SOSP or MobiCom papers is a missed opportunity. Racking up publications is fine, but if you want to have impact on the real world, there's a lot more you can do.
