My Dad is a retired Civil Engineer. He worked most of his professional life for the federal Government of India, for its telecommunications organization (Department of Post and Telecommunications, later split off into Department of Telecommunications). He built countless buildings that housed telephone exchanges, telecommunication network equipment, offices for the organization, and housing quarters for its employees. He also ventured to remote parts of the vast country of India to set up telecommunication microwave towers. Of late, several years after his retirement, we two have had a chance to step back and take stock of what he enjoyed during his long career and what he proudly reminisces on.
My world as a Computer Scientist, or Computer Engineer — I have the two-faced Janus syndrome on whether I am a scientist or an engineer — has always seemed far removed from my Dad’s world. But with clarity that comes with distance, I have begun to realize there are three things that I have picked up, unwittingly, through osmosis as I sometimes went with him and Mom to his work sites. And I have adapted them to my far-removed world of computing.
- Build for the ages
- Test, test, test till you are ready to put your reputation behind it
- “No cigarettes please”
1. Build for the ages
The buildings are meant to survive, nay thrive, for many many years. Therefore, you put the best material in building them, your best talent in designing them and verifying their durability. And decades later, when driving past one of them in our home town, you can point to them alike with pride in your voice and mist in your eyes. Or when flying to a distant city for a vacation and on a drive you see the imperious microwave towers that have stood tall for decades and brought connectivity to far-flung corners of the vast country that India is.

Now how does that translate to our often brittle world of software? To me it means you develop code that you know will be used in far-flung contexts and by people who do not look like you. And that code should stand up and work as they have been told it would. Anticipate the unexpected, the unexpected interactions with hardware or with other pieces of software or users who with wondrous human unpredictability will behave outside of the specifications. And build your software to stand tall in the face of such unexpectedness. In the less-complicated days of my Dad’s professional life, he did not have to worry about malicious attacks against his buildings. But in my world where I work on secure software systems, being resilient to malicious attacks is another dimension that I design for. So, whether buildings or software, the principle of building for the ages, overly grandiose though it may sound, holds us well.
2. Test, test, test till you are ready to put your reputation behind it
I remember Dad climbing up these towers or tall buildings to vertigo-inducing heights on wobbly spiral stairs to run his structural tests. He could easily have relied on his reports to do all of that, but he did not. Later on, when software became the standard for designing such structures, he took to using simulation to do some testing, reluctantly at first. But he never gave up on the comforting familiarity of touching the structures and pushing and pulling on them to satisfy himself. He told me that he would test under various extreme circumstances — unexpected large number of people on a floor, large number of people on a floor stepping in unison, high wind speed, high wind speed while there are a large number of people. Going back to the first item above, he meant these structures to stand for many decades, knowing that what is unexpected today may well become the expected tomorrow.

Translated to my work with software systems, this means testing by various means, for various corner cases, for various corner cases in combination. Subconsciously, my choice of research area as reliable and secure systems may have been driven in part by my observations of how Dad approached life, at work and at home. In our software industry, there are some weirdly good software testers. They are not the best at developing software, but give them a complex piece of software and they are wizardly in their ability to find weak spots in them. Such people are in great demand and the Gen AI surge has increased their demand, if anything, as they can spot weaknesses in AI-generated code as well. My far-less-wizardly abilities in generating test routines is influenced in part by how I saw Dad approach structural testing.
3. “No cigarettes please”
This is a throwback to a fixture of office culture in India till even the 2000s. You go to meet someone in an office — I can speak knowledgeably of government offices — and to get things started the person in the office orders tea (“chai”) for all in the meeting. A bell beneath the desk would be pressed, which would summon a “peon” (a rough culturally relocated term is an office attendant), who would be asked to bring the requisite number of cups of chai, and which would arrive in about five minutes from the office canteen. Now the person who has come to visit would offer the government officer a cigarette and the preliminary idle chit-chat would happen sipping chai and puffing on the cigarettes. India is notorious for corruption at low to mid-levels of government. It has languished for years close to 100 in the ranking of the Corruptions Perception Index by Transparency International which is a proxy for assessing the level of government corruption for each economy.
The proffering of the cigarette would sometimes be a prelude to the substantive forms of inducement: a family dinner invitation to a swank restaurant or a couple days of getaway in a local resort, and moving up from there. For Dad, he was handling building contracts of significant amounts and the building contractors would have to meet with him quite regularly. Knowing the slippery slope from the cigarette, he would for most of his work life refuse even that. This would cause in the other person, either confusion or consternation to start, but over many interactions, this would transform into respect. Respect earned like that persists for life, way beyond when these people had anything to gain from Dad.

This one does not translate directly to my technical work, but influences my world view. If there is an ethical slippery slope even in the distant horizon, I don’t venture anywhere close to it. One form of this is consultancy that companies would come to me with for patent litigation. Another form is research contract where there is requirement on what I should say or cannot say about the product of a company in a benchmarking study. If any of this smells even remotely fishy, I run. Pablo Escobar cynically said, “Everyone has a price, the important thing is to find out what it is”. From Dad I got that that price can be set to infinity.
To sum, the world my Dad inhabited in his work life — dusty file folders for structural civil engineering in a federal government department in the developing world of India — is light years away from my current world. And yet, certain principles that I picked up, unknowingly and that I assimilated through years of quiet observation, have surprisingly colored my work and my world view. These principles have made the translational journey across geographies, cultures, and professions remarkably well. Do I know what such principles are that I am unwittingly passing down to my next generation?