For some time now, I’ve avoided talking about my current job – in fact, I’ve tried to avoid all job-specific posts on this blog. However, ever since I took my current position, too many people have asked me the precise nature of my work - “Research SDE” isn’t a very common job title. Further, for the past few months, as I’ve had my head down in work, my blogging suffered and I realized that writing about work might be the only way to get some content in a Windows Live Writer window.
I underwent eleven rounds of interviews before MSR India offered me my current position. These were conducted on two separate days with a very eventful fortnight in between. Some of interviews went well, and some went poorly, but the one that challenged my entire graduate thesis was the one with a research manager, who is probably the most accomplished researcher in the field of static analysis. And I faced the most enjoyable enquiry I’d faced on my thesis – even better than my thesis defence! Towards the end, he told me (and I paraphrase very liberally): “Sometimes, researchers sit in ivory towers and lose sense of the trenches and make unreasonable demands of developers. Can you describe an instance when you faced a demand you thought was unreasonable, and pushed back?”
At that time, I thought he was talking about hypothetical situations. Why would people who were more technically accomplished than most developers make unreasonable demands of them? It just didn’t make sense. I answered what ever I could forgot about it for quite some time.
Now, four years, half-a-dozen projects and with a bunch of successes and failures behind me, I realize that he was pointing to a fundamental difference in perspective between the two groups in the lab – developers (and I include PMs and dev managers in this group) and researchers. I also realize now that as both an insider in the lab, and an outsider in research, I have a unique perspective (which may be right or wrong). Hence this series. Here, I intend to write about research from a developer’s perspective, and of the life of a developer in a research lab. Please note however, that everything I say here, like elsewhere on my blog, is strictly my opinion, and has nothing to do with my current, past or future employers.
First we introduce our actors. Researchers are starters. They love starting new projects, coming up with new ideas, and working on new problems. Researchers thrive in uncertain situations, love unclearly defined problems, and generally are fond of exploration. Failures are acceptable as long as there is a lesson that is learnt. Theoretical soundness is more important than fit and finish – it is OK to have a solution for a problem that ignores the “corner cases” - provided the problem is unique and challenging enough.
Developers are finishers. We like conclusions, we like definite schedules, and we like knowing that what we are doing will be used directly by our audiences. We prefer certainty and while we do explore, we will almost never put our exploration ahead of our project commitments. Shipping is everything and the user is king (well, most of the time :)). Polish matters – a feature is worth nothing if it doesn’t work on a particular browser or a supported platform. In fact, I remember from my previous companies, exercising our code through automated test-cases on eleven different platforms before getting a green signal to ship.
Of course, these are generalizations. And like all generalizations, they have many exceptions. It does happen that a researcher puts on a developer’s hat for a year or two simply because (s)he is committed to a project/idea. Developers do take technical uncertainty in their stride when required. However, what I’ve outlined is the basic nature of the two species – the starters and the finishers.
In future posts, I’ll narrate some incidents, describe some of the insights I learnt, including working with those beings known as interns, and attempt to paint an honest picture of the life of a trench soldier who was invited to the ivory tower.