Writing is clarifying

The Hold

Wed, 22 Apr 2026 23:13:31 -0700

I have spent nearly a decade asking a few simple questions.

Why do people like Mahatma Gandhi, Desmond Tutu, and the Dalai Lama wear childlike smiles, unlike most adults in our daily lives, who wear stress and tension on their faces? Didn’t they go through much harder times than most of us?

Why do some people respond to setbacks with more elegance than others? Why do some people stand still in front of obstacles or back off when others find ways to crack those obstacles? Haven’t we all read the same books and heard the same advice? Yet, when the moment arrives, why does most such advice disappear?

When something we don’t like happens, self-saboteurs like blame, victimhood, judgment, and helplessness kick in. Where do those come from? What needs to change?

While I decorate my public profile with things I have done, degrees accumulated, and accomplishments, what about all the situations where I got stuck with routine things or had setbacks — like when I didn’t get the role I wanted, when the promotion didn’t land, when I thought I was ready, when the job I secretly hoped for didn’t land, or when an organizational change ejected me out?

I read all the usual self-help books from Dale Carnegie’s How to Win Friends and Influence People to Daniel Goleman’s Emotional Intelligence to Carol Dweck’s Mindset to Stephen Covey’s The 7 Habits of Highly Effective People. But where was my growth mindset when I was stuck? Why didn’t I stay present and emotionally intelligent when I needed them most, say, after a work situation brought an unpleasant conflict, and I showed how emotionally unintelligent I could be?

What makes all such advice and help go invisible when I need it most? Why? Is there a more fundamental obstacle that I have not been seeing?

Such questions led me from my day job in software engineering leadership to the psychology of leadership, biographies of some leaders, the neuroscience literature, the Ubuntu philosophy, the Upanishads, and eventually to Nāgārjuna’s Mūlamadhyamakakārikā and Yogācāra philosophy. My instincts for finding answers grew stronger as I delved into the abstract aspects of Buddhism, such as Śūnyatā (emptiness), Pratītyasamutpāda (dependent origination), and Madhyamāpratipada (middle way).

At first, things made sense, but I began to notice a major disconnect between those abstract ideas and the real world. Buddha taught Pratītyasamutpāda, but how could I deny my free will and actions? Nāgārjuna implored Śūnyatā, yet nothing in front of us seems empty. As long as I am alive, healthy, and living comfortably in a suburban home, why bother with the suffering that Buddha spent so much of his life addressing?

I kept digging deeper. I began examining everyday situations and behaviors. It was uncomfortable at first. I started working on myself. That’s when the fog started to clear. It still takes effort and frequent squinting, but the fundamental obstacle began to reveal itself.

The fundamental obstacle is not in front of me, but it is what I have been holding and defending. Years ago, I felt bullied by someone. I labeled myself a victim and moved on. On reexamination, I now see a silent judge seeking vindication behind that victim.

It is also what you have been holding and defending. Check when you were upset and raised your finger at someone who cut in front of you in traffic. Was the same you reading this? How about the situation when someone hurt you so deeply that you took months to recover inside? Or think of the situation when you cut your ties with a dear friend because they offered a different point of view of yourself that you didn’t agree with.

It is the notion that we have a stable self that can be coached, optimized, and expressed authentically. Call it the mountain. It has accumulated over the years, feels solid, and does not give way easily. It feels credible and dependable. It feels worth holding on to and defending because we built it.

What if we release that hold? What if we examine how those mountains are formed to detect that hold? These days, my best days are when I see the hold and loosen it. The series of articles I have been writing over the last few weeks (see the Mountain Series) is my attempt to explore what you and I have been holding and defending.

Some of the material will be difficult at first. You might even find me delusional at times, but I urge your patience. There won’t be listicles of advice — there won’t be a need since the root issue is simpler. But the journey shall be unsettling.

The Authentic Mountain

Sat, 11 Apr 2026 21:55:03 -0700

It is time to dig deep to tear apart the romantic idea that authenticity is showing up as yourself. Nobody knows what being yourself means except through the stories you tell about yourself. Here is what authenticity does: I’m this and that; hence, I showed up like this — this is a feel-good defense, a fortification of our mountain.

We are told to attain authenticity by being faithful to ourselves. There are leadership theories and self-help books to teach us how to be authentic. But there is no stored definition of that “being self” in our brains. Stories are all we’ve got, from the sandcastles to the mountains and the clouds.

It’s like turning a broken, smudgy pair of binoculars to your mountain — look at the peak, that is my perseverance, that waterfall is my kindness, that other peak is my courage. Every one of us got those. Those stories create vague reference points in our minds, and we turn to them when asked to describe our authentic selves or when our identities are threatened.

Remember A’s situation when she found out about B’s views of A’s actions? Like a well-balanced pendulum that keeps on going, her rumination swung back and forth between her views of her strengths and B’s weaknesses … click … clock .. click … clock. I selflessly stepped in and worked extra hard to get the job done. I always care for others. … B is incompetent. B is thankless. That rumination stopped only when we changed the question from “who got upset” to “what got upset,” and she realized that what got upset was her story about herself.

But there is more to this, and it can be unsettling.

This article is part of the Mountain Series — an inquiry into self-identity and why some people respond to setbacks with more elegance than others. Read the full series →

Already Arrived

I once worked for a peculiar and difficult manager. I used to have vivid stories of him in my head. In one particular meeting, he kept prodding me about a decision I thought I was entitled to make. That went on for some time. I did not feel good about that episode. I felt like I was being bullied. Later in the weekend, I began journaling about it. I wrote in my journal, “Here is my story …” and then circled the word “victim” in bold next to that paragraph. I picked up that “victim” metaphor from Shirzad Chamine’s popular self-help book, Positive Intelligence, which I read sometime before that episode. Naming what I was feeling that weekend as “victimhood” calmed me down.

I didn’t probe it harder then. I did not have to. That label “victim” on my lapel fortified my self-definition: I am genuine. I thought through my decision. I behaved according to my principles. Nothing needs to change. I’m packaged. I’m authentic.

No more probing was required. That was all that my mountain was seeking that weekend. It felt virtuous. Finding vindication, that weekend rumination ended. That’s the catch with authenticity. You are perfect as you are. Just show up accordingly — such a naive concept. You have already arrived. Nothing more to be done.

Jacob Golomb, an Israeli philosopher, characterized authenticity in In Search of Authenticity in 1995 as being faithful to scripts you have already written for yourself. David Hume, one of the most well-known 18th-century Western philosophers, was more brutal when he called the self a “bundle of perceptions” that we can creatively mould in any way we like. That bundle includes memories, thoughts, emotions, and impressions. Hume’s view in the 1700s is similar to the Yogācāra view of the mind, ālaya-vijñāna, a storehouse of seeds of accumulated past impressions and habits.

Authenticity is not the starting point of our behaviors. It is a post hoc label we use to explain and defend our behavior. Such labeling builds an immune system. It makes the mountain a hero. A quick etymological search shows that the word “authenticity” is derived from the Greek word “authentikos,” which means killer, murderer, acting on one’s own, and hence not answerable to anyone. Over centuries, that definition morphed into a virtue.

When authenticity is nothing but post hoc labeling, the situation has already paid the price. My “victim” lapel stopped me from probing further. A’s label kept her pendulum swinging. It can be, and should be, unsettling to come to terms with the realization that authenticity is labeling.

There is no pure inner self to be faithful to. So, the instruction to be authentic has no fixed referent. The belief that authenticity is good rests on a hope that there is an inner guide that uniquely defines each of us. There isn’t one.

A few weeks ago, on a flight from San Jose, I accidentally nudged the seat in front of me. I didn’t notice it immediately, but there was a pregnant woman in that seat. A male sitting next to her got upset and gave me a look. I returned a similar look and felt vindicated. But what happened to my self-definition of being kind? Instead, a stored default behavior, anger, defined my behavior. My authentic self was nowhere to be found.

Nowhere to be Found

Was I being inauthentic on the flight? Or was I being unaware? In the moment, returning a look showed strength and yielded vindication. The right response was an apology to the couple. For that, I needed to give up my scripts about what standing up for myself looks like. I needed to be present, instead. But my scripts obscured presence. Golomb pointed to Jean-Paul Sartre, the French philosopher, who mused about authenticity as “having a true and lucid consciousness of the situation.” Had I been present, I would have substituted my look with an apology.

Naming victimhood over a weekend years ago calmed me down. I felt vindicated, and my mountain was protected. I also felt understood — I had a label to describe myself in that situation. Had I probed harder, I would have discovered some root-cause stories and been curious about what my manager was seeing. I would have seen what I helped A see — that what got upset was the story about herself. Labeling myself prevented that insight.

The search for authenticity obscures our vision. The reference points we want to see on the mountain are our defensive mechanisms. Ah - there is your perseverance peak, your kindness waterfall, and your courage peak. You arrived, authentic and fully packaged. No probing required. Let this unsettling feeling stay for a while.

This article is part of the Mountain Series — an inquiry into self-identity and why some people respond to setbacks with more elegance than others. Read the full series →

Two Mountains

Sat, 04 Apr 2026 23:31:15 -0700

I know a software developer, call her A. B is the manager of another team, handling a critical project with plenty of tasks to be done, and dealing with escalations from other teams. A offered to help. A’s manager C talked to B, and they agreed for A to volunteer. A jumped into the project, took charge of key technical decisions, executed fast, and cleared up some critical parts of B’s backlog of work. A didn’t expect anything from B other than some appreciation and positive feedback during the review time. At least A hoped for it.

But B felt differently. When the review time came up, C approached B for feedback on A. Her feedback was lukewarm. B told C that A’s work was not as consequential as A believed and that A should have handled technical decisions differently. For B, A’s heroics were unnecessary, and B’s team felt that A forced herself into the situation. B and her team could have lived without A.

A hears about it from C. That hurts A. After all the time and effort I put in, how could B say such a thing? How ungrateful! Had I not offered to help and intervened, their project would have gone completely sideways. This is what I get in return? If she had nothing to say, at least she could shut her mouth - instead, I had to hear from C that my work was not good enough for them. So thought A.

A starts building her case. I had to clean up B’s mess. I had to work late in the evenings to finish things from B’s backlog. It was such a mess before I intervened. I rescued their project. She rehearses her arguments. She imagines her future confrontation. Rumination begins.

What got upset in this situation?

This article is part of the Mountain Series — an inquiry into self-identity and why some people respond to setbacks with more elegance than others. Read the full series →

What Actually Got Upset

A’s work for B’s project was real. The technical decisions that A made were real. The project did move. Neither B nor C would dispute any of these. What caused A’s rumination was the threat to her narrative.

A had built up a narrative about her involvement — she was the hero. B was unable to manage their project, and the situation required her intervention. When the need came up, she selflessly stepped in and worked extra hard to get the job done. A always cares for others and deserves to be seen as such. That is A’s version.

A built this narrative based on these and similar deeds she had done in the past for B and others. She had always been that way. She had examples — like medals on a wall. That narrative has been part of A’s mountain — she built it slowly over time. It feels solid, authentic, and indisputable. That helping nature has been a critical part of her identity, according to A.

When A heard of a different version from C, she began to ruminate about the situation. It was unsettling for A. In that rumination, she turned to her mountain for validation. The mountain rightfully validated her version — there are past stories like that to prove A’s helping nature. A has plenty of examples to give comfort. Yes, I’m right, thought A.

Yet, that validation was not enough for her. B’s narrative still bothered her.

She turns her attention to B — Such a mess. How could B manage a project like that — so many pending but critical decisions? What a mess it was before I intervened. It was awful. I have seen this before. B always struggled to manage her projects well. What I did was not good enough for B? How dare.

This counter-narrative began to settle A’s mind. A is right. B is incompetent. And ungrateful.

The Pattern

What got upset here was A’s story about herself. What she heard from C threatened her narrative. To fight back against that upset, A turns to her mountain for validation and builds a counter-narrative to find comfort. Once threatened, the mountain quickly builds its clouds.

This pattern is universal. Earlier in my career, I went through the same drama when my manager made someone else the lead on a project I did most of the work on. How could that manager not see my contribution? I ruminated for at least a week. On the day the lead role was announced, I got so disillusioned that I left work early and locked myself in a room at home. I turned to my mountain for comfort. My narrative that I did most of the work for that project helped me. I also had to build a counter-narrative about the manager and the person chosen as the lead. The manager was the villain, and that lead person was incompetent. I was the competent one — that counter-narrative comforted me. My mountain was defended.

It’s story versus story, fabrication versus fabrication. The internal drama continues till you feel vindicated. Rumination is the search for vindication. The mind eventually quiets down when it feels that the mountain is protected.

Buddhism has a precise name for this pattern: upādāna — attachment or clinging. Attachment forces defensive mechanisms — you had to be a hero again and make the others villains. In this process, the victim becomes the judge, who then reprimands the villains.

The vindication feels like the truth. It has a nice ending for A and, in the project lead situation, for me, although arriving after gut-churning rumination. A quick discussion by A with B would have revealed something that A had missed. A chat with my manager on what I could do to earn the lead role would have opened a different door. But the rumination got in the way.

The Chuckle

A has stories about herself, decorated in her mountain. B has stories, similarly adorning their mountain. B must have ruminated too, seeking validation and finding fault with A. B’s project was, of course, not in good shape. Then they formed clouded views of each other — B first, then A — clouding their judgment. They mirrored each other’s behaviors, each seeking vindication and defenses. This conflict is about view versus view and story versus story, not about who is right.

Hurt, A shared her story with me. It reminded me of situations when I was similarly hurt and ruminated. I knew who was upset. So I changed the question — What got upset?

That question helped A detach from the situation and see what I’m seeing. There are two mountains on the stage, each looking to defend its position. Each was upset and was seeking answers. Not feeling vindicated, each was checking whether their shape and mass were intact and looking for weaknesses in the other. That way of seeing the situation made her chuckle.

Next time, when you catch yourself hurt, defending, or protecting, consider the question: What got upset?

This article is part of the Mountain Series — an inquiry into self-identity and why some people respond to setbacks with more elegance than others. Read the full series →

The Mountain and the Clouds

Sun, 29 Mar 2026 19:45:57 -0700

Take a typical work situation. Something was expected of my team. But it was not met. The other party calls for a meeting. Meeting starts. I look at the slide on the screen - there is status with dates, red flags, and my team name next to those red flags. Baits were laid out. Accusations made, and arms are up. I was expected to take the bait, argue, and defend. Or retreat in defeat. Weapons were drawn.

Mind is racing - I had seen this pattern before with this team. I need to fight back. They struggle with their deadlines and escalate in the last minute! Poor planning. Always. Now they are acting like bullies, covering up their problems. I don’t like this. They are wrong. A cloud forms in the head. Weapons up. Argue. Defend. Prove them wrong.

Or, pause and acknowledge? Where are they coming from? There is difficulty. Their work is critical. What was their situation? What are the challenges? Where did the process break down? What were they seeing that I have not seen so far? I ignore weapons. I ask questions and seek answers. We decide the next steps. War mode diffused.

Weapons up and prove yourself right? Or pause to see through the cloud to solve the problem? Most choose weapons. Few choose the pause. Why? The answer does not come from leadership training or self-help books. It comes from somewhere older.

It was 1925. Gandhi received an anonymous letter criticizing his satyāgraha. It was harsh and accusatory, blaming Gandhi for failure and cowardice. The accuser urged Gandhi to leave politics. What did Gandhi do? Get upset, ignore it, or angrily throw it away? Or loudly defend himself? None of those. He first published the letter in full in a newspaper, then praised the accuser’s love of the country, and calmly explained his approach. No bitterness. No insults. No criticism. Was that response spineless? Or mastery?

Take any interpersonal or team conflict. The pattern is the same: egos, disagreements, talking past each other, and bruised feelings. We hear about pausing and reframing in many self-help books to handle such situations. Still, we often forget such advice in the moment. Why is that?

Step back. Understand what we think happens versus what actually happens.

The obstacle runs deeper - way deeper - than we realize.

This article is part of the Mountain Series — an inquiry into self-identity and why some people respond to setbacks with more elegance than others. Read the full series →

The Cloud That Clouds

Here is what we think is happening. We observe the situation, assess it objectively, judge, and then act according to that judgment.

I entered the room, saw it was an escalation, observed the frustration and blame, objectively assessed that they were wrong, and concluded that I had to argue for and defend my position. I had a strong case, based on facts, rational thought, and judgment.

Sound familiar? Most of us have been in that room. Most of us were equally certain.

But would a different person who observed the same situation come to the same conclusion? Likely not.

Let me share another work situation. It happened years ago. I was not initially involved in the situation, but I decided to intervene after witnessing pent-up friction among about a dozen individuals. Their work was connected, but the people were not. There had been years of mistrust, finger-pointing, passive aggression, and little cooperation.

I met with each of them individually to ask a few questions - what was happening and what they would like to see happen. I kept asking clarifying questions and taking notes. Each person shared stories about what was wrong. I compiled my notes and, without naming anyone, shared my summary with everyone in a group meeting. Everyone agreed. I then led a discussion to determine the next steps. Suspicion decreased, and trust increased. By the end of the meeting, everyone felt relieved upon realizing they had a clear path forward.

Any one of those dozen individuals could have easily done what I did. But they did not. Why not?

Before I stepped in, they all had stories about others in their minds. Each had a different story. They saw themselves as the protagonist. In their mind, a few others from the group were the antagonists. They provided examples. Each had logically constructed reasons for their actions toward the antagonists.

You have those antagonists, too. You know exactly who they are.

But I didn’t have an antagonist in my mind in that situation. All I saw was dysfunction. Their stories clouded their judgment. I was willing to see through those clouds.

But where do those clouds come from? Character flaws? Immaturity? Poor attitudes?

The Mountain is the Source

Check your mind. Is there a story about that colleague you don’t get along with? Check. That girl at the reception you’ve never spoken to? Check. The scuffle from three years ago, you still replay? Check. Your best friend? Check. Your loved ones? Check. That meeting where you were triumphant? Check. When you got fired? Check.

The mind keeps scores and scars. Every experience, every interaction, and every impression leaves a trace, like a bit of soil and rocks added to a mountain. The mass and shape of the mountain, which we proudly call “I,” is a slow and silent accumulation. The mountain is our identity.

The trouble with the mountain is that it builds clouds. Orographic lift - the meteorological process by which mountains force moist air upward until clouds form - isn’t just geography. It is psychology. Our past impressions form clouds that cloud our perception of what’s in front of us. This clouding is not just a metaphor. Our minds generate predictions based on accumulated experience and only update them when prediction errors are significant. Neuroscientists call this predictive processing. What we see is largely what we expect to see. Two people in the same room, looking at the same status slide or the same dysfunctional situation, will form different perceptions. Social psychologists call it construal.

But this idea is very old - nearly 1600 years ago, Yogācāra, a branch of Mahayana Buddhism, called the mind ālaya-vijñāna - a storehouse of seeds of accumulated past impressions and habits. These seeds remain dormant until the right conditions, at which point they ripen into our lived experiences. More recently, memory researchers arrived at the same conclusion through a different path: their idea is schemas, which are generalized patterns that our brains construct from incoming information and then automatically apply to new situations before conscious thought even begins.

Those dozen individuals weren’t clouded by character flaws. They were clouded by their mountains - years of accumulated impressions, interactions, and stories about each other. Each saw the situation differently, shaped by the nature of their mountains and the stories that shaped their clouds. I had the same impediment in my work situation. I had past impressions ready to cloud my view even before I looked at the status slide on the screen.

You do not see situations NEUTRALLY. You never have.

Our perception is already clouded before we do anything. This is a fundamental limitation of the mind — not a flaw, not a choice, just how it works. There is nothing you can do to eliminate it. But there is something you can do about your relationship with it. That is the practice.

The Practice

I walked into that room with clouds already formed. I saw weapons instead of, perhaps, a plea for help or a call to take responsibility. Each of the dozen individuals saw their own cloud, not each other.

That insight - that we don’t see situations neutrally - created the pause. That pause changed everything. I acknowledged the difficulty. I saw what they saw that I had missed. I asked questions and sought answers. We decided on the next steps without war. Squinting through the clouds, I could see what they saw. That seeing opened the door to reframe the situation.

That pause is rare, not because it is difficult, but because the insight behind it is almost never named. We see clouds in the situation, and not in our perception of the situation.

Gandhi learned it from the Gita and Tolstoy. He didn’t let clouds obscure his vision. People expected him to confront, but he acknowledged and engaged instead - whether it was when the anonymous accuser criticized him, when he gifted handmade leather sandals to General Smuts, who jailed Gandhi twice, or when he refused to see antagonists in the Hindu-Muslim conflicts of the 1940s.

The same wandering prediction-making mind that builds sandcastles also makes up the clouds. Controlling the mind from making sandcastles or clouds is a futile exercise. The trick is catching the cloud before it becomes a certainty.

The clouds still form. They always will. The next time you walk into a room, certain about the people in it, certain about who they are, what they want, why they’re wrong - that certainty is the cloud. You built it. You are walking into the room with it already formed. The insight helps me squint. It gets easier with practice. Weapons dissolve as I squint.

This article is part of the Mountain Series — an inquiry into self-identity and why some people respond to setbacks with more elegance than others. Read the full series →

Sandcastles and the Mountain

Sat, 21 Mar 2026 18:40:36 -0700

I vividly remember how it felt in my stomach - a mixture of bitterness, hurt, and shame. It was years ago. I had to walk down memory lane and replay the situation from different perspectives to discover where I went wrong.

It was a new company, a new role, and a new problem space filled with ambiguity. As a newcomer not yet used to that workplace’s culture, the most I saw was chaos and dysfunction. There was a big project ahead, and things were not going as planned. I jumped in with another colleague and started exploring options. One of those options appealed - it was an out-of-the-box idea, requiring a big change. If implemented, it would alter my role and my career path. I fell in love with that idea.

I didn’t stop at just pitching it. I imagined what would happen next. I played with, replayed, and extended the idea, and I started to love it even more. I pictured what I would do next, how I would show up, and how I would get the project back on track. I would be the new hero. It was going to be amazing. It would open a new career trajectory. The more I imagined, the more real it seemed, and the more I fell in love with it. Alternative ideas faded away. I was consumed by that idea.

That went on for a few weeks. Then, none of that happened. Things took a different turn. Another option became real. My beautiful sandcastle was washed away, just like that. It felt like a gut punch. A chill. A big defeat. The ego was hurt. I was left feeling bitterness over losing what I wanted, anger at how it turned out, and shame for my sandcastle, which was on full display for a few people before the waves washed it away. Bitterness. Anger. Shame. Those make up a new sandcastle made out of what was left. I struggled for a bit, bounced back, and went on to do what was needed, at least outwardly. It took months not to feel bitterness and resentment.

This article is part of the Mountain Series — an inquiry into self-identity and why some people respond to setbacks with more elegance than others. Read the full series →

## Sand Castles

That’s the nature of sand castles. I’m referring to those sand castles that our wandering prediction-making mind builds as it predicts future possibilities, like a new job prospect, a promotion, a new relationship, some extra pile of money, a new place, and so on. We don’t just perceive the world as it is; we perceive it in ways that appear useful to us. Our minds build sandcastles because they appear useful.

Initially, it was a small idea, just a thought—like a tiny mound of sand on the beach. It’s easy to miss such a passing thought, but then move more sand, build a small dome, and add some basic walls - the shape is clearer now. As the walls form, the castle begins to take shape. Sprinkle a little more sand to add structure. It starts to look real, with mass and form. Then begin to admire the work, walking around it and decorating it with shells and pebbles. It looks fantastic. It’s my creation. That’s how I built my sandcastle, and then I fell in love with it.

What was the error in this process? Was it the sandcastle or the relationship I built with my sandcastle? Building sandcastles is what the mind does during most of our wandering times for our survival. The error is the significance I attributed to my sandcastle. The error lies in the meaning and importance I gave to the sandcastle. It was my ignorance in recognizing that the sandcastle was just my thought construction. The Buddha realized it 2500 years ago. The result of not recognizing is grief. My grief was not proportional to the loss of an opportunity. It was proportional to the size of my sand castle and the time I spent entertaining it.

What did I do when my sandcastle got washed away? I turn to my mountain.

The Mountain

The mountain feels different from the sandcastle. It is built slowly with effort and experience and includes my education, career, the expertise gained over time, and prior accomplishments - all these feel more real and earned than imagined, unlike the sandcastle. The mountain has shape, weight, and history. It accumulated over time. There was effort involved. Every past accomplishment feels like yet another switchback. Past careers are boulders added for extra mass and shape. The mountain appears credible and dependable. I turned to the mountain because I knew it had the tools to deal with the situation. The mountain helped me pull myself together.

And yet, for all that solidity, the mountain too is a construction of the mind, just a slower one. This mountain includes the accumulated beliefs, principles, and preferences that appear to define me as a person. When someone asks me who I am, I don’t turn to the sandcastle - I turn to the mountain. My authenticity is right there encoded in that mountain. The mountain thus gives comfort, a sense of stability, and purpose. It acts as a reference point. It appears more useful and durable than the sand castle.

But mass and height don’t mean no grief. Where do you think the bitterness, hurt, and shame in my situation came from? They appeared because what happened in that situation didn’t agree with the mountain - my “self” definition. The wave washing off my sandcastle felt like a defeat - the self didn’t agree with it. The sandcastle’s collapse, on full display, was a source of shame because shame hurt the ego. The mountain is thus as much a source of grief as the love I had for the sandcastle.

It too can erode, and parts of it may crumble, albeit slowly. A change in economic circumstances, a war, bankruptcy, a company reorg, a layoff, or an unfortunate health challenge can upset the shape of that mountain before I realize it. Clinging to that mountain has the same effect as falling in love with the sandcastle.

Seeing it Clearly is a Practice

I still build sandcastles to stay curious, explore possibilities, and venture into unknown territories. But I know they are impermanent and depend entirely on external conditions. Waves are coming by? Build the castle elsewhere. Still difficult and imperfect to put into practice, but it becomes easier with practice. What used to take weeks to bounce back now takes hours or days.

I keep adding boulders to the mountain, too. The lessons learned, books read, and insights from experiences add more bulk to the mountain. As I age and add different experiences, the mountain takes a more complex shape. It is built upon decades of experience and effortful curation. It’s the source of identity. It’s hard to treat it as less important, even fully knowing that it too can be a source of grief, when it does not agree with situations. There are moments when I catch myself defending the mountain even as it causes the very pain I’m trying to understand.

The practice, then, applies to both — clearly seeing sandcastles and the mountain as sources of grief and mental discomfort. I have not mastered this. With a pause and some effort, I can now recognize the source of mental discomfort. It’s either the love for the sandcastles or the disagreement of the mountain with the situation. The pause makes space for alternative framings of the situation. That recognition alone - not the mastery, just the seeing - tells me what I am dealing with. Gut punches now land like soft blows.

This article is part of the Mountain Series — an inquiry into self-identity and why some people respond to setbacks with more elegance than others. Read the full series →

Ride the Wave, Don’t Drown

Sun, 15 Mar 2026 13:10:05 -0700

Per Anthropic’s most recent article on AI’s implications on the labor market, I belong to the most exposed occupation: computer programmers, with a 74.5% exposure risk. Such predictions undoubtedly cause panic, an adoption rush, and an identity crisis. A lot is being written about these every day, and there is nothing for me to add.

Instead, let me focus on learning. Learning is the most essential thing to do during a time of change, and it is in our control.

This is a great time for learning new things. Thanks to AI, the cost of learning new things is now rapidly declining. It is now easy for anyone to put together personalized learning plans, go through them, and learn new things. Instead of spending months of coursework through textbooks or online learning platforms like Coursera, you can pick up a subject, ask your ChatGPT, Gemini, or Claude to put together a multi-step learning plan, and go through those steps in a much shorter timeframe. What’s more, you can let the AI eliminate undifferentiated tasks from the learning activity, such as tool setup, research, summarization of what you want to learn, validation of what you learned, etc.

It sounds like a good deal, but there is a catch. The very technology that can help us learn new things very quickly also opens a wide enough door to offloading and surrendering cognitive work. Let us take a walk through the “memory lane” of our brains to find that catch.

Engrams and Schemas

Brain research is one of the oldest and still-developing areas of philosophy, cognitive and neuro-psychology, neurobiology, and neuroscience. From ancient philosophy to contemporary neuroscience, we have been trying to understand human consciousness, the nature of the mind and brain, how memories form, how we remember, and how we develop insights.

According to neuroscience, engrams are the neural substrate responsible for storing and recalling memories. These are ordinary neurons recruited for memory. But we, as in conscious selves, barely register most of the information we receive through our sensory organs. However, when adequately primed, the information leaves a trace in our brain as engrams. Engrams are reactivated when we receive cues similar to those present at the time of engram formation, resulting in memory retrieval.

But not every neuron is recruited during engram formation. Neurons compete in this recruitment process, and those with higher excitability at the moment of learning win. Among other factors, attention and effortful engagement increase excitability.

Learning about such a connection was like a lightbulb for me. Cognitive attention and effort raise neuronal excitability, making those neurons more likely to be recruited in memory formation.

What gets even more interesting is how we form generalizations and patterns, called schemas, from related or overlapping information between those engrams. Schemas emerge from related engrams over time. As we experience overlapping or related information over time, our brain updates those schemas. As our brain forms schemas, it frees our working memory to process incoming information. Schemas are representations of knowledge. Schema formation lets us accumulate knowledge and quickly recognize patterns, encode new, related information, and make predictions to solve unfamiliar problems. In this way, schemas lay the foundation for critical thinking.

This is another lightbulb. Effortful engagement in problem-solving supports schema formation, which in turn supports our critical thinking.

Intuitively, this all makes sense. As a software engineering practitioner, I see schemas as higher-level abstractions and engrams as building blocks. We use layers of such abstractions to model the real world and solve problems.

Difficulty and Generation

Most of the struggle in learning is forming schemas. The brain does not simply record what it receives to form schemas. Let us pause to consider two related concepts from cognitive psychology: cognitive load and desirable difficulty. These concepts play a role in designing learning programs and tell us that the learning process must include a certain level of difficulty to help our brains acquire information and develop schemas. Introducing the right kind of difficulty at the right moment helps us develop stronger schemas, which is important when learning new things. So, while it is easier to learn new things now, forgetting them is also easy unless we go through the difficult parts.

There is another related concept, “generation effect,” in cognitive psychology. Explaining what we hear in our own words or writing it down are forms of generation. Generation solidifies schemas in our brains. This is why we remember self-generated words better than passively read words.

Consider two related tasks: listening to an audiobook vs. scribbling notes in side margins when reading a print copy of the same book. The latter involves generation, which helps increase retention and schema formation. Similarly, writing this article involved cognitive effort and sustained generation over several days for me. I had to read research material, connect the dots within it, and synthesize it in my own words. It was cognitively demanding work. That puts a reader who glosses over this article at a disadvantage.

Cognitive Offloading and Surrender

Daniel Kahneman, in his Thinking, Fast and Slow, introduced us to two modes of thought: System 1 and System 2. System 1 is fast and instinctive. System 2 is slow and deliberate. Per Kahneman, System 1 draws on instinct and deeply ingrained experience, while System 2 is effortful and deliberate, requiring active reasoning and encoding.

Through a recent article by two Wharton School researchers, I learned about a third mode: System 3, which relies on artificial cognition. This mode offloads thought and reasoning to AI. In their paper, Thinking—Fast, Slow, and Artificial: How AI is Reshaping Human Reasoning and the Rise of Cognitive Surrender, these researchers, Steven Shaw and Gideon Nave from the Wharton School, extend Kahneman’s theory into a Tri-State theory with the third state - the adoption of AI - which can override both System 1 and System 2. They point out that because AI outputs are fast, fluent, and sound authoritative, we bypass effortful reasoning and quickly adopt those answers as our own.

This mode of working involves cognitive offloading and surrender. Offloading is when we delegate a cognitively intensive task to System 3. Cognitive surrender is the failure to apply System 2 reasoning to verify what System 3 produces. Offloading is not a problem by itself, but surrendering is. In this process, what our brain would learn is how to use AI to get an answer, but in doing so, we would sacrifice critical thinking and accountability for the output.

Take vibe coding - it is System 3. When relying on this mode, we bypass memory formation, memory consolidation, pattern formation, and encoding in the brain.

However, there is reprieve. When used appropriately, I believe that System 3 can augment and enhance System 2. We can do so, for example, when we use it as a learning aid to discuss topics, answer questions, let AI ask us questions, and explore our own understanding.

Learning to Ride the Wave

In this time of rapid change and information overload, we must adapt by learning. But as I covered above, learning involves active research topics like engrams and schemas, difficulty, and generation. By discussing the underlying brain science, my goal is to clarify the distinction between cognitive offloading and surrendering.

This research tells us that we must engage in tasks that help us learn and improve our critical thinking, rather than always resorting to quickly finding answers and avoiding accountability.

For example, I protect reading and writing from AI. I don’t let AI generate documents, slides, or summarize written material, including books. But I’m okay with letting AI search and research for me, as long as it provides citations to original sources I can read. I am perfectly okay with taking AI’s help to validate my understanding by letting it ask me questions.

In the context of software development, I’m okay with letting AI critique a system design and point me to better alternatives, but not with letting it come up with requirements and designs and blindly turn those into code.

There is a human cost, too. Think of a congratulatory note or a sympathy card you would write to someone. You can effortlessly produce profound-sounding text with AI, but you will miss the opportunity to empathetically connect with that person and the circumstances. When we don’t participate in the generation process but outsource it to AI, I worry that we lose empathy and the human connection.

In summary, we must be intentional about using AI to maintain critical thinking and accountability. When we understand AI’s limits, know what to protect from it and what to disrupt, and lead the adoption, we develop the skills to ride this wave. Otherwise, we might drown.

Productivity and Entropy

Sat, 07 Mar 2026 11:22:43 -0800

I’ve spent over 25 years watching software systems accumulate entropy and drift into disrepair and failure. I’ve led several projects and know the excruciating pain it takes to bring such systems back on track. That experience makes me cautious about unbounded productivity gains with AI. The early productivity gains are clear, but we should discuss complexity and entropy before jumping to conclusions.

While there is no universal definition of complexity, when we say some software is complex, we usually mean a system with many parts that occasionally behaves in ways that go counter to our understanding. Entropy is a measure of uncertainty and unpredictability. It shows up as tangled dependencies, unpredictable states, cascading failures, etc.

Frederick Brooks explored these topics in the context of productivity 40 years ago in his ACM article titled No Silver Bullet: Essence and Accidents of Software Engineering. Since that article is behind a paywall, see this 1995 reproduction. In that article, Brooks made a few observations: (a) software construction involves two kinds of complexities, essential and accidental, (b) essential complexity is irreducible, and (c) there is no silver bullet for productivity.

AI is reshaping both essential and accidental complexities. We can now automate several aspects of determining what to build and how to build it. It sounds like we found the silver bullet that Brooks has given up on: more tokens → higher productivity → fewer people → more profits. But is that so? Let’s probe into the origins of complexity and entropy before jumping to such a conclusion.

Path dependence

The idea of path dependence is that early choices have irreversible consequences. As a system gets successfully adopted, early choices create a lock-in. We see it in every successful tech company: some early assumptions and designs usually dictate the rest of the software’s evolution. Those assumptions and designs ultimately influence not just code evolution but also team structures and even culture.

Paul David, an economist who introduced the idea of path dependence, uses the QWERTY keyboard as an example of how early typewriter designs in the 1880s locked us in since then. Path dependence constrains future choices. By limiting choice, it increases the cost of changes as requirements change and business conditions evolve.

Once I read about path dependence, I could not unsee its impact in the companies I worked at in my career. At every place, path dependence was at play - large monoliths, custom frameworks that lock the data in particular databases, particular team structures because “it has always been that way”, etc. Changing such things takes enormous time and effort. Most of what we consider legacy, or technical debt, is often the result of path dependence.

As we add more features to such software, the path dependence constraint will lead people to work around it. Then it becomes more difficult to understand the implications of changes. Entropy accumulates over time as we try to work within the constraints of path dependence.

Will AI help you circumvent path dependence? One might argue so: you could direct an agentic coding tool to refactor and rewrite the code to tear apart path dependence. However, in practice, that can prove to be disastrous. Rewriting any complex system, including all its dependencies, while preserving data and existing user behavior, is a hard task. The risk is high.

The next three are based on two excellent books on systems thinking: Thinking in Systems by Donella Meadows and Drift into Failure by Sydney Dekker.

Competing feedback loops

In the first chapter, Meadows introduces the concepts of “stocks” and “flows” and two kinds of feedback loops: balancing (stability-seeking) and reinforcing (amplifying, growth-seeking). Stock is the material you work with. In the context of software development, stock refers to the amount of code, services, data stores, various components, teams, and people. Flows are activities we do to manage the stock. Flows change the stock.

The best way to think about stability-seeking and amplifying feedback loops is to ask whether your organization is changing the stock for stability or growth. When focused on stability, you constrain the flow to reduce bugs and improve system stability and performance. When focused on growth, you increase the flow to prioritize business growth. You can try to improve both at the same time, but you can not ignore the tension between the two.

In practice, no software organization does either alone. Some parts of an organization may be stability-seeking (such as your infrastructure or platform teams), while others may be growth-seeking (such as your feature teams). Similarly, your architects and senior engineers may prioritize the architecture’s stability and integrity, while the rest may prioritize speed. The tension between these two leads to conflicting choices and workarounds. The net result is an increase in the overall system’s entropy.

Now, bring AI into the picture. Unless constrained, AI will rapidly accelerate conflicting feedback loops. Empowered by a high-speed tool, each team could attempt to optimize the system in conflicting ways - some for stability, and many for growth. Most might get their outcomes in the short term, but very quickly, the competition between these factions will increase entropy faster than it would without AI.

Delayed feedback

Delayed feedback is like the slow drip you forgot to fix in the basement, and now you have mold in the house. In software, certain delays take time to manifest. For example, you might delay some cleanup or scale-out activity because everyone is busy introducing other changes to the system, unaware that entropy has been increasing and that the system is reaching a critical state. Things would be fine for some time, and one day you might find yourself in firefighting. The delay in the feedback creates a false sense of safety, which then leads to delayed repairs. Per Dekker, delayed maintenance and repair contribute to systems drifting into failure.

Delays show up in other forms, too. In one case, a minor data corruption issue remained undetected for several months, and correcting it became expensive and time-consuming. In reality, in any large software-powered enterprise, there are likely several such slow feedback loops at play. Such delays usually result in future unplanned maintenance work and drain your productivity calculations.

Will AI help detect such delayed feedback loops sooner? Will it prioritize such repair work over other kinds of work without our prompting? Or will we have more such delayed feedback loops as we rapidly change the system with AI? While we don’t have evidence for either, AI will likely introduce more delayed feedback loops, requiring more frequent unplanned maintenance.

Stale/incorrect models

Meadows also reminds us that whatever we think we know about the world is a model. Models are incomplete, and different people construct different models to deal with the world outside their minds. Meadows says in Chapter 4,

… our models fall short of representing the world fully.

What does this have to do with software? As software ages and multiple people touch the software, our models drift apart. For example, the senior-most person in the company who wrote the original software (and thus the creator of path dependence) might have one model of the software. A junior engineer who joined the organization recently will have a very different model of the software. As software ages, changes by different people with different models lead to even more drifted models of how the system is supposed to work. Eventually, nobody would have the complete picture to reason about the system. Most technical debates I’ve witnessed are the result of people holding different models of how the system is supposed to work. People argue about how to add or modify something before checking whether they share the same assumption about how the current system is supposed to work.

As more changes get made, the coupling within the system changes in unexplainable ways. The result is increased entropy. Changes become time-consuming to make and difficult to validate.

AI will likely add more fuel to this situation unless we find ways to coerce everyone to use the same model of how the system is supposed to work. It will be difficult to construct such unified models for large monoliths, or even for monorepos.

Will AI have a better model of software (including systems’ runtime behavior and user behavior), carefully balance between stability-seeking and growth-seeking patterns, and manage entropy?

No. The four factors we discussed above - path dependence, competing feedback loops, delays in feedback, and above all, incomplete models will create a complexity ceiling for AI.

Just consider our models. Like us, AI builds a model of the system and uses that model to determine actions. Like all models, an AI-built model would be imperfect too. Further, multiple people working on the same system will likely see their AI tool generate a slightly different model tailored to their use. AI thus magnifies the same model problem we humans have. It is like 100 teenage developers working on the same system, each with a different model of the system.

Since we’re the ones setting the goals for AI, we will likely continue to favor growth-seeking feedback loops over stability-seeking ones, delay maintenance, and allow our systems to drift toward failure faster.

AI will require us to hold on to good software engineering principles even tighter. Those who understand this will build systems that grow and last. The ones chasing unbounded productivity gains won’t know why they failed.

Agentic IDEs - 100 Teenager Dev Problem

Sun, 25 Jan 2026 21:04:41 -0800

Imagine this situation: You are an experienced dev manager. You know how to assemble 15-20 adult software developers, analyze a moderately complex set of requirements, develop a project plan, break the work down, and delegate tasks across the team. You are capable of running appropriate SDLC rituals and delivering results on a predictable schedule. One day, you arrive at work only to find your team replaced by a hundred hyperactive teenagers. Those teenagers have googled everything and believe they know it all. They are excited about their first job, curious, restless, and eager to start working on their keyboards. Your task is to organize this team to achieve the same results much faster.

Where do you begin? How would you approach this challenge? That’s the kind of skill needed to produce predictable outcomes quickly with agentic IDEs. While my comparison of agentic IDEs to managing a team of 100 teenagers might sound snarky or funny, I recognize that it’s unfair to teenagers. After all, our future depends on them. I’m making this comparison to emphasize that taming agentic IDEs to achieve predictable results is much like getting a 100-teenager software development team to work well.

Here are some reasons why it is important to draw such a reference.

Agentic IDEs act confidently. They behave as though they know everything there is to know and impress you.
Yet it takes little effort on your part to coerce them into contradicting themselves, changing their minds, or giving up altogether.
You can give a complex specification to get them to quickly build a working system, but they can also just as easily send the system into chaos when asked to fix a bug.
Unless you are carefully watching, they can break your architecture and make changes in unwanted places. You must be extremely granular and specific with your instructions.
They act like they know how to follow instructions, but they can conveniently ignore them. They will give you vague explanations about why they ignored your instructions.
Depending on how their system prompts were designed, some respond obediently while others respond tersely to your questions.
Once in a while, you have to pull them back by their tails to not get into rabbit holes.

None of these patterns should be surprising. LLMs are massive prediction machines. They hallucinate, don’t understand language, code, or concepts. They are sophisticated statistical engines designed to predict the next token. Coercing them to produce decent outcomes is an art and not a science.

So, how would you get them to produce effective outcomes? Through December 2025 and early January 2026, I’ve dealt with three moderately complex problems: modernizing a legacy codebase, an mTLS-based system for authentication and authorization between services, and an internal developer CI/CD platform for creating and deploying apps in the cloud. Each problem would normally take 3-6 people over several months, and I spent about $500 (a decent portion of which went to AWS). In each case, I addressed full-stack concerns and got working solutions.

My experience varied from mediocre to excellent. I used multiple agentic IDEs. As I reflected on the differences between scenarios where they worked well and those where they struggled, I began to notice patterns and formulate hypotheses. I have some evidence supporting these hypotheses, and I will continue to refine them in the coming weeks and months. The goal of these hypotheses is to find out how to tame these agentic systems to produce reasonably correct software solutions.

Hypothesis 1: Good engineering principles matter more than ever.

Let us go back to the 100-teenager analogy. How would you organize a 100-teenager team to do some constructive work?

You would create an overall plan for how the work should be carried out. You would break the work into manageable parts and assign each to a small enough team. You will provide them with clear instructions on what to do. You will outline some dos and don’ts.

You will provide sufficient space and boundaries between subgroups so that each can work independently to accomplish its task. You will consider the dependencies between subgroups and identify what can be done in parallel and what must wait for other subgroups to finish. You will set communication pathways and protocols between the subgroups. You will assign the task of ensuring the correctness of those dependencies and communication to a few. You will tell them how to test that various subgroups did their work correctly to your satisfaction.

In other words, you would meticulously focus on a documented system design, architecture constraints, component choice, project plan, modularity, interfaces, composability, module testability, tests (unit, integration, end-to-end, etc.), acceptance criteria, etc. The same holds for taming agentic IDEs to work for you.

Furthermore, when you have a large number of people (that too, teenagers) working for you, you would focus more on correctness and completion and less on getting an MVP out the door quickly. When I compare the situations where I made steady progress and where I had to fight code regressions, the difference was how well I thought through modularity, interfaces, tests, and acceptance criteria at every phase, instead of short-circuiting the process with poorly tested modules and porous interfaces. The more structured I was in determining how the work should be done and in following contract- and test-driven development, the greater the throughput I achieved with agentic IDEs. The more component-level, integration, and end-to-end tests I had, the faster it was to implement new features or find bugs. Taking shortcuts had the opposite effect. In one particular instance, I wasted almost half a day getting AI fix some regressions. My experience made sense in light of the seven points I listed above.

To summarize, meticulously following good software development practices is essential to get high throughput with agentic IDEs. Some of those principles may matter less when you have a small human development team that can only produce a handful of changes a day, but not with agentic IDEs that can make dozens of changes in minutes.

Hypothesis 2: High development throughput depends on simple, automated, and well-integrated dev tools and processes.

When was the last time you carefully reviewed all the dev tools and processes and eliminated friction points? Probably never or for a long time. But the time is now. Here is why.

The development throughout is a function of the tools and processes employed. Consider these:

Dev tools: Source control, local dev setup tools, local builds and tests, artifact repositories, secrets management, CI/CD pipelines, test and integration environments, logging and monitoring systems, distributed tracing, docs and standards, task and bug tracking systems, ticketing and approval flows, internal developer portals, etc.

Dev processes: Architecture and system design procedures and reviews, planning rituals, sizing and estimation, task breakdown, checkpoints such as standups and status meetings, code reviews, change review processes, etc.

Your current development tools and processes, whether you like them or not, are perfectly aligned to yield your team’s current throughput. Furthermore, those tools and processes are a result of your company’s and team’s legacy, culture, technical debt, organization’s structural debt, business conditions, and leadership attitude. To add, most aspects of these tools and processes are evolutionary. Those are often a patchwork of what you inherited, what you learned, and what you instituted over time. Those are likely not designed from first principles to yield high throughput.

Just like the 100-teenager dev problem, agentic IDEs introduce a scaling problem. Your current tools and processes will become bottlenecks as these tools can design, reason about designs, write, test, and debug complex software problems in seconds or minutes rather than hours or days.

For example, in my experiments, I gave my agentic IDE seamless access to my source control system, CI/CD infrastructure, and cloud-based deployment environment. That smooth integration allowed me to let my agentic IDE review and commit code, review CI logs to catch issues, review CD steps, check deployment logs, perform health checks, and, in general, do everything I would do manually.

But if your development flow involves hand-offs across teams (like dev to QA to release), meetings, manual checkpoints, approvals, tickets, fragile test environments, logging and monitoring systems that are hard to access, long lead times between commit to production, etc., then your team’s throughput will be severely constrained. This is the time to carefully review tools and processes, eliminate bottlenecks, and prepare for a world where agentic IDEs, and not just people, are the ones iterating through every aspect of the SDLC. This step will involve moving cheeses and breaking norms, which brings me to my next hypothesis.

Hypothesis 3: Yet, most enterprises will struggle to get high developer throughput.

Here is my stark prediction. Getting licenses to agentic IDEs to everyone at work is the easy part, and most enterprises will struggle to yield consistently high throughput with those tools. Many will get occasional proof points, which I call “accidental wins” when a team performs a task or project at 5x or 10x throughput. Yet, many will likely struggle to achieve sustainable throughput increases.

I am basing this hypothesis on the following factors.

First, most managers are usually detached from the finer details of how work gets done within and across various teams to know how to (a) improve engineering hygiene and rigor to support my first hypothesis, and (b) rewire the team’s dev processes and tools to support my second hypothesis. They are usually busy with meetings, reviews, escalations, 1:1s, and all such operational tasks. Their memory of how good software should be built may also be dated. But leading the change with agentic IDEs requires you know how code moves through your system of processes and tools.

Second, even when a manager is capable and willing, most organizations don’t incentivize improving hygiene and rigor on existing code bases. Say, your team’s test coverage is low, and you want to prioritize improving test coverage for a few sprints. Or you want to invest in refactoring the code to make it more modular. Or you want to invest in automating some long-pending manual workflow. Which product manager or senior leader will support you and make room to prioritize such hygiene factors over shipping a new feature?

Third, managers, due to the nature of the pressures they face, develop throughput-bursting habits over time. For example, consider how you estimate the time required to complete a project. You will base it on prior experience and everything that went wrong in the past. You also make room for some attrition, leaves, dependencies, and so on. However, your estimates will influence and control the pace at which work gets done. To try what it takes to yield high throughput, you should be willing to say yes to bigger ideas. But bigger projects come with risks and uncharted territory. Why bother and leave the predictable territory?

Under the right conditions and organizational factors, managers can be great enablers of increased team throughput by focusing on the factors I identified in my first and second hypotheses. But when those conditions are not right, managers will be the biggest bottlenecks for change.

As I wrote last month, agentic IDEs require you to shift your mindset from artisanal to industrial software crafting, which introduces a scaling problem. Your systems of SDLC that were originally set up for human developers to emit at most one or two merge requests per day will not allow dozens or more per day with agentic IDEs. It also introduces a leadership problem. As a manager, you may already be dealing with tightened headcount budgets, and trust levels in your team may be low. You may lack the conviction and confidence to stand before your team and proclaim that agentic IDEs are the solution.

Yet, the opportunity to learn and lead change is huge. You now have powerful tools that can turn each member of your team into a superhuman and do impactful work. For many in their 40s and older, this may be the last big change they witness in their careers. It is therefore imperative for managers to get their hands dirty, lead from the front, and figure out how to let their teams become superhumans at work.

What Counts

Sun, 04 Jan 2026 21:55:12 +0530

Welcome to the new year. I spent my time traveling, coding, and reading during the slow period over the past two weeks. This is not the first time I have taken the time to reflect and write in long-form about what matters to me and what I believe (1, 2, 3). But this time, I’m sharing a few things without accompanying prose. These are what I want to count more, at this time.

(+) Learning to share, and earning to give away
(-) Sharing for the echo, and earning to impress

(+) Sharing space
(-) Elbowing

(+) Getting big things done
(-) Incrementality

(+) Taking time to reflect and refine, every day
(-) New Year’s resolutions

(+) Production
(-) Consumption

(+) Subtracting things
(-) Adding things

(+) Typing things, one character at a time
(-) AI-sloppery, sprayed in bulk

(+) Honest silence
(-) Platitudes

(+) Presence
(-) Rethinking the same things

(+) Personhood, playing a role on a canvas
(-) Selfhood, fixated at the center of the canvas

Thanks, Steve, for writing What Deserves My Attention Now, which motivated me to take a break from what I was doing this week.