Letter #3 — The Impavid Imposture


Dear X,

It has been a while since my previous letter. Life got in the way hence the delay. One lesson that is hard for me to follow, but I still share with everyone

Explicitly set aside some time for your passion(s)

In my previous letter, I had mentioned having a strong Work Ethic as a necessary attribute for a successful career. To clarify without belaboring my point, the perception one gives off is as important as having a good work ethic

My first exposure to GUI was Windows 3.1. There was a paucity of resources in college so in any given year peripherals, keyboard, mice, trackballs, etc were shared by hundreds of individuals. Which in turn resulted in the devices breaking down. There was a 6 month period wherein we had to use 5 different Windows’ machines with a non functional pointing device i.e. the mouse and/or trackpad remained unusable. During this time I learnt to navigate Windows by just using the keyboard. I have carried forward the same habits today. Every time I start using a new IDE or Software, the first thing I do is explore the keyboard shortcuts.

15-July-1997, I join Mahindra British Telecom (MBT) aka Tech Mahindra in its current incarnation. The interview process for getting into MBT was as follows

  1. Aptitude test
  2. Interview

I cleared the aptitude test and was on a short list of about 5–10 people for the interview. Suchet Dabadge was on the interview panel and I vividly remember the questions he asked. All his questions were around databases and SQL queries. The SQL part of the interview consisted of

  1. Join, inner join, outer-join, left-outer-join, right-outer-join, union, triggers
  2. Normalization — 3NF, Boyce-Codd Normal Form
  3. Constraints and Indexes

It would not be a stretch to say that I got my first job primarily based on my SQL skills.

In spite of all the NoSQL movements that have happened since, SQL stands tall and is still the undisputed champion of data querying and processing technologies.

Mid-90’s was when the world was in the throes of Y2K. Upon joining the company, I was put on a training program which taught me programming in COBOL, JCL, CICS, and a host of other tools/languages used on IBM Mainframes. I spent about 6 months on the torturous training regimen of learning all these tools. At the time, it was an immensely frustrating experience. Having come freshly out of college and reading Ayn Rand’s books — The Fountainhead and Atlas Shrugged, I felt it was beneath my dignity to work on anything that was not C/C++ or more system level programming. The sense of entitlement I carried from being an enlightened objectivist had me quoting things like

“I swear by my life and my love of it that I will never live for the sake of another man, nor ask another man to live for mine.”
Ayn Rand, Atlas Shrugged

Towards the end of my training, I got assigned to a project which was building a CRM front-end for British Telecom. The CRM was called SMART. The UI was built in Visual C++ with the back-end in Mainframes and Oracle. I felt I was getting back in the groove of working with my core strengths and passions. I was colossally wrong about the project playing my core strengths. The work involved more than just C++ . The next 2.5 years I worked on technologies all through the stack, building code working with CICS, IDMS, C++, CORBA, SISS and a host of other technologies that I had learnt in the first 6 months of my job.

Go as broad in your learning approaches as you’d go deep.

My boundaries were breached, and expanded at the same time. The first 3 years of my professional career were memorable for not just the technical lessons, but the human and cross-functional ones. It was humbling in more ways than one. The specious feeling of invincibility that I had built resulting from my reading of Ayn Rand’s works eroded (rightfully).

Working in Science and Software is immensely humbling; and keeps me curious and hungry.

Of all the algorithms I’ve learnt in college, there is only one I’ve had to implement from scratch for a custom business need; in the year 2020. Not Quick Sort, not Bubble Sort, not Binary Search, not B-Tree Balancing. Libraries exist for all these algorithms which solves virtually all use-cases. But for the business case I was building, I needed to write my own custom implementation of Control Break Processing. Control-Break is implemented in databases where the SQL query execution does it for you as you specify the group by clause with the appropriate summations. I had never envisioned that the algorithm I learnt in 1992, and reinforced in 1997 would end up being implemented in 2020

A solid understanding of foundational algorithms is invaluable and essential

“My dear Frodo!’ exclaimed Gandalf. ‘Hobbits really are amazing creatures, as I have said before. You can learn all that there is to know about their ways in a month, and yet after a hundred years they can still surprise you at a pinch.”

Highly relevant even today, the Mainframes’ ecosystem(s) have solved a lot of modern day problems way back in the 70s and 80s. Today the internet and servers are amok with things like HTML, Server side processing, Job Processing, Network Databases, Multi-tenant processing, Rate-limiting, Circuit-breaking, etc.

SMART Architecture

SMART was a CRM which was implemented in Visual C++ and communicated with Mainframes through one of the 2 channels:

  • TN 3270 — A Terminal client
  • SISS — A TCP protocol. SISS was the primary transport TN3270 being a backup transport.

Architectural highlights

  1. Redundancy was built into every layer starting with Transport. If one transport layer failed, the client switched over to an alternative
  2. Mainframe processes were rate limited. Processes which took long time to run were terminated. Blocking processes were terminated and teams were forced to fix or production deployment was reverted
  3. CORBA-style calls were implemented throughout to have redundancy in RPC providers

When we built a new feature for the CRM product, following is the process we would go through:

  1. Identify the fields/attributes that are needed on the front-end to implement the business requirements
  2. Identify the CICS Transaction(s) that are needed for the business. A CICS transaction is equivalent to SQL stored procedures
  3. Identify the CICS-MAPs associated with the transactions. A CICS Map is the interface into and out of the Transaction
  4. The CICS team would then implement the changes and we would implement calls from the front end.

To my knowledge, we’ve never had breakage of functionality because of bad CICS maps. The MAP design was a critical part of our design process.

Every component in Mainframe architecture has a current-day equivalent

  • HTML+Javascript = CICS Transactions
  • HTML Form/API Interface = CICS MAPs
  • Server side processing = COBOL handlers for CICS maps
  • Network Database = IDMS
  • Python and Tcl/Tk = REXX
  • Microservices = CORBA style services

Every time I see an invention announced proudly as if it is ground breaking, I check back on my notes and see what existed in the Mainframes’ ecosystem.

As like the Hobbits, I am always surprised at what I find.

Those who cannot remember the past are condemned to repeat it — George Santayana

There are a lot that can be learnt from Mainframes, but too much nostalgia is bad. If we use nostalgia as a comfort food, we’d live in the past only, forget to live in the present and stagnate innovation for the future. A Raspberry Pi today is more powerful than the Mainframes of yore and does run COBOL as well, but it does not mean we keep MVS alive artificially.

During my stint at British Telecom, I learnt a great many things. My boss Abhijeet Kelkar, was a task master; and also a great human being. He used to invite us home regularly for lunch and/or dinner and we used to socialize off-work quite a bit. He was genuinely interested in the people who worked for him and worked with him. The one lesson I take away from my interactions with Abhijeet is to “make it a point to know your co-workers outside of work”. This has been beneficial to me in more ways than one.

Once a teammate of mine uncharacteristically started behaving a bit erratically, like missing deadlines and getting snappy in meetings. It helped that I knew the reasons behind his sudden change of behavior, and the team as a whole could de-escalate most of the incidents. Eventually he did leave the company, but not for lack of effort on the team’s part. I have lost touch with a great many friends/colleagues/peers but make an effort to reach out to them privately; just to check-in with them.


Technical Takeaways

  1. Build redundancies: Have redundancies in all components of your stack. Have at least 2 pathways to a destination. In case of microservice implementations, deploy at least 2 instance of the same service running for failover
  2. Rate Limit: Do not let long-running server processes block resources. Implement timeouts on the server side to deal with errant client requests
  3. Interface design: The interface is a binding contract and treat it as such
  4. SQL is here to stay: Anyone who says otherwise is misguided. Do not shy away from learning SQL as it is a vital technical skill

Leadership Takeaways

  1. Stay humble: You know a lot less about a lot more than you think. Be curious and open minded
  2. Learn from the past: There are a lot of technical problems solved by previous generations. We stand on shoulder of giants, so it is worthwhile reading up on computer history
  3. Foundational Knowledge: While you may never need to implement basal algorithms like Quick Sort, Binary Search, or B-Tree balancing; it is immensely helpful to understand how they work. A good understanding (not rote memorization) of fundamental algorithms is the foundation upon which good engineers thrive
  4. Network with peers: Whether you choose to be an Individual Contributor or become a manager, your success and growth is very much dependent upon the relationships you build and carry over from your previous jobs.
  5. It pays to be kind: Even if you have a difficult team-mate or a tough manager, be kind. Do not burn bridges. There have been many cases where unexpected peers from my past were generous enough with their references.
  6. Efficiency: Explore efficient and smarter way to do things as you start using new software and frameworks. However do not compromise maintainability/readability for brevity

Let’s see what the next letter brings




Views expressed on this blog are solely mine and not those of employers, past or present.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

The Great Resignation & The Future Of Work: Gissele & David Taraba Of Maitri Centre for Love and…

On the Shoulders of Black Tech Giants

Celebrating The Sunshine

Photo of a sun setting with trees in the foreground

Grant Gochnauer: Awesome Humans — Issue #174

Web misri hackingmykid 740x493

How our Students Recreated the Careers in Code Website

Rising cost of living Desire ©.

Why Steve Jobs’ Personality Made Him a Great Leader

A light bulb with dirt and a budding plant within it

Degradation on the job: How to defend yourself

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kartik Lakshminarayanan

Kartik Lakshminarayanan

Views expressed on this blog are solely mine and not those of employers, past or present.

More from Medium

Why Amyst?

Implementing resiliency at the edge

Let’s Do Some Networking!

Saved by the Ford Model T