Letter #1 — Dawn of an education

Dear X,

July of 1993, I am studying at Nowrosjee Wadia College for my Bachelors of Computer Science. Ours was a relatively new department in one of the oldest colleges in India. Computers were a novelty then and being a Computer Science student was a matter of immense pride. Part of our curriculum necessitated that we do labs in the form of completing programming assignment. As with all early stage education initiatives, budgets were limited and most students couldn’t afford a PC (Personal Computer). The Department paired up students who would sit together and complete lab assignments in a common lab at the college.

This was my first introduction to team work

The students were paired up based on their last names, and my lab partner was Navneet. Our lab had about 20 PCs with 2 of them being IBM PC/AT the others being 8085/8086/8088 chipset. The PC/AT had an Intel 286 and a whopping 256 Kb of RAM, with a hard disk of 20 MB. Since there were only 2 of these PCs, they were highly coveted. My lab sessions were scheduled for 7 am weekdays, and I used to stand in line at about 6 am to get on this PC.

Day one of lab, I get the PC/AT, and Navneet joined me shortly. His reputation as a savvy computer programmer preceded him and I was already in awe. He asks, “How do you want to do do this? We could take turns typing our own assignments and running it. Or we could do this together where one of us types, complete it quickly and get out of here fast?” I mutely nod “latter option” and we were off to the races. The first programming assignment was to be completed in C and I watch Navneet type out the program. Our first assignment was to implement selection sort He starts typing out the code and talks through his process as he implements. He lays down the logic with the needed for loop, the if conditions and then function definitions. I am mesmerized by how fast he types, and at that stage he was the only person that I knew of who could hit Ctrl+Alt+Del with one hand. His process for writing code is still a work of art. Tiny things like typing in a {....} block for every if , for , or while loop before writing a single line of code within the block. Even if the block had one line in it, he enclosed it within an explicit {}. This habit I carried over to C++/Java and has helped me immensely over the years. There are many other traits that I picked up working with Navneet, but the below was the one I remember the most

Detailed comments and clear articulation of logic.

Another classmate of mine was Shashank. He is one of the most gregarious and generous human being, I have had the honour of interacting with. He has always been genuinely happy at the success of others. When someone got their first job or scored high, he’d be the first to congratulate them. He’d spend time answering questions with nary a complaint. One of my best memories of Shashank was when he invited a lot of our classmates to his house to watch the 1996 World Cup Cricket Quarter-final between India and Pakistan. “Operations Research” was one of our subjects which was a notoriously difficult one to grapple with. So much so that I called it Statistics++. We had a programming assignment to implement the Simplex Method. I was struggling to get an implementation complete. Shashank generously offered to share his code and help with implementation. I looked at his implementation, extracted parts of it to C functions, made appropriate function calls, and completed my assignment.

This was a lesson in DRY before DRY was a thing

Summer of 1997, Sybase was an upstart company which was challenging Oracle in the RDBMS market. Sybase had beaten Oracle to the punch when they introduced DB Triggers before Oracle did. I was fascinated at what triggers could/would do and was discussing the implementation and features with my classmates. Suddenly Navneet pipes up —

What happens if the update on Table X triggers an update on Table Y; and the update on Table Y, triggers an update on Table X? How long do the triggers run recursively?

I had no answer to that question, but tried the exact scenario. Found out that the recursive triggers' calls break after 32 mutual invocations and the database does not get into an infinite loop

Try and break the system with corner cases

Takeaways

Technical Takeaways

1. Pair Programming: Learn from observing others write code
2. Form clean programming habits.
   - Every time you start a block, add an end block almost immediately, and then fill in the logic for the block. Modern day IDEs which do this for us so we are constrained a lot less. Same principle applies for other resources.
   - Every malloc/new should be immediately succeeded by a free/delete ; and then business logic gets written between the block
   - A connection.open() should be succeeded immediately by a connection.close() before inserting code above the close
   This pattern of writing code will help with fewer memory or connection leaks. And most importantly, you would be spending lesser time debugging gnarly resource contention issues.
3. DRY( Don’t Repeat Yourself): Find ways to refactor and reuse code instead of reinventing the wheel.
4. Question the status quo: Do not be satisfied with just the happy path alone. Plan to test every possible corner case you can think of.

Leadership Takeaways

1. Teamwork: You cannot do everything by yourself. Lean on your team-mates and lean-in as well
2. Be generous with your time: In the process of helping others out, you might learn something from them. Even if you don’t gain much, you’ll gain their goodwill

Adios until the next letter
-Kartik