I recall my early days as an alumnus of the National Institute of Technology, Trichy in India. (Then called Regional Engineering College, Trichy). I had just graduated and found a job. 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 me and my peers believe that we were well positioned to offer feedback to the university on the course contents.
The program I graduated from was a combination of computer science and mathematics, with some management courses thrown in. It was a much sought after 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.
I don’t recall how far I supported such positions. 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.
Fast forward three decades, and I’m glad that they made us learn all that. 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. I was initially not very comfortable in the team. The team was mostly contractors from various European countries. Some seemed to view me, the new arrival, with suspicion.
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 how to do 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 scripting phrase one way was ok, but not another way. Without being able to explain my changes, I did a few experimental changes, and found that I could get rid of half the conflicts with a day’s work. I checked my changes in, ensured that the overnight build went ok, and went home after sending a request for code review.
The effect on the rest of the team was sensational! My boss was especially impressed that the new guy had somehow acquired a mysterious skill that was missing in the team. He wanted to make me the gatekeeper for the scripting language, but thankfully didn’t insist when I declined. The rest of the team 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. Over the years, I had found a use for graph theory when I was working on routing software. (Yes, the thing that Google maps routing does!). I’d found a use for numerical analysis when I was asked to implement coordinate transformations to transform geometric objects on spherical/ellipsoidal earth to a flat map or screen. Linear algebra, matrix multiplications, differential calculus, and mathematical functions came in handy when I learned machine learning. When I write algorithms, having an intuition on algorithmic complexity helps. These were all taught to me in another part of the world in another era!
Turns out that the management courses were useful as well. I can follow statements about EBITDA and P&L when the product managers talk about the quarter. The organizational studies gave me the vocabulary to translate top mangement's statements to my team in their language.
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 studied just enough to pass the courses. Not all the teachers were good, or even fully competent. But overall, the course content and instruction have worked out pretty well in my case. What seemed like a hodgepodge of disconnected learnings helped me prepare for my career.
Or perhaps I was just lucky like that kid in ‘Slumdog Millionaire’.