The irony is tragic. We cling to the past as our only roadmap, hoping it will shield us from future pain. Yet, in our refusal to face the present, we mentally transport ourselves back to the original wound and relive it over and over. We are essentially cutting off our nose to spite our face, inflicting the very pain we seek to avoid, just to feel a semblance of control. In this grand act of escapism, aren't we losing the only moment we actually have?

Why does a loss in the present cut so deep? It is rarely just the loss of a single person, plan, or possibility. It is the slamming of a door on a part of ourselves. Imagine the self as a vast residence, a mansion of many rooms. Every connection we make, every dream we nurture, every path we choose grants us access to a new chamber, a space where a version of us comes to live. To experience loss is to hear those doors slam shut. Sometimes it’s a temporary closure, a draft from a window we might open again. Other times, the door is sealed forever, and the version of us that lived in that room is now, suddenly, homeless.

Yet, vulnerability has a cruel sense of timing. Moments arise when we feel a pull to peek through the keyhole of those sealed doors. In those moments, we might find someone else standing there, sheepishly attempting to uncover the mysteries we have promised ourselves we would never unveil. They are disguised as a new opportunity, a new face, a new chance. We would rather deny these visitors entry to our haunted house, because to let them in would be to scab an unhealed wound, to let the blood we’ve worked so hard to contain spatter across the floor of the present.

And so, the cycle tightens. Why is loss so unbearable that we would rather lock ourselves in the foyer than risk another opened door? Why do we try to control people, plans, and possibilities as if they were sand in a fist? Perhaps it is because we believe that if we grip hard enough, we can prevent another door from slamming. But the tighter we clench, the faster the sand slips through our fingers, leaving us with nothing but the sting of our own nails digging into our palms. An empty hand, and a self-inflicted wound.

When this sense of wounded homelessness kicks in, is there a place in this abode where we can rest? Is it possible to keep the rooms from becoming haunted while we gather ourselves back up? What if those sealed chambers could be transformed, not into crypts, rather into spaces as welcoming as a freshly cleaned hotel room, bright and fragrant, ready to welcome new guests? Instead of standing guard in a frenzy, panicked at the idea of theft, we could simply open the windows and let the light in.

That, perhaps, is what healing is meant to help us with. Early in the journey, the idea of bringing light to the parts of ourselves we don't know how to deal with, the rooms we have let go barren in darkness, feels less like a practical task and more like a piece of abstract philosophy to decode. It is only with time, with patient care and a deep understanding of one's own self, that we learn to inhabit this idea. We learn to exist with compassion in a strange world that was never meant to be fully controlled.

One of the key acquisitions on this journey is the art of letting go of resistance, the need to fight the present or rail against the changes forthcoming in life. Resistance to something being actively lost, or to a thing not working out in our preferred way, does not save it. It never does. But it does guarantee something else: it turns into mental agony. It calcifies into feeling stuck, anxious, ruminating. It traps us in a loop of overthinking, over-analyzing, and over-rationalizing. These are all forms of self-harm, quiet ones that take up residence in the body, rooting us firmly in the past and making the return to the present feel like an impossible journey home.

This resistance can take an even more severe turn when the suffering becomes coupled with the ego's desperate need for validation. When that happens, the suffering is no longer content to stay within; it seeks company. The goal shifts from healing a lost cause to winning a game. To the one holding the pieces, this state can feel like a fun place to be — an illusion of power, a throne built on the rubble of a broken situation. Yet, games are only fun on boards or in sports. In life, where every person we encounter is simply another soul in another body, these games work against the very compassion we could be showing up with. They become a hollow performance of superiority, a distraction from the simple truth that we are all just trying to find our way back to a well-lit room.

Conversely, when a loss becomes tied to one's sense of self-worth, the act of recovery turns into a desperate chase. In the aftermath of a breakup, for instance, this anxious pursuit manifests as excess — excessive giving, excessive emotional nurturing, excessive gifts. It shows up as a need to reopen the closure discussion again and again, depending on which way the emotional tides are pulling. Yet, this situation rarely ends in recovery. More often, it leaves a person looking like a doormat, while their own emotional state is trampled in the rush to prove they are worthy of staying.

These unyielding complexities, these knots we tie ourselves into are best unraveled not by pulling tighter, but by pausing to see where the thread is going. There is a quiet power in simplicity. Being simple in nature and allowing things to remain as they are ensures they lead to their natural outcome. It is better to surrender the outcome after doing all that was truly within one's power.

For what is lost.
For what could have been.
For what is yet to come.

When we accept the lost cause for what it is, when we come to understand that life is merely a series of good phases and bad phases woven together, the view shifts. We stop looking through the microscope at the tiny details of our pain and start seeing from a bird's eye view.

This acceptance means coming to terms with the old version of ourselves, and the old version of others. It means acknowledging how our perception of what could have been colors the reality of what is. It means understanding that the change in dynamics, the shift in individualities, fundamentally alters how things will now be. And perhaps most crucially, it means recognizing that we are not always meant to receive the whole picture at once.

Sometimes, we are sent only a fragment of what we desire — a single room instead of the entire wing, a glimpse instead of full entry. This fragment is not a cruelty or a mistake. It is a test, a quiet measure of whether we are ready for the rest. Can we hold this small piece with gratitude, trusting that what is meant for us will not pass us by? Or will we spend our energy mourning the rooms that remain closed, missing the one that has just been unlocked?

When we finally stop oscillating between the past and the future, we arrive at the purest form of reality: this moment. The rest are just projected realities, illusionary stories that kill the present moment with the complexities of our own thoughts. From this place of quiet, we can look back at what we have lost, and forward to what we have not yet met, with something softer than fear.

We can call it gratitude. We can call it hope. Or we can simply recognize that there is so much still to see, to feel, and to become. And none of it was ever limited to what we could hold in a clenched fist.

I don't know if the journey ends in a well-lit room, with windows open and gratitude in my chest. As I write, I still recall the despair of standing in rubble—when loss takes everything like a tornado devouring even the strongest foundations. The uncertainty that kicks in when one day you wake up to find the front door slammed in your face.
And yet, knowing all this, I cannot say how the journey will unfold when something shatters again. Someone could leave. Something almost understood could turn back to exclaim the big misunderstanding. A door I thought sealed could crack open and reveal more darkness. I don't know if I will remember any of this.
Still, sitting here right now, the fist is unclenching. It's simply because a clenched fist cannot hold anything - not grief, not hope, not another person's hand, not even a new opportunity.
That is all. That is everything. That is nothing.
Hopefully, I too can return to this piece when the time arrives.

I see this all the time. We find a solution that works for us - maybe it's walking, a specific productivity hack, or a particular diet. It becomes our truth. So when we see a friend struggling, we hand them our solution like it's the only map out of the woods. "Here," we say. "This is the way."

So, what happens when your friend is sad, and your belief system says therapy would be a life-saving raft, but they're just not ready? Perhaps they are too weary or afraid to grab hold, so they push it away?

The easy, dogmatic response is to get frustrated, to think, "Well, I gave them the answer. If they won't listen, that's on them." We walk away, confident in our "rightness." But our friend is still sad. The problem isn't solved. And we've failed the one thing that mattered: actually helping.

This whole train of thought finally led me back to the beautiful concept from Jain philosophy called Anekāntavāda^[2], which humbly states that nothing has just one side.

Anek (अनेक्) = "Not one" or "Many"
Anta (अन्त) = "Ends", "Sides", or "Aspects"
Vāda (वाद) = "Doctrine", "Theory", or "School of thought"

It is simply translated to "no-one-perspective-ism" or "many-sidedness".

There's a classic parable of a few blind men describing an elephant. One man touches the leg and says, "An elephant is like a tree!" Another touches the trunk and says, "No, it's like a snake!" Another touches the tail and insists, "You're both wrong, it's a rope!"

They're all correct from their own limited experience. But they're all completely wrong in their absolute conclusions.

Hence, the friend's sadness is a complex reality aka the 'elephant' of suffering. It has psychological, social, biological, and spiritual dimensions. Thus, the solution can have many sides, here that is, professional therapy, compassionate listening from a friend, exercise and diet, spiritual comfort, or simply having someone who doesn't give up on them.

We all can exhibit the qualities of a blind man. When we choose to cling to the one "right" way to help, we're just touching one part of the elephant and ignoring the friend's side of the story, that's their fears, their history, their unique perception of reality.

So, what's the antidote?

Jainism offers a practical tool for this called Syādvāda, or the "Doctrine of Maybe." It sounds philosophical, but it's incredibly down-to-earth. It just means adding a mental "maybe" to your convictions.

"Syāt" means "from a certain point of view," "perhaps," or "maybe."

This tiny word is a game-changer for human interaction.

Instead of telling our sad friend, "You need to go to therapy," we can instead think:

"Maybe therapy is the best long-term solution."
"But maybe, right now, what they really need is something else"
"Maybe, if I ask them, they will tell me to just sit with them and watch a feel good movie."
"Maybe being a steady, non-judgmental presence is the help I can offer today."
(Cue is to ask them)

It transforms the conversation from a command to an exploration. It replaces "This is the way" with "How can we figure this out together?" It transforms us into a partner instead of a preacher.

This shift does one more vital thing: it holds us accountable for our impact, not just our intention. We can have the purest intention in the world - to save our friend with the perfect solution. But if our rigid action pushes them away, the impact is harm and hurt. The moral failure isn't in our intention, but in our refusal to correct our action when we see it isn't working.

Anekāntavāda teaches us that our first perspective is limited. Syādvāda gives us the humility to admit when our initial action, however well-intentioned, was a mistake. This is where we often get stuck: admitting our action caused harm feels like admitting we are a bad person, when it just means we're human.

I'm learning to be less in a state of a static 'problem solver' and more in the dynamic loop: act, observe the impact, and if there's hurt, find the flexibility to fix it. It’s the work of making sure our actions align with our ultimate intention: to truly help, not just to feel like we were right. It could look like saying:

"Let's put my ideas aside for a moment and focus on what you need to feel comforted right now. We can tackle the rest when you're ready. Your well-being is the only goal."

This ancient wisdom has completely reframed how I think about helping and approaching relationships in many aspects. It isn't about having the perfect answer. It's about having the humility to know that my answer is just one part of the truth. It's about prioritizing the person over the principle, the connection over righteousness, and openness to perspectives over dogmatism.

Perhaps, this path would lead us to be more morally effective, and have the pragmatic humility and a commitment to repair that evolves our inter-personal relationships to be more nurturing.

[1] Moral Competence by Evan J Conrad
[2] Anekāntavāda: The Relativity of Views

However, AI doesn’t understand organizational rules or know your team’s error-handling conventions. It forgets your patterns unless you either repeat them, or cache them into context - consuming a ton of tokens regardless.

Left unguided, AI-generated code creates entropy and scales poorly. A codebase where every function looks different, debugging requires archaeology, and "it works on my machine" becomes the standard. Hence, job descriptions have switched from finding engineers who just write code to ensuring code behaves as intended.

1. Contract > One-shot Coding​

We stopped asking devs to write Lambda handlers. Instead, I built a [framework] that helps the developer focus on writing the business logic, by handling the plumbing. The first deploy works every time. What used to take hours to weeks, now is done in a day on average.

Now, when a developer (or their AI assistant) scaffolds a new service, they don’t write plumbing. They implement a strict interface. The logging, retries, tracing, and error normalization are enforced by the framework, not by convention.

Why this matters in the AI era:

AI is great at filling in blanks. It is terrible at maintaining architectural integrity across 50 microservices, if not given the proper infrastructure to work with. By hardening the [framework], I ensure that whether a human or an AI writes the business logic, the system behavior is identical.

A new hire ships on day three because the system is designed to onboard them fast without needing to understand the full system yet.

What would have just been a 4x multiplier, is also maintaining the system's integrity.

2. Zero-Cognitive-Load Adoption​

We built an invisible architecture in a system. Product teams across AAA adopted it without having to sell it to them, or asking anyone to attend integration workshops.

In a world where AI can generate infinite features, the bottleneck isn’t creation, it’s integration. When your internal tools require meetings, docs, or config files, it's natural to meet more resistance to adopt. This invisible architecture adopts itself because it offers immediate value with zero cognitive load.

This idea holds value in different forms across unique systems.

3. Eradicating Bug Classes and Data Corruption​

We had a silent data-loss bug in MongoDB. An AI might fix the specific instance. A senior dev might patch the service.

I fixed the client.

I wrote [21 LOC] and injected it into our shared database layer. Now, no one — human or AI — can write code that overwrites data. The entire class of this bug is extinct. This is the difference between coding and engineering. Engineering eliminates the category of error. Coding alone might just hide the symptom.

4. Design for the 3AM Page​

Our sync jobs used to page us at 3 AM. We replaced them with self-healing state machines. They retry, back off, and recover automatically. Now, there's hardly a page in a year.

AI can write a cron job. It cannot easily design a system that anticipates failure modes, handles race conditions, and recovers without human intervention as it requires deep system understanding. To even address the problem, it requires empathy for the person on call.

5. Descoping is a Design Tool​

Every quarterly planning cycle starts with multiple feature requests for various epics. Since AI is endlessly generative, it will happily write all the code. It doesn't mean it should. With no concept of ROI, AI doesn't ask whether a feature deserves to exist.

What you don't build matters as much as what you do. Every line of code can become a liability. It needs tests to write, a feature to maintain and if anything breaks, a bug to fix, and a potential page at 3 AM.

Engineering judgment is the filter against that entropy.

What can we remove? What can we simplify? What shouldn’t exist at all?

A descoping pass ensures product is built for its end-users, not for AI's generative capacity.

Conclusion​

In an AI-first world, velocity is becoming cheaper, and code is treated like a commodity. Integrity is what compounds here, especially when consistency is the spine.

Instead of being the hero who leaves vacation to fix breakage, I like architecting systems that can detect breakage and self-heal, so that they work even when no one is watching.

P.S. Across the system’s lifetime, during my role at AAA, this pattern has saved an estimated ~4,000 developer hours, and continues to compound by eliminating repeated fixes, debugging effort, and inconsistent behavior across services.

A Community Born from Necessity

I was three weeks into university when I realized something was missing. The campus buzzed with tech clubs, sponsored by names everyone recognized (Mozilla, Microsoft, etc), but their calendars were filled with formals, branding events, and administrative formalities. Actual conversations about code, systems, and the open‑source philosophy were rare.

I wanted a space where computer scientists could simply build, share, and learn without hierarchy. A place where a first‑year student could sit beside someone who’d been contributing in tech for years, and both would walk away having taught each other something.

Inception​

In ALiAS, what mattered first was the gathering. A few of us began meeting in empty classrooms, running installation fests, and talking late into the evening about kernels, pull requests, and why open source mattered. Shyam Saini and Shivam Rajput were there from the earliest conversations, confirming I wasn’t alone. Over the next few months, others joined, each drawn by the same hunger for genuine technical community.

This is how ALiAS, Amity Linux Assistance Sapience, was born. A name that captured the identity we were creating for tech enthusiasts who believed in open source, accessibility and exploration.

From those small beginnings, ALiAS grew into something larger than any of us expected. But the foundation was always the same: a flat, inclusive space where curiosity mattered more than credentials. Our vision was simple, to create an accessible environment where collaboration, knowledge sharing, and personal growth could happen naturally, without the barriers that often fragment student communities.

Roles and Responsibilities​

A strong community needs structure to direct the immense energy sparked from enthusiasm. For this, ALiAS was designed around a flat hierarchy, deliberately avoiding rigid titles so that members could take ownership of areas aligned with their strengths. This approach allowed me to delegate strategically while ensuring that every aspect of the community received focused attention.

• Community ethos and leadership – I entrusted key members to uphold the vision in day‑to‑day decisions, providing guidance while allowing them to lead in their own style.
• Inclusivity and communication – I personally shaped the communication framework and inclusivity practices, setting the tone for how we onboarded members, handled conflict, and made sure every voice was heard.
• Technical development – I established a technical mentorship structure, pairing experienced contributors with newcomers to maintain high code quality and encourage knowledge transfer.
• Event logistics – I designed a workflow for planning and executing events, empowering members to run operations while I oversaw alignment with our long‑term goals.
• Content and documentation – I created systems for documenting our work and creating accessible learning materials, ensuring that knowledge outlived any single event.
• Outreach and partnerships – I led external engagement, connecting with industry mentors, faculty, and organizations to expand our network and bring new opportunities to the community.

⠀This structure gave each area the focused attention it needed while keeping the organization agile—and it allowed me to scale my impact by enabling others to lead within clear guardrails.

Growth and Milestones​

From small workshops to large‑scale annual events like Hacktoberfest, I deliberately chose activities that would build both technical skills and a sense of shared purpose. Some of the initiatives I launched or led include:

• Monthly Linux Installation Fests – Introducing students to Linux and helping them get started with a powerful open‑source environment.
• Daily Tech Meetups – Creating a regular forum for discussing the latest technological advancements and sharing insights across the community.
• Community Calls – Establishing a rhythm of planning meetings to continually refine ALiAS’s direction and expand its reach.
• Specialized Study Groups – Organizing peer‑led groups in areas like frontend development and machine learning, with support from faculty collaborators.
• Annual Hacktoberfest events – Introducing students to open‑source contribution and helping them make their first pull requests in a supportive environment.

⠀Beyond events, I also drove the creation of a community blog—a platform for members to share technical insights and experiences, which became a key tool for building our reputation beyond campus.

These efforts did more than grow numbers; they created a culture where students felt empowered to lead their own initiatives. I made it a priority to identify emerging leaders and give them the space to run workshops, mentor peers, and eventually start their own chapters elsewhere.

Linux Study Group with Prof. Priya Ranjan​

One of the most rewarding collaborations came through Prof. Priya Ranjan, a Linux enthusiast in the Electrical and Electronics department who had been running weekend study groups for years. We began co‑organizing sessions that combined his deep technical expertise with ALiAS’s growing community of learners. His ability to explain complex systems in simple terms left a lasting mark on how I thought about teaching and mentorship.

Overcoming Challenges​

No community‑building journey is without obstacles. Navigating university bureaucracy, engaging a broader student base in open‑source contributions, and addressing gaps in participation all required persistence and adaptability. Each challenge became an opportunity to refine my approach—whether it was learning how to negotiate with administrators or redesigning outreach strategies to reach students who hadn’t yet found a technical home.

Bridging Gaps​

Enhancing Women’s Participation in Tech Despite our growth, the gender ratio in tech remained skewed. Of the founding members, only two of us were women, and participation reflected that imbalance. I knew that passive inclusion wasn’t enough—so I initiated targeted efforts to change the dynamic.

I organized workshops and events specifically designed to welcome women into tech spaces, including Women’s Day tech talks featuring prominent contributors like Shivani Bhardawaj of LinuxChix India.

Beyond events, I started a personal mentorship program where I guided women students through career choices, skill development, and navigating the tech landscape. These efforts significantly boosted female participation and, more importantly, brought diverse perspectives into the heart of the community.

Impact​

The impact of these efforts became visible in tangible ways. ALiAS was recognized as the most active tech club on campus—a distinction that carried weight when I later advocated for curriculum changes. Working with faculty and administration, I helped make the case for introducing Python into formal coursework, a change that benefited students across departments.

Expansion​

The Rise of ALiAS Chapters The model we built—a flat, inclusive, student‑led community—proved replicable. When students from Amity University, Lucknow, expressed interest in starting their own chapter, I provided guidance, shared our resources, and helped them adapt the framework to their context. That first chapter became a blueprint, and soon ALiAS chapters began emerging across India, each carrying forward the same ethos of open‑source advocacy and community‑driven learning.

Looking Ahead​

Today, ALiAS has grown to over 4,000 members across multiple chapters. Students who once attended their first installation fest now contribute to major open‑source projects, speak at conferences, and mentor the next generation. The mentorship programs I helped establish, along with initiatives like GSoC sessions, continue to guide new waves of technologists.

Reflection​

Looking back, building ALiAS taught me that sustainable communities are built on clear systems, not just enthusiasm. I learned how to design structures that empower others while maintaining strategic direction—a skill I now rely on in everything I do. More than anything, I saw that when you give people ownership and hold a clear vision, they will surprise you with what they can achieve.

This journey also deepened my conviction that technology is at its best when it is collaborative, inclusive, and rooted in genuine curiosity. Those principles continue to shape how I approach problems, lead teams, and contribute to the open‑source ecosystem. ALiAS was never just a club—it was a proving ground for the kind of technologist and leader I wanted to become.

Embracing the Unexpected​

When high school ended, like countless others, I harbored certain dreams I believed that only through such accomplishments could I truly excel and achieve my aspirations. However, life had other plans, and my journey veered onto an unexpectedly rewarding path.

Discovering My Passion Locally​

The aforementioned setback steered me towards an equally fulfilling educational experience. It was here, amidst modest beginnings, that I found my true calling.

In September 2016, two months into my freshman year, our alumni organized a workshop that introduced us to Python, Linux, and the Kivy framework for developing Natural User Interfaces. This event wasn't just about coding; it was a gateway to the broader open-source community and a dormant tech club at our university, known as ALiAS. This club, they shared, was pivotal in their professional success and eventually was mine as well after I set on a journey to revive it which I have written about in the ALiAS section.

A Lesson in Community and Open Source​

The hands-on session in Linux and Python wasn't just about learning new tools—it was about understanding the ethos of giving back and collaborating.

I realized that Computer Science was more than day-to-day coding; it was about exploration, innovation, and community.

The stories from our alumni during the workshop weren't just inspiring; they answered a deep-seated question I'd often pondered during uninspiring high school computer classes: "Is this all there is to Computer Science?" The answer, resoundingly, was no.

Expanding My Horizons​

Inspired, I sought out more experiences. I attended the first meetup of ILUG-Delhi and soon after, joined sessions with PyDelhi and LinuxChix India. These groups introduced me to a network of experienced tech enthusiasts who were always ready to lend a hand or share knowledge. The core of these meetups—diverse tech talks—opened my eyes to the vast possibilities within the tech industry.

My Journey in Open Source​

I was particularly drawn to the open-source community, where I could contribute to projects that aligned with my interests and values. My contributions to Pandas and LinuxChix India are a testament to my commitment to the open-source ethos.

I have also volunteered to organise and speak at various tech meetups and conferences, including PyCon India, PyDelhi, and ILUG-Delhi. These experiences have not only honed my technical skills but also helped me build a strong network of like-minded individuals.

Recognizing My 'Luck'​

At each event, people would often remark, "Oh, how lucky you are!" to have discovered these groups so early in my career. While I appreciate their sentiment, I believe my 'luck' isn't merely coincidental. It's the result of my efforts to seize every learning opportunity, driven by a genuine passion for technology.

The True Meaning of Luck​

This journey has taught me that luck in tech, or in any field, isn't about serendipity. It's about hard work, community engagement, and the continuous pursuit of knowledge. Each step in this journey, from attending workshops to contributing to tech meetups, has reinforced my belief that when you love what you do, the right opportunities will follow.

Looking Ahead​

I am now looking forward to connect with like-minded individuals who share my enthusiasm for technology and community, and with whom I can explore new technologies, tackle projects, and enjoy the profound satisfaction of giving back.

Final Thoughts​

To anyone embarking on their tech journey, remember that your path might not always align with your initial plans. Embrace it. Sometimes, the unexpected routes are the most enriching ones. Indeed, I am lucky, not just in being in the right place at the right time, but in choosing to dive deeply into the opportunities presented to me.

When I was starting high school, I was at crossroads of chosing a stream of courses, as goes in the Indian education system. I had to decide between studying either economics or computer science. AI hadn’t yet become a household buzzword. My family, with roots in multi-industry business, saw computer science as a narrow, uncertain path, especially when not having enough examples in their experiences to validate the path. Economics, on the other hand, was respectable, versatile, safe and would most importantly keep the doors wide open, in a traditional sense, for all of business, academia and government services.

I chose computer science.

My reasoning was mainly a hidden passion with a flavor of practicality that computer science is a skill‑based knowledge. While I spent my afternoons and nights tinkering with my personal computer, I could see myself wanting to learn it deeply under structured guidance and practice. Economics, I believed, was something I could pick up later if I chose to run a business, through life. ^[1] I couldn’t explain this well at sixteen. I only knew I had to try.

The skepticism was polite at first, then persistent. “Are you sure? You might regret this.” I wasn’t sure, how well my statements made sense. I just knew I have always had a lovely relationship with computers and I would like to maintain it.

Years later, when high school was done where I had performed the highest in the computer science subject than any other, and now I was in uni pursuing my Bachelors in the subject, I came across an email that I would brush off in a first glance as spam.

I had been selected for felicitation by Narendra Modi, the Prime Minister of India at the time, for one of the early active participation in digital governance. The invitation felt surreal. I told my parents as they lived through their usual, rushed daily life, brushing it off as spam without even looking at the screen. Digital scams were really too active then and it was an extraordinary claim to accept when not having seen a physical evidence. So I didn’t go.

Weeks later, the ceremony aired on national television. My family was gathered in the living room when the segment began. There, on screen, were the dignitaries, the venue, the very event I had described. Looking at fellows get felicitated by the Prime Minister, my dad turned to me. “Why aren’t you doing such rewarding deeds?”

I exclaimed, “You called it a scam when I told you!”. A little sheepishly with a hint of pride they looked at the email that I hadn’t yet deleted.

Did my family stop questioning my plans after that? Not entirely. The pattern had started earlier, and it would continue.

In college, I threw myself into building ALiAS, a community for Linux and open‑source enthusiasts. I organized events, attended meetups, spent evenings in empty classrooms talking about kernels and pull requests. To my family, it looked like I was spending time and money on something with no clear return.

“Shouldn’t you focus on your studies?” they’d ask. “Is this really worth it?”

I didn’t have an answer that would satisfy them. I only knew that building something alongside passionate people felt more valuable than any grade. So I kept going.

Over time, the community grew. ALiAS became the most active tech club on campus. We introduced Python into the university curriculum. Students made their first open‑source contributions. Chapters began appearing in other cities. The recognition came, not just in awards like the Shri Baljit Shastri Award for being the Best in Human Values in my entire university, but in the quiet satisfaction of seeing me mentor others and help them come out of problems I was once drowned in.

My family saw it, too. The same relatives who had questioned my choice of computer science began pursuing master’s degrees in the field. The same parents who doubted the value of my “meetings” started asking about the next event. They didn’t apologize. That’s not how it works in an Asian household. But they no longer doubted.

My family, like any higher genration, wanted me to be safe externally while I was chosing it in trusting my own compass even when the map was unclear.

Now, when I make a decision that looks uncertain from the outside, I welcome the questions. They help me see perspectives I might have missed. The final direction comes from within.

Reflecting, when I see someone navigate a similarly uncertain path, I aim to offer what I would need, that is, trust without the wight of conditions.

Patience, though not easy, is well worth it when doing the slow, steady work of building something worth believing in.

Eventually, the evidence arrives on its own. You just need to show up.

[1]: Here, the value of economics in my life was put up for more on-ground applicability like running a business, rather than an in-depth understanding of the subject.