Why you, too, can PhD

It’s getting to the time of the year when graduate programs are accepting applications and deadlines are approaching. Graduate school is a bit of a misnomer, since it’s not really school or a job. If you’re not sure what grad school is all about, you’re not alone. It took me a good while to figure it all out myself. To make the process easier, Cornell’s CS’ very own Professor Ross Tate made a video about common misconceptions about graduate school. It’s mostly aimed at people interested in getting a PhD in Computer Science, but if you’re interested in a different field this video might still be useful. Some common questions answered are:

  1. What is graduate school all about?
  2. Will I get paid to go to graduate school?
  3. Is graduate school only for people who want to become professors?
  4. Do graduate students have a life?
  5. How should I pick a graduate school to apply to?

If you’re curious about any of these things (or graduate school in general), take a look at this video. If you have any questions that weren’t answered, leave a comment either here on the YouTube page and we’ll try our best to answer it.

Graduate School Semester 2

I’m about a month into my second semester of graduate school at Cornell’s excellent Computer Science department. (Shameless plug: If you applied and got admitted you should definitely come visit, we’re awesome. If you’re thinking of applying contact me with questions.) The first semester involved a fair amount of getting used to grad school life. It’s pretty different from undergrad and I covered my initial impressions before. There’s a lot of autonomy (even in the first few semesters) but that means it’s all that much easier to screw up. The most important lessons I’ve learned are to start early, make plans and schedules and set up routines and environments that make getting the work done the default (this applies to both school work and research). I’m definitely not perfect at it, but I try to suck a little less each day.

While last semester was a good learning experience I got a lot less done than I could have. While I don’t want to cry over spilt milk I certainly don’t want to make the same mistakes again. My class load and TA work are about the same as last semester. However I have a better idea of how much time each takes so I can schedule blocks of time more effectively to get large chunks of work done at a time (and not worry about it otherwise). That in turn means that I can have more time for research (which is something I definitely want to do more of this time around).

I’m really happy about the choice of classes I have for this semester. I’m taking Advanced Programming Languages and Datacenter Networks – both are areas in which I have an interest but I know less than I would like to. I have great professors in both and so far the material has been very interesting (and useful). I’m the TA for a class on functional programming which is turning out to be a good learning experience as well. I’ve done some amount of functional programming but not a lot and not in a structured way. I’m working through the exercises and homeworks myself so that I can better help out the students and learning a lot in the process. Since I’m going to be doing a lot of functional programming in the future (Haskell programming in particular) this a good way to level up as well as get my TA duties done.

Last semester I had a small research project which was more of way to get familiar with the concepts and tools I’ll be using later. I am a little disappointed in that my final deliverables weren’t as complete as I would have liked but the experience will come in handy. This semester I have a more concrete (and more ambitious) project. I’m also starting sooner and thanks to last semester I have a far better idea of the challenges I’ll face and how much work it will take to get around them. My main interest in programming languages and right now the project isn’t very language-oriented. But there is a lot of cool systems-hackery involved and once the foundations are laid I can move on to the more higher-level language-oriented parts of it. I’m still taking baby steps (figure out build systems, building testbenches and having rather intense discussions with my compiler) but within a week or two I want to progress to the real meat of the project.

Aside: In case you’re wondering, it involves networks and trusted computing, but more on that in a future post.

Apart from school and research work I’m hoping to do some more exploring. Cornell has a really nice campus but I only saw a small fraction of it last semester (and probably spent a bit too much time in my apartment). I’d like to be able to get out more and take advantage of everything that Cornell has to offer. That’s a bit easier said then done in winter, but that’ll change as things get warmer.

I’m still trying to work out the best “work life balance”. While things like Cal Newport’s fixed schedule productivity seem appealing it might be unworkable for me right now. More importantly, I’m still not sure how separate my work and my life should be, or even what constitutes “work”. I haven’t decided if I consider my writing or my on-the-side hacking (which I’ve been doing far too little of recently) to be work, play or something else. Part of me would like to think that the work-life distinction is only applicable to a more Industrial Age setting where you don’t like your job and want to spend as little time doing it as possible. Ideally you should do work you love (which I’m gradually approaching) and have no need to draw a distinction. While that seems appealing I’m afraid it might lead to sitting (or standing) in front of my machine all day which is not what I want to do. Luckily these aren’t questions I have to answer definitely right now, but I can keep refining my answers over time.

I’m hoping that the rest of the semester will have lots of great learning, cool hacks and maintaining some semblance of a life away from my machines. I know that graduate school can easily become a drag and very stressful and I’m determined to not let myself end up in such a position. Luckily I’m in a good department with great support from friends, family and professors. I’d like to see this semester be more productive and a step on the way to deciding exactly how I want my grad school experience to turn out.

In the presence of gods

From Wikipedia, James Gleick in Genius: The Life and Science of Richard Feynman:

This was Richard Feynman nearing the crest of his powers. At twenty-three … there was no physicist on earth who could match his exuberant command over the native materials of theoretical science. It was not just a facility at mathematics (though it had become clear … that the mathematical machinery emerging from the Wheeler–Feynman collaboration was beyond Wheeler’s own ability). Feynman seemed to possess a frightening ease with the substance behind the equations, like Albert Einstein at the same age, like the Soviet physicist Lev Landau—but few others.

Also, last week I went to a lecture by Jon Kleinberg, Tisch University Professor of Computer Science at Cornell University and winner of a MacArthur Foundation Fellowship (also known as a Genius Award), whose early research formed a large part of Google’s success as a search engine.

Some days we are reminded that we walk among giants, that we live in the presence of gods. On those days, we are humbled and uplifted at the same time.

Flamenco dancers, programmers and excellence

Tuesday night I went to see a Flamenco performance by the Flamenco Vivo Carlota Santana company. It was a wonderful performance, especially the second half (at least that’s what I think, knowing nothing of flamenco). It must have them days of practice to get the choreography and music down right and years to get to the point where they could actually move the way did. Not to mention, the continuing time and effort investment in keeping in physical shape and on top of their game. Being the nearly obsessed student of programming that I am, I of course thought about programming as well.

It’s occurred to me more than once that I really don’t know many great programmers. I go to a small school and most of my fellow students are about the same level as I am (or lower). Actually I don’t really know what level they are on because I don’t get to work with them as much as I would have to in order to find out. There is only one person whom I can say for certain is a better programmer than I am and I’m currently doing a project with him. My professors are good computer scientists, but I have no idea how good at programming they are.

But from what I’ve read (and what I can attest to from personal experience, to some extent) achieving excellence in any field (especially programming) requires a lot of dedication and hard work — about 10,000 hours of it. I’ve thought about whether or not it really is worth it to invest so much time in one activity, even if you really love it. I love spinning code, but I don’t want to be sitting in front of a bright screen all the time. Watching the dancers the other night, I got to see what dedicated practice can bring. They put on a great performance and everyone enjoyed it (including myself) and creating something beautiful and wondrous is a worthy cause. But I’m also interested in getting to know about what they dancers themselves think about their work. I’d love to know their feelings and emotions as they dance and have people cheer and whether they think it’s fair compensation for their commitment. And I don’t mean compensation in only the monetary sense, though that is important too.

Admittedly there is nothing in the programming world that is quite the same as a great dance performance. Our victories are more personal and what people see (and sometimes applaud us for) is often a small sliver of everything that we do. But that’s fine by me. When I solve a hard problem after a long time (my personal record is 3 hours hunting a pointer bug) or make something that I think is really cool (a recursive-descent parser for a little language), I think I feel some of the elation, satisfaction and relief that I think the dancers would have felt too. Yes, it does feel really good. As each year goes by I get better at doing what I love doing. But I rarely ever think about all the practice and experience that has gone into making me capable of whatever it is I am doing. Not too long ago, I would never have imagined myself capable of writing a UNIX shell or designing a programming language, but know I am doing both those things and it feels almost natural.

Ok, that last sentence was a lie. It doesn’t feel natural, but it feels like it’s just outside the range of being natural. When I’m doing things like that, I’m on the edge of incompetence. It was hard and it was painful, but now that I know I can do it, I feel much better. In some ways, I wish such chances came more often (I think the education system for computer-related studies needs to be revamped significantly, but that’s another matter) and I know that each such experience leaves me just a little bit better. Do flamenco dancers feel the same way? Maybe. It would be interesting to find out.

Excellence is a rather strange thing in that it’s hard to achieve and the return on investment on its pursuit can be very little until you get to a certain tipping point. And then there all the people who seem to be trying really hard without getting anywhere. I’m not surprised that many people choose not to put in the investments that it takes to be excellent. As a girl I liked once told me, there are a lot of people leading average lives who are very happy about it. I guess that’s true. I’m not clear about where I stand on excellence myself. I do want to be really good at what I want to do and I fully understand that it won’t be easy. But I also don’t want to give up everything on the quest for excellence. “No sacrifice, no victory” sounds very noble and all, but there’s a tinge of recklessness that I really don’t like.

At this point, the word “balance” might seem appropriate. But that’s bullshit too. I don’t think people who are great at something got there by seeking balance. The better option is breaking the rules, or at least fracturing them. The prime example is 37signals. They’re a small company, with little VC funding who don’t give away their products for free and still make millions of dollars. And they didn’t do it by working round the clock either. They broke “rules” like working 80 hours a week and making free products and other such things. But they also knew what rules to break. They didn’t break rules about being thrifty or having a solid business plan. They might not be the paragon of excellence and they’re certainly arrogant, but they’re doing well so far.

As someone seeking excellence myself, I’m trying to bend my own set of rules. I bend rules by taking courses out of sequence, doing independent studies where I can write lots of code and meet interesting people and actively trying to talk to people I admire. I need to put in 10,000 hours, so I build my life to provide opportunities to do just that. I really wish that there were a lot more people doing the same.

Happy hacking.

The role of software engineering in research

As my research project continues our software is gradually growing more and more features, and we’re adding new functions almost everyday. While it’s certainly a very good feeling to be adding functionality, it can also get ungainly very quickly. About two weeks ago, Slashdot posted a very interesting query by a person interested in doing a PhD on software design principles. Since then, I’ve been giving more and more thought to the role that industry-style software engineering principles play (or should play) in computer science research.

Research in science has been mostly held to be separate from engineering. Chemistry research is not performed in quite the same way that chemical engineering is. Even in cases where there is significant amounts of high technology equipment is used (the LHC is a good recent example), the engineering teams are separate from the scientists. However, computer science is not really a typical science at all. Research in computer science faces many of the same problems that software development faces:

  • Multiple people working simultaneously on large and growing codebases (team management).
  • Adding or removing features without requiring major rewrites (extensibility).
  • A way to collect large amounts of data and detect failures (testing and error logging)
  • Having multiple copies of the experiment running, with different parameters (scalability and version control).
  • Last, but not least, the experiment should actually work and produce results (in corporate terms, the software should ship).

Keeping the similarities in mind, what lessons can we as researchers learn from industry techniques and practices (by industry, I mean open source as well)? I’m not sure what other researchers do, or if there is some sort of standard procedure, so I’ll just talk about what my small team has done to make our work easier.

Divide and conquer:

The first thing we did was to carve up the various parts of the project. While my two teammates took up the core engine and the output system, I chose to deal with the human interaction part. At the same time. we had regular meetings where we planned out how our parts should interact as well making high-level descriptions of what each part of the code should do. This meant we could each develop our code largely independent of the others while still having a fair idea of where the whole project was going.

Throwing away version 1:

Though our first version was a working program, we made it keeping in mind that we would probably have to change a lot of things, possible even rewrite it. As a result, we developed it quickly, and focused on making it “just work” without adding too many features. This allowed to get a good feel for what the rest of the project would be like and let us make important decisions before we had invested a lot of time into it. In research you often don’t know what you’re looking for until you start looking, and this was the case for us. Our throwaway version gave us a better idea of which direction our research was heading, what concepts had been explored before, what was new and how difficult various aspects were.

Strict Version control:

Right after we started working on our post-throwaway system, we moved all our code to a Subversion repository on our college’s research cluster. We do are own work in our working commits and perform daily commits and updaes. Our repository is also divided into trunk, branch and tag directories to keep separate the most recent copy, older releases and other milestones. This way we can see the evolution of our project at a glance more easily than having to check out older versions. This comes in particularly handy, since being a research project we tend to be looking at what we did before and what results we got rather regularly.

Coding conventions:

Another post-throwaway decision was regarding coding styles. We fixed general naming and commenting styles, decided on tabs vs. spaces (4-space indent, in case you’re interested) as well as a number of minor things that weren’t project-threatening, but could have led to unnessecary confusion later on. We also keep detailed records of how we’ve changed our codes and any bugs we’ve introduced/fixed on a common wiki meaning that everyone is always up-to-date on changes.

Personal freedom:

By standardizing some aspects of our project, we’ve been able to have greater freedom as individual researchers. All our code is in platform-independent Python. Besides that our only other common tool is Subversion, which is also freely available and easy to use. By choosing open source and platform-independence, we have been able to have three developers work on three different platforms using different editors, IDEs and SVN clients. We can work equally well on our own machines sitting in our rooms, on the computers in our CS department’s labs, or even from the Mac Pro computers in the Arts buildings via SSH. It’s hard to quantify how much easier this independence has made our work. This has meant that we didn’t have to rush to the CS Lab’s whenever we had a thought or problem and we could whenever we wanted, however we wanted as long as we stuck to some simple rules. Scientists and programmers both need a certain amount of freedom and we’ve been able to secure this freedom by a proper choice of tools and techniques.

Things to do:

It’s been almost four weeks since we started using software engineering practices for our research work. We don’t know how things would have turned out had we not implemented the practices that we have. However we have come to rely heavily on the framework and guidelines that we have built for ourselves. At the same time, we’ve come to realize that there are parts of our project that could benefit from adopting some more industry-standard practices. I’ll end with a brief list of the things we plan to implement in the next few weeks:

Robust error handling: We’re currently using some very ad-hoc methods to handle errors and track down bugs. But we’re in the process of building a flexible, yet robust error handling and reporting system into our project. Since we intend our tool to be used by non-programmers, we need to implement a system that won’t mean looking at the code everytime something goes wrong.

Flexibility via a strong framework: Our work has turned out to have more applications than what we originally intended for it. As a result, we were considering forking our code into two separate branches. Though we still haven’t reached a proper decision regarding this, I’ve personally been trying to redesign our project into a “framework + dynamic modules” system. This is purely a software engineering effort, since it will mean a lot of refactoring and restructuring, but will not have much of an external effect rather than making our job easier.

Unit testing and other automation: Till now, an important part of our work has been getting user feedback, partly because our system is very visual intensive and also because we weren’t quite sure what we were looking for. Now that we have a better idea of where our project should be headed and what we should be looking for, we can begin to automate some parts of our work. However we won’t just be checking for bugs, but rather generating a large number of results and then further improve our system to get what we want.

I’d love to hear from anyone who’s been involved in computer science research projects and has opinions of how to use software engineering principles to make things easier/more effiicient.