Slumdog Programmer

The movie Slumdog Millionaire reminds me of my own career. Like the kid in the movie, I often found myself answering questions only because life had unexpectedly prepared me years earlier. My preparation came from subjects I once thought were useless in school.

As an alumnus of the National Institute of Technology, Trichy, India (then called Regional Engineering College), I used to attend the alumni association meetings regularly. A regular feature of such meetings was a discussion on the contents of the program I'd just graduated from. The confidence that came from having a good job, and a first-hand knowledge of the work environment made my group believe that we were well positioned to offer feedback to the university on the program contents.

The program I graduated from was a combination of computer science and mathematics, with some management courses thrown in. It was a popular program. I recall the elation when I was offered admission, the sense of awe that came with it, the fear and the resultant humility. (“Gee! This is all so sophisticated! Am I going to be a misfit?’).

In hindsight, this makes it all the more surprising that I felt qualified to offer advice on the course contents right after graduation.

We debated the useful and dispensable parts of the program. In those days, most people did database work, so part of the group felt that databases, SQL, form designers and report generators were all that were needed. ‘Who needs compilers, data structures, numerical analysis, statistics and all that stuff? And why are they shoving courses on organizational behavior and economics down our throats?’

I might have been ambivalent in response to such sentiments. But I was certainly party to the group recommendations. Our recommendation, as I recall, was to lighten the students' workload by dropping a few courses. It took me three years to realize how wrong we had been. What I was forced to learn during my student days has helped me solve several hard problems over the years. At the very least, the background knowledge ensured that I didn’t back down from many challenges.

When I got my first job in England, I joined an international software development team. The team was mostly contractors from various European countries. As the newcomer, I felt the need to earn my place in the team.

The team worked on a software product. All the low-level functionality of the software was exposed to the application tier through an interpreted scripting language. The language might have been well-designed and tidy to begin with, but had evolved to a beast over acquisitions and team changes. Any new functionality involved enhancing the scripting language. There was no oversight, or coherent guidance for those enhancements. So, people threw new statements and phrases in the language, as long as the changes didn’t break anything else, all was considered to be good. As a newcomer, I didn’t spot the problem immediately, but noticed that every time I compiled the code, yacc, the parser generator warned of several conflicts. The folk wisdom went like, ‘as long as you don’t see more than 27 shift/reduce conflicts and 9 reduce/reduce conflicts, you’re ok’. 

I was working over a Christmas break, mainly because I had exhausted my vacation days for the year. I didn’t have much to do, so I chased one of those warnings. I had studied compilers and formal languages in my course without any idea why. But strangely, that background had given me some intuition on why expressing a statement one way was ok, but not another way. Without being able to explain my changes, I did a few experimental changes to the grammar, and found that I could get rid of half the conflicts with a day’s work. I checked my changes in, ensured that the build went ok, and went home after sending a request for code review.

The effect on the rest of the team was sensational! They seemed to have the attitude, ‘Better you than me!’ as everyone hated the interpreter part of the code. So everyone was happy. That incident went a long way in me being accepted as a member of the team.

That was one episode. Years later, graph theory resurfaced in routing algorithms. Numerical analysis appeared again while implementing coordinate system transformations. Machine learning brought back linear algebra and calculus. Subjects that once seemed disconnected turned out to be waiting for their turn in real world use.

I don’t want to give you the impression that I was somehow a model student, or that I understood everything that was taught. Far from it. I started with all the ideals, but had subsequently settled for keeping my head above water as new information was taught, and thankful to pass the courses. Teaching quality was also variable. But overall, the course content and instruction have prepared me not just for my first job, but for the next thirty years.

Or perhaps I was just lucky like that kid in ‘Slumdog Millionaire’.

I urge my children not to view their courses with a minimalist 'what-good-is-this-going-to-do' bias. Further, I believe too much of early specialization can reduce the range of problems they can address later in their career.

Click here to read other career related posts in this blog.