Commonplace Notes

Commonplace note is a personal compilation of knowledge - quotes, stories, and my observations on artilces I read on topics that interest me. These range from wealth, learning, networking, life, spirituality, homeschooling, and more.

I try to explore an idea out in public (in line with my learning framework), sometimes even without agreeing to it. Think of these as scrap notes.

Edward Thorp on longevity

Edward Thorp on longevity:

The goal is to have a long life that’s also a healthy, productive one. As opposed to being in assisted living somewhere.

I want such a life. I want to be active until the last minute and be dead.

So what to do? Two things:

  • defense: minimize chances of bad outcomes which includes regular check-ups
  • offense: exercise + diet

I think of it as having two parts. One I’ll call defense, in which you minimize the chance of really bad outcomes of one sort or another. And you try to eliminate weak links. It just takes one weak link to finish you off.

This leads to proactive defenses like regular checkups or vaccinations and managing overall risks.

On offense, exercise is one of the magic bullets. The evidence is that if you exercise a moderate amount, you can probably add half a dozen years to your expected life span.

Two types of exercises:

My exercise has two parts. It’s aerobic, and it’s strength building. So I spend some time walking or maybe an occasional short jog. And then I spend time in the gym just building strength, particularly core strength. I can do two chin-ups and 15 pushups. Not a lot, but still pretty good for 91.

And then there’s diet. What one eats makes a huge difference.

From rest of the article:

  • Think for yourself. Don't err too much in the way of accepting authority and believing what’s being said, even if it isn’t properly vetted and properly executed research.
  • If there are lot of upside, but also lot of downside, wait for other's experiments
self

Don't let LLM think or speak for you

Daniel Roe:

Tech gives superpowers to people.
For good or ill, technology is a force multiplier. It enables. Unlocks.

As a lead in Nuxt project, Dan come across plenty of pull requests (PR). He lays out two rules for PR. Though he talks wrt to PR, the points are applicable for larger context.

Never let an LLM speak for you
Never let an LLM think for you

I use LLMs regularly. I use it as a brainstorming partner as well as to rewrite whatever drafts that I write — from policy docs to blog posts.

But as Dan says, whatever I goes out from me should I have my stamp on it. I shouldn't let LLM think for me or speak for me.

aieconomy

Habits with high rate of returns

James Clear:

Habits that have a high rate of return in life:

  • sleeping 8+ hours each day
  • lifting weights 3x week
  • going for a walk each day
  • saving at least 10 percent of your income
  • reading every day
  • drinking more water and less of everything else
  • leaving your phone in another room while you work
productivity, coach, self

Top Mistakes Made by Software Architects

Bertrand Florat:

time for introspection and an analysis of the most common errors I’ve observed in architectural practices

As I read through this fantastic article, I kept nodding at each mistake because I could recognize the time I made each of them.

Being a “Seagull Architect”

Seagull Architects are highly concept-oriented but disconnected from real-world issues and complexity.

Acting Like a “Factory Worker Architect”

Some architects fall into the trap of behaving like factory workers, mechanically churning out designs, diagrams, or decisions without truly engaging with the bigger picture.

Falling Into the “Golden Hammer Syndrome”

Falling Into the “Golden Hammer Syndrome”. This issue is often exacerbated by company fossilization — when architects stay in the same company for too long without exposure to external ideas or trends. Over time, they become overly comfortable with the tools and processes they know, reluctant to explore new possibilities.

As I age in this industry, I often wonder if I'm becoming a fossil. I keep myself updated by continuous learning.

Succumbing to “Résumé-Driven Development (RDD)”

when decisions are driven more by what looks impressive on the architect’s résumé than by what is actually needed for the project. Architects guilty of RDD prioritize trendy tools, frameworks, or methodologies to boost their personal career prospects, often at the expense of practicality and project success.

I can stand upright and say I have not committed this one fatal mistake. I encourage my team to choose "boring" technologies so that we don't have to be woken up at odd hours with escalations.

Trying to be “Nostradamus”

While strategic thinking is essential, attempting to foresee and address every potential issue far in advance often leads to a lack of agility and results in rigid systems that fail to adapt to changing requirements or technologies.

Pre-mature optimization is a curse which sometimes we can't avoid, especially sitting in IT services organizations. When client demand a "google" type scaling for their startup, you can only argue to some extent. When they threaten to take the business to another org, you have to shut-up and do what the client asks.

Being trapped by the Vendor’s Siren Song

overly trusting and receptive to vendors and commercials, often in the name of "better support" or "guaranteed security." This naivety can lead to costly decisions that prioritize vendor solutions over more practical or open-source alternatives.

I see this mistake so much in 2025 with the peak GenAI siren song. Everyone goes by what the vendors say in their blogs and using their tech only to get burnt as the project goes on. When there is a tight deadline there is a temptation to go with what we read in the docs. That is the time to go with "boring" tech choices.

Lacking Competence in Non-Functional Requirements (NFR) Collection and Integration

A very important skill for Solution Architects is their ability to competently collect and account for Non-Functional Requirements (NFRs). These requirements, which define the system’s qualities rather than its functions, are critical for creating a solution that is not only functional but also robust, scalable, and adaptable to organizational needs.

NFRs are mostly not discussed but come to bite at the wrong time at the wrong places. A good architect should always lead the discussion towards NFRs and capture the details as much as possible. If a system doesn't meet NFRs it is squarely the failure of the architect in the project.

tech