A Guide to Getting a Programming RA

The all-consuming endeavor of most graduate students from South Asia is to find a research assistantship the moment they land, if not earlier. The topic dominates conversations so much so that a typical conversation goes like, "What is your name? Do you have funding?" - when people are in a hurry they sometimes mix up the order.

Funding is a big deal for South Asian students coming straight from undergraduate studies simply because education is very expensive and most people rely on personal funds or loans. This weighs very heavily on minds that haven't yet seen the color of money, who find it hard to remember that it is possible to pay off the loan in about a year since graduation (lets assume a modest $7000, that's $84,000 per annum - Stanford Masters tuition is around $43,000 per year).

I know that I cannot take this tension away. However, I can give some advice, having done a little bit of research on labs that hire software development talent. I got to do a study last Winter, understanding the problems that professors face when hiring Masters students for software development. Regardless of the department, there was a remarkable similarity in the issues faced. I will try to present some of them, and suggest concrete steps students can take to make good decisions and increase their odds of having a successful educational experience at Stanford.

Professors are generally scared of Masters students. Masters students tend to be desperate for money and will initially promise the world in order to get an assistantship. They don't usually take the time to think about research (RA = research assistantship). Once they're given a programming RA, a couple of things have been seen to happen. First, it turns out their programming skills might be good but their software development skills are awful. They can take the professor back a couple of quarters (as in, someone has to come in and clean up the mess). Second, they have homework. And between homework and research, homework takes priority. Third, even after they cross the first two hurdles, learn and start performing, the time has come for them to graduate and the professor has to now retrain someone or drop the project.

I am not trying to be cynical by citing these reasons. I think it is very important to understand the system if we are to work with it. The reasons above cause professors to prefer Ph. D. students for meaningful work. However, it is not always possible to find Ph. D. students with solid programming skills, and there are openings for Masters students. These are kept hidden, if the professor values mail sanity. Usually, existing students are told to contact friends they trust for potential RA candidates.

Let's take a look at what these dynamics do to the educational experience of a Masters student. Until funding has been obtained, a Masters student in the South Asian community feels like a loser. Every time someone gets an RA, it becomes the topic of the evening conversation, and calls of commendation pour in. It starts to feel as though the goal of coming to Stanford is to get an RA, and not a Masters education. If you're lucky, a mentor can help set things right by reminding you of why you are here. If you're not, this leads to miserable nights.

I submit that the two scenarios are painful both for the professor and the student. The professor is not moving ahead on research and the student is having a bad time. If you don't agree with me so far, then you can stop here. I also submit that it is possible to get out of this mess and be really happy, the ENTIRE time you are at Stanford. Read on.

There are two frames I will use to tackle this scenario. Philosophical and Material.

Philosophical
First, happiness is not a condition, it is a decision. You decide to be sad or happy. You decide to worry or be stressed. If you can accept the truth of this, then you will find there is no reason to be sad, no matter what. From day one, remind yourself of the immense honor and opportunity you have by getting admitted to Stanford. You must show your gratitude to the world by being the best student possible and learning more than anyone else. You will let yourself down by doing any less. All your material decisions will be based on this philosophy. If you find people discussing what a sad situation it is that RAs are hard to find, you must not let that get to you and inspire your friends to see the opportunity that they already have.

Material
Lets look at the material side now. This is a whole lot easier, as objectives and criteria are external. They are not often explicitly stated, but the purpose of this article is to make them explicit.

First, we must begin by aligning with a professor's research interest. They need the best programming talent they can get so their research can progress. It is easy to miss the fact that there is research involved, and the best programmers for a professor are usually also interested and aligned with the research. If you treat programming as a day job that you must somehow get through to pay for your tuition, you will be miserable and make your professor miserable as well. So, find a professor who does or likes what you would love to do.

Second, it is true that you won't be an ace software developer if you have never developed software. Don't count college hacking experiences - that was about machines and languages. Software Development is about people, psychology and communication. It is not fair to expect you to know this if you haven't worked professionally - but what the heck, one of your colleagues reading this article will take the effort to learn, so you can't afford not to if you want to stay in the competition. You need to check-in to a training center in India or wherever else you are and invest in yourself. If there is no training center, then sit down and teach yourself. What training should you get? Here's a list that I think is essential:

[1] Extreme Programming Methodology: How to build software in an agile manner - learn how to run the Planning Game (professors love it when exposed to it), Retrospectives, Continuous Integration, Test-Driven Development, Refactoring, etc..

Book - Extreme Programming Explained by Kent Beck
Site: http://www.xprogramming.com, http://www.industrialxp.org
Mailing lists: Extreme Programming, Industrial XP, Extreme Programming India (ask on this list for training opportunities - I think ThoughtWorks keeps organizing seminars and workshops)

[2] Test-Driven Development (TDD) and Refactoring: These two are so important that even if you couldn't understand XP, you must do your best to master these.

TDD
Book - Test Driven Development: A Practical Guide by Dave Astels
http://www.testdriven.com/, http://www.junit.org
Mailing List: Test Driven Development

Refactoring
Book - Refactoring: Improving the Design of Existing Code by Martin Fowler
http://www.refactoring.com
Mailing List: Refactoring

[3] Design: For any serious programming, you must understand Object-Oriented design. A lot of people use C++ and Java's OO features grudgingly and create terrible messes. The test for anyone knowing Object-Oriented design is if they understand "Design Patterns." It is a fun subject, and your level of programming climbs several notches when you know this.

Book - Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, et al.
Book - Refactoring to Patterns by Joshua Kerievsky, et al.
Mailing List: Design Patterns

[4] The craft of programming: Learn how to use your environment to support agility. If you are a Java programmer, then learn how to use Eclipse really well - http://www.eclipse.org - this IDE is free. Figure out how to setup your own CVS repository to do version control of code. Attend an Eclipse workshop in India. If you are using C++, then Eclipse supports C++ as well. The Microsoft tools for programming tend to be primitive - make sure the IDE you pick has native support for Test-Driven Development and Refactoring (like Eclipse). Learn how to write tests in Eclipse and have it lead to production code. Learn how to do automated refactorings in Eclipse.

Book: The Java Developer's Guide to Eclipse, Professional Eclipse 3

Optional (depending on the lab)-->
[5] Databases: Master working with at least one database, learn about ODBC/JDBC bridges and drivers. Build a reasonable application to get your hands dirty.

[6] Web Development: If you can, learn how to do web-based development - servlets and the Model View Controller pattern that drives so much of it. See if you can pick up the Struts framework.

The Secret is Out
Now that the secret is out, if you don't get trained, your friends will and that will put you at a disadvantage. So better get started..

Once you have this background, you will find professors very interested in talking to you. Then, it becomes a matter of aligning research interests and personality. With this background, you will not be rejected for lack of technical knowledge, and it will help you generate opportunities.

Just so you know, 6 to 7 months is sufficient time for picking these up, if you put your heart into it. It is a much better investment than simply worrying about funding. After reading all this, you may just decide that you do not want a programming RA. That is what I did. I liked one professor's work in Global Teamwork and took a risk - worked with this professor for two quarters without funding. It produced immense learning for me, led to a summer internship and a quarter's RA. It also led me to love research and apply into the Ph. D. program. My close South Asian friends have had similar experiences. Two of them focused on Strategy and worked with a top marketing professor for two quarters to produce a top-class Harvard Business Review case study with their names on it. This case study was used as a final for the professor' s class. Both have top notch jobs now in designing Strategy (Deloitte and Microsoft), due in no small part to their background work in this area and the risk they took.

Good luck!