More Indian sport

I love posts where I can say “I told you so”. After the 2008 Olympics, I wondered if this was a new dawn in Indian sport. The events of the 2010 asian games have strengthened my belief that it is indeed so. True, the shooters haven’t lived up to their potential, and the archers didn’t do as well as they did in the commonwealth games, but take one look at the details of the medal tally, and you’ll see what I am talking about.

A 1-2 finish in the women’s 10k race. A 2-3 finish in the 5k race. Gold in the steeplechase event. Gold in the women’s 400m hurdles after 24 years. Gold in the men’s 400m for the first time ever (unless Milkha Singh won it in his time). Gold in rowing. First time medals in skating and gymnastics. Golds in boxing. This games have been quite good for India.

What is also heartening is the manner in which these medals were won. Take for instance, Joseph Abraham’s last minute push to get the gold or Sudha Singh’s desperate lunge to finish first – how many times in the past have we seen Indian athletes overcome their opposition when placed in such situations?

Rest assured, things will improve. These heroes will now encourage more sportsmen and women in the country to come forward. With government support and strong private sector participation, not to mention rising confidence in Indian abilities, the future looks bright. Of course, the 2012 olympics will tell us how far we have come, but I’m more confident than ever that we have crossed one, if not all the hurdles in the way of sporting success.

The ‘developer’ high

Most of us in the software profession agree that it is probably one of the few honest professions that will pay you a decent monthly allowance for doing something you love to do. But have you wondered why software development is such fun?

Well, as you expected, I have a theory. I think the reason development is such fun is because of the recurring, never-decreasing highs that one gets. Created a cool, extensible design? You have a high. Found a cool way to randomize a list with just one line of LINQ code? You have a high. Debugged a crazy bug that has haunted you for days? You have a high. Positive customer feedback? Another high. Why, even seeing a “all-green” status on your unit test run – even that can give you a high.

And the best thing about the highs is that their intensity is not dulled by repetition – something a good alcoholic smoker friend of mine certified :)

This is probably a key factor that keeps developers glued to their IDEs.

Putting on my trench man hat, I think this is another aspect that differentiates developers from researchers. Researcher highs are fewer and far-inbetween. You publish maybe 3-5 papers every year. Generating new, workable, and innovative ideas that are different from those in the ‘market’ is gut-wrenching work, and new leads probably occur a few times a year. The situation is even worse for managers who have to wait for a product to ship to feel the high.

There is a flip-side to this. It is easy for developers to fall into the addiction trap – sometimes sacrificing long term health of true innovation at the altar of the regular dosage of customer appreciation highs. Managers and researchers can keep their sights on the bigger prize for longer because their work and training (particularly for the researchers) trains them to think longer-term.

Again, let me add my usual disclaimers about this being a generalization and like all generalizations, not applicable to all people and situations! :)

What do you think?

The biggest threat to India

Ramachandra Guha of “India after Gandhi” fame once visited our lab and gave a talk in our “Kaleidoscope” series. He outlined nine threats to Indian security – Maoists, majority communalism, the divide between the rich and the poor, and so on. Unfortunately, he missed out on three others: the so called liberals and human rights activists, the communists and the UPA.

The common thread to these three threats is that they represent the left in its different colours and flavours. There is the hard-left – the Maoists who are determined to undermine the state militarily, the soft-left, comprising of the activists and the leftists who want to it by sleight of hand, and the UPA who wants to do it by inaction.

Let me elaborate. For long, it has been thought that Muslim and Hindu fundamentalism feeds each other. The most common example is the the Shah bano case and allowing Shilanyas at the disputed site in Ayodhya. One set of fundamentalists got the law amended to undermine women’s rights, and the other got the opportunity to start a ‘communal’ movement. However, what is forgotten in these discourses is the role of the “secularists”, “progressives”, and the “leftists”. While there was widespread condemnation of the Shilanyas and the subsequent yatra, condemnation of the parliamentary amendment was muted. And this is a pattern that is familiar. Secularists who condemn the attack on M.F. Hussain, are suddenly silent when a professor in Kerala has his arms chopped and is suspended from service. ‘Progressives’ who come on to the streets against the burkha ban somewhere in France, don’t venture out when the popular front of Kerala threatens a woman for refusing to wear the veil. Our own Manmoron Singh, who spent sleepless nights at the thought of Dr. Haneef in spending time in jail, had a sound, silent sleep when tens of innocent students (mostly Hindus and Sikhs) were beaten and killed in Australia. In the latest incident, I saw a human-rights activist talk about the suffering of the Kashmiri Muslims without a single nod of acknowledgement towards the suffering of the Pandits, which was one of the worst incidents of ethnic cleansing in the country. The same person went on to call the Panun Kashmir a communal organization – Syed Shah Geelani, a two-state theorist is secular, while an organization founded to safeguard the interests of displaced Pandits is communal!

It is this perverted logic of the leftists, human rights activists, ‘liberals’ and ‘secularists’ that incites majority communalism. It is this logic that clouds reality, and forces governments into taking illogical decisions. See the debate on the AFSPA for instance. There is not a single shot that has been fired by the Army, yet there is all the hullaballoo about withdrawing special powers to it!

Wonder why the “left” acts this way? The answer is simple – leftism needs victims to survive. Leftism needs to oppose. And leftism hates stability. I can go on about this – but I’ll defer that to a later post.

Java is not a good first language

I’ve found that the only way to get back to blogging is by writing some random posts. After a hiatus, it somehow becomes very difficult to write cohesive posts on a single topic. The words don’t come out as easily, the sentences don’t seem right, and I spend inordinate amounts of time trying to come up with enough material for my post. Finally, unable to come up with something I like, I abandon the post and add it to an ever-growing list of drafts that I never re-visit.

Anyhoo, for today’s random post, I talk about the threat posed by Java schools to the software profession and the threats that human rights activists, perverse secularists, and the UPA pose to this country.

First, Java schools. While there is long on-going debate in sociology on whether language determines thought (what is called the “linguistic relativity” principle, or the Sapir-Whorf hypothesis), that question in Computer Science is settled. In the world of programming, language does determine thought. Which is why Stroustrup had put in warnings for C programmers to think object-orientedly. Which is why most imperative programmers take refuge in the := and ! operators of SML when they first encounter functional programming. The language you program in makes you think a certain way. The trouble with teaching Java as the first language is that there is no way teachers can teach the way to think in Java (the object-oriented way) without the students undergoing a course in procedural languages. As a result, students end up thinking in way totally unsuited to the language – a class becomes something you create because the language forces you to, and a place where you dump everything that your program needs. Objects become mechanisms to get at the members without the notion of what it means to instantiate something. Access control mechanisms become a unnecessary distraction – if you want a class to access a member in a different class, make the member public. The signature of “main” - “public static void main (string [] args) introduces problems of its own that have been detailed in ACM papers here and here. Beyond these problems, Java abstracts away some of the most critical concepts in Computer science – pointers, memory management, the idea that resources are finite, and the dilemmas programmers face in using and implementing data structures.

The trigger for this rant is a bunch of interviews that my teammates and I are conducting to hire summer interns. Our target pool are the students from the IITs, most with very high GPAs (think 8.8+/10) and two years into their B.Tech courses. All of them have done 3-4 academic projects, and some of them, internships in places like Adobe. Due to their relative immaturity, what we look for are programming basics – choosing data structures, programming recursive algorithms, and some Computer science fundamentals in areas like networking, OSes, or OOAD (depending on the students’ coursework). To our surprise, we found that while most of the students knew the commonly used data structures, very few could choose the appropriate one for the problem at hand. Still fewer got the implementations right, and most wrote code as though they were in programmer utopia – infinite memory, infinite resources, and nothing bad ever happening in the environment. The bigger problem was that not one bloke I interviewed was able to find and debug problems in their code.

There also seems to be this idea gaining ground, particularly amongst the Phd-types that teach courses at the IITs, that programming is secondary to Computer Science, and what matters is “researchy” topics, like IR, machine learning, large scale algorithms or such. At the same time, there is tremendous pressure on the IITs to evolve from being teaching institutions into research institutions. Because they cannot attract talent at the graduate level, it seems professors are taking the route to make the undergraduate program a research program. Good programming techniques and sound concepts of software engineering become “implementation detail”. And writing good code, tests, and having the ability to debug programs is lost on a whole generation of Computer science undergraduates.

Or maybe I’m just being paranoid.

[Postscript: I realized rather late, that this post had become too huge for me to add my second rant. I’ll be posting it separately.]

A trenchman’s view of the ivory tower

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.