Blog

It’s almost a month of learning AI and building software along with AI. From understanding prompt engineering, evaluations to implementing RAG and awaiting fine-tuning opportunities, it’s been both exciting and humbling. As a solo developer using Cursor to build projects from scratch, here are my observations about the reality of AI-powered coding.

The Trust Balance

There’s a constant juggle between trusting AI completely and maintaining healthy skepticism. My journey has been as follows:

Phase 1: Micromanagement – I started by reviewing every single diff AI produced, accepting changes one by one with careful scrutiny.

Phase 2: Blind Faith – Soon, it was the opposite extreme, trusting all AI-generated code and hitting Cursor’s “Keep all” option without hesitation.

Phase 3: Automation Addiction – Then came the “Auto-run” mode, where I didn’t even want to wait to execute commands manually.

The Reality Check – Within days, my codebase had devolved into a tangled mess of spaghetti code.

The lesson? AI is incredibly powerful, but it still needs human oversight. The sweet spot lies somewhere between paranoid review and blind acceptance.

The Knowledge Gap: When AI Writes Your Code

There’s a fundamental difference between writing code manually and accepting AI-generated code. When you hand-craft every line, you maintain a mental map of your entire system. But with AI assistance, something unexpected happens:

You can end up with files containing 1,000+ lines of code that you technically authored, yet you have no clear understanding of how functions interconnect or trace through the system. It’s like being the architect of a building you’ve never actually walked through. This creates a dangerous disconnect between authorship and understanding. The code works, but the developer loses their intuitive grasp of the system’s inner workings.

Remember this xkcd joke? What if you don’t have any context to recollect in the first place. That’s what happened to me very soon.

Lazy Prompts, High Expectations

Here’s an uncomfortable truth: we’re often lazy with our prompts while expecting AI to read our minds and deliver perfect results.

I started with overly generic prompts like “You are an expert prompt engineer” and so on. But soon the prompts change this “Fix this” and “Rewrite this function” and on. The reality is that AI output quality directly correlates with prompt quality. Garbage in, garbage out – but with a twist. AI is forgiving enough to produce something from vague prompts, which can mask the fact that we’re not communicating effectively.

Key Takeaways

Maintain Strategic Oversight – Don’t swing between extremes. Develop a middle path where you leverage AI’s speed while maintaining architectural awareness.

Preserve System Knowledge – Regularly step back and ensure you understand the high-level structure of what’s being built, even if AI handles the implementation details. I might end up using some AI system to generate better documentation for this.

Invest in Better Prompts – Treat prompt engineering as a skill worth developing. Clear, specific, context-rich prompts yield dramatically better results. And build the patience to give better prompts every single time you interact with AI.

With a lot more AI development to come, I’m sure this post might get outdated over time. Exciting times!

What’s been your experience with AI-assisted development? Have you found similar patterns in your own work?

A trek with Vasudha was long pending, given the number of treks she has done so far. All this while, I’ve been mostly hiking in and around Bangalore. A real trek needed the right time and the 1 week off given by HackerRank ended up the right spot.

What made this trek a little crazy was instead of going ahead with Indiahikes or any other trekking group, we decided to do this DIY. Given this is the only possible trek that doesn’t need us to carry a tent all along the way and has a nice pitstop at Ghangaria, we just packed our bags and left Bangalore.

This was the plan till we reached Poolna. That is the last motorable village in the our trek. Post that, the real trek starts

Day 1: Poolna to Ghangaria (10kms, 6hrs, +3600 feet)

The ascent from Pulna to Ghangaria tested our preparation immediately. Carrying our own gear for four days added significant weight to what was already a substantial climb. Six hours of steady hiking felt familiar yet more demanding than our usual Bangalore treks—the same rhythmic challenge stretched over a much longer duration. The views on the way were way too stunning. We took enough photo breaks.

Day 2: Valley of Flowers

Vasudha had described the Valley of Flowers portion as “a walk in the park”—and based on every video and blog we’d consumed, we expected to enter the gate and immediately witness the famous flower beds.

We were completely wrong.

Hours of walking stretched before us, and while the trail wasn’t technically difficult, our mental unpreparedness played tricks on our minds. The disconnect between expectation and reality made each step feel longer than it should have. Eventually, though, we reached the valley proper and were rewarded with the spectacular carpet of wildflowers that makes this trek legendary.

Day 3: Hemkund Sahib – The Real Challenge

Learning from the previous day’s miscalculation, we approached Hemkund Sahib with proper preparation and realistic expectations. A 4 AM wake-up call had us on the trail by 5 AM, and we maintained steady progress throughout the seven-hour ascent.

Reaching the sacred lake at 12 noon felt like a genuine triumph. The langoor kitchen’s simple meal of tea and khichdi became one of the most satisfying meals of the entire trek

Day 4: The Descent Back

The return journey from Ghangaria to Pulna began with a mild headache that initially concerned me, but lunch and medication quickly resolved the issue. The descent proved much easier than the ascent.

Why This Trek Mattered

Shared Experience: Finally experiencing firsthand the stories Vasudha had shared from her previous treks created. Tat cafe, Beatles cafe, THE Beatles cafe, the view of the river Ganges. I’ve listen to all of them multiple times, but there is something about being there and sharing the experience with her.

Fitness Benchmark: The trek served as an honest assessment of my physical capabilities. While the Hemkund Sahib descent pushed me to my limits, completing it successfully gave me confidence for future high-altitude adventures (finding the time to do this might be the biggest challenge).

Mental Reset: Mountain trekking has a unique ability to strip away work stress and daily concerns, forcing complete focus on the immediate challenge of the next step forward.

It is hard to imagine a life without Google Maps (I’ve lived that life, though can’t remember how I survived navigation before Google Maps). Yet, the journey of how this product came to life is a story of near-failure, unexpected turns, and innovation. In Never Lost Again, Bill Kilday—former marketing head at Keyhole and a key figure in the Maps team—shares the behind-the-scenes of Google Maps product.

Top three things I learnt from this book.

1. Google Maps Was Almost Killed—But Grit and Belief Kept It Alive

Even before the acquisition, Keyhole project had multiple near death moment. Even after Keyhole was acquired by Google, the product didn’t immediately fit the company’s core strategy. Internally, Maps was seen as a side project—a distraction that didn’t align with Google’s search and ad business. The team was under constant pressure to prove its value, fighting for headcount, compute resources, and executive attention. It wasn’t until a confluence of factors—including CNN using Keyhole during the Iraq War and a compelling demo to Google’s founders—that the team gained momentum. Still, the path to success involved fighting against internal resistance, lack of resources, and even the threat of shutdown.

2. Storytelling Made the Tech Matter

Kilday, coming from a marketing background, recognized early that the Maps team needed to create emotional resonance with its product. The team didn’t just show off features—they told stories about how people could interact with geography in a whole new way. The “you-are-here” experience became a powerful narrative that made Maps not just useful, but personal and intuitive. That story helped sell the idea internally and win over skeptics, including Larry Page and Sergey Brin.

3. Limitations Fuel Creativity

Working with limited bandwidth, slow processors, and fragmented satellite data, the engineers at Keyhole had to compress massive datasets, render map tiles in real time, and deliver a seamless user experience long before smartphones were ready for it. These limitations led to invention. The team pioneered technical tricks like quadtree tiling and GPU-based rendering that later became foundational to all maps products out there.

I’ve read a lot of books about Amazon, Apple and Netflix early stage. This is the first time I’ve read a book about Google product. A must-read for early stage founders or for anyone building 0-1 products.

Found this good list while browsing the internet as the ‘Subtle Rules of Software Engineering’. These kinds of lists float around often, but this one felt especially thoughtful and more practical.

1. You WILL regret complexity when on-call
2. Stop falling in love with your own code
3. Every single thing is a trade-off – no “best”
4. Every line of code you wrote is a liability
5. Document your designs and decisions
6. Everyone hates code they didn’t write
7. Don’t use unnecessary dependencies
8. Coding standards prevent arguments
9. Write meaningful commit descriptions
10. Never ever stop learning new things
11. Code reviews are to spread context
12. Always build for maintainability
13. Always ask for help when stuck
14. Fix root causes, not symptoms
15. Software is never finished
16. Estimates are not promises
17. Ship early, iterate often
18. Keep. It. Simple.

Lists like this are both inspiring and… a little maddening. The advice is good. But like most software engineering principles, they occasionally pull in different directions.

For instance: “Always build for maintainability” vs “Ship early, iterate often”

Can you always do both? Maybe not. Sometimes you’re racing to get feedback; other times you’re investing in long-term good code. Real-world engineering often is a push-pull between quality and velocity. It’s not that one rule is better—it’s about understanding the trade-off you’re making in the moment.

Now, just for fun—what if I had to upvote only 5 of these and downvote 5?

This would be mine.

Why the top 5?

1. Every single thing is a trade-off – no “best”
Because software engineering is rarely about absolutes. Understanding trade-offs helps you make pragmatic decisions. What’s “right” today might be wrong tomorrow depending on the team, scale, or product maturity.

2. Never ever stop learning new things
The field moves fast—tools, best practices, and expectations shift constantly. Staying curious is how you stay relevant and sharp.

3. Always ask for help when stuck
This is one attribute I’ve found in the best engineers I’ve worked with. They know when to ask for help and how to unblock themselves quickly. Like every other rule, there is a trade-off here and asking help too quick and too often might also land you in trouble in the long run.

4. Software is never finished
There’s always a bug to fix, a use case to support, or a refactor to make. Embracing this helps me to design for change. You’re not building monuments—you’re evolving living systems. Think milestones and basecamps. It is not about the summit all the time.

5. Ship early, iterate often
Feedback beats perfection. Getting real-world usage fast helps you build the right thing, not just a well-built wrong thing. Early shipping helps validate ideas and keeps teams grounded in user needs.

How would you order this list? Try the app here and share your list – https://sp2hari.com/software-rules/

I got this email from Danish, one of the early engineers at HackerRank.

I’m writing this email to you to ask you whether you’d be interested in a “Blog Questions Challenge”. It’s basically a set of questions you’ve to answer in a blog post and it works like a chain. So I’m currently writing the post and then I’ll tag some folks and they’ll do the same. A ponzi scheme without a scam at the end, sorta. Here are the questions:
======

* Why did you start blogging in the first place?

* What platform are you using to manage your blog and why did you choose it? Have you blogged on other platforms before?

* How do you write your posts? For example, in a local editing tool, or in a panel/dashboard that’s part of your blog?

* When do you feel most inspired to write?

* Do you publish immediately after writing, or do you let it simmer a bit as a draft?

* What’s your favorite post on your blog?

* Any future plans for your blog? Maybe a redesign, a move to another platform, or adding a new feature?

* Who’s next?

======

Obviously, I was interested. So, here I go, sharing my answers.

Why did you start blogging in the first place?

I started blogging back in 2006, when it felt like everyone in college—friends, seniors, peers—had a blog. It was a natural thing to do: write about what you were learning, exploring, or just thinking about. Blogging turned into a habit, a way to make sense of ideas by putting them into words. It wasn’t about going viral—it was about documenting a learning journey, one post at a time.

Looking back, I’m incredibly glad I started when I did. I don’t think my blog is super popular or anything, but gives me a space to write about my experience, thoughts and learnings.

What platform are you using to manage your blog and why did you choose it? Have you blogged on other platforms before?

Right now, my blog runs on a self-hosted WordPress setup, and I’ve been using it for quite a while now. I chose WordPress for a couple of very specific and personal reasons.

First, back when I was still learning software development, I used to read through the WordPress source code just to understand how it worked. I was fascinated by how it was structured, how plugins were integrated, and how themes could customize the experience so effortlessly. It wasn’t just a CMS—it felt like a well-thought-out product with a clear philosophy behind it. That exposure deeply influenced my thinking around software architecture, and interestingly enough, a lot of the early architecture decisions at HackerRank were inspired by what I had seen and learned from WordPress. So for me, WordPress isn’t just a tool—it’s part of my developer journey.

Second, I genuinely love the freedom that WordPress offers. The vast ecosystem of plugins and themes makes it incredibly flexible. And on the rare occasion when I can’t find a plugin that does what I want, I can just roll up my sleeves and build one myself. That kind of power and extensibility is hard to find in many other platforms. Being able to completely own and customize your blogging environment is a huge plus for someone like me who enjoys building things.

I transitioned to WordPress when I finally got my own domain—sp2hari.com. That domain, by the way, was a birthday gift from my friend Manas, which makes it even more special. Before that, I was blogging on Blogspot, Google’s old blogging platform. My very first blog still lives at sp2hari.blogspot.com, frozen in time. It’s a bit of a relic now, and while I say this with a bit of embarrassment, it really does capture who I was back then: raw, naive, and figuring things out as I went. Don’t judge me too harshly for those early posts! I was young, still in college, and figuring out not just how to write, but how to think.

How do you write your posts? For example, in a local editing tool, or in a panel/dashboard that’s part of your blog?

I usually write my blog posts directly in the WordPress editor. Over the years, I’ve found it to be simple, convenient, and just enough for what I need. Since I already manage my blog through WordPress, it feels natural to write in the same place where I publish—it keeps everything in one flow.

I typically start by creating a draft with just the title or a rough outline, and then revisit it when I have more clarity or time to flesh it out. The built-in formatting tools in WordPress are more than enough for my use—especially since my writing is mostly text-focused, with the occasional code snippet or link.

Sometimes, I might jot down quick ideas in my notes app if I’m on the go, but the actual writing and editing always happens in WordPress. I like seeing the post take shape in the same environment it will be published—it keeps me focused and minimizes the overhead of switching tools.

When do you feel most inspired to write?

Interestingly, most of my writing inspiration doesn’t come from a sudden burst of creativity—it comes from a commitment. I have an ongoing blog bet with a few friends where we each have to publish a post at least once a month. That external accountability, paired with the looming deadline, is usually all the motivation I need.

In fact, most of my blog posts are the result of last-minute panic, where I scramble to organize my thoughts and hit “Publish” just in time. It might sound chaotic, but that pressure has consistently pushed me to write, reflect, and share—especially on weekends when the deadline is near.

The blog bet has become a great motivator, not just for consistency, but also as a fun shared ritual with friends. I’ve written more about how it started and what it’s led to here: Writing Bets Experiment. For now, it’s safe to say that structured panic is my main source of inspiration!

Do you publish immediately after writing, or do you let it simmer a bit as a draft?

I usually don’t publish immediately after writing. My process typically starts when I get an idea—often sparked by something I read, a conversation, or a moment of reflection. When that happens, I quickly jot down a potential title or a rough heading for the blog post. That title acts like a placeholder or a mental bookmark for the topic I want to explore.

From there, I begin outlining the structure with subheadings or key points, even if I don’t yet have the full content ready. It’s a way for me to scaffold the post, giving it some shape before diving into the details. Sometimes, that rough draft sits for days or even weeks while I mull over how I want to approach the topic.

When it’s time to publish—usually prompted by a personal deadline or one of my blogging bets—I sit down and write most of the content in one focused session. That’s when I give it the final fit and finish: refining sentences, fixing flow, and making sure the message is clear. So, while the post might look like it was written quickly, it’s usually simmered for a while before it reaches the final published version.

What’s your favorite post on your blog?

One of my favorite posts on the blog is “Advice for a Junior Software Developer”. Among everything I’ve written so far, I truly believe this is the most useful and impactful piece. It came from a place of genuine reflection—thinking back on my own early years in the industry, the mistakes I made, the things I wish someone had told me, and the small mindset shifts that made a big difference.

This post is special to me because it’s not just advice; it’s a consolidation of real experiences, hard-earned lessons, and encouragement that I hope every junior developer finds at the right time. I’ve had friends, peers, and even strangers reach out saying they found it helpful or that it gave them clarity—and that means a lot.

While I’ve written about a variety of topics over the years—some technical, some personal—this one stands out because it feels like it has the potential to positively influence someone’s journey. That’s the kind of writing I want to keep doing: simple, honest, and useful.

Any future plans for your blog? Maybe a redesign, a move to another platform, or adding a new feature?

As of now, I don’t have any major redesigns or platform changes planned for the blog—I’m pretty happy with how things are running. That said, one idea I’ve been playing with is writing a focused series of blog posts around a specific theme. In particular, I want to explore the journey of how a programmer or coder evolves into a true developer or engineer—not just technically, but in terms of mindset, habits, and thinking.

It’s something I’ve thought about often, especially when mentoring or reflecting on my own growth. There’s a big leap between just writing code and building systems, understanding trade-offs, communicating effectively, and taking ownership of a product or problem.

The goal would be to take this series beyond the blog—ideally, once I have a strong collection of well-thought-out posts, I’d love to compile and refine them into a book. It wouldn’t be just a how-to manual, but more of a guide for the transition, both practical and philosophical. It’s still just an idea for now, but it’s one I’m excited about.

Who’s next?

Adyasha, Ishan, Shloka and Vaasavi – you’re up next. No pressure!

As a founder, people often think my life is all about planning, strategy, and business. And yes, a big part of it is. But what surprises people is the simple, everyday things that make me happy—things that don’t really have a “purpose” but bring me joy.

For example, I love collecting stationery. New notebooks (muji tops the list, mnemosyne is in the wishlist), smooth pens (lamy and uniball top the list), colorful sticky notes, sketches —I enjoy them all. It’s not about being more productive or having the perfect planner. I just like the feeling of using good stationery. Collecting them gives a nice small purpose in life.

Then there’s watching anime like Naruto. Some people think it’s just for kids, but for me, it’s fun, exciting, and sometimes even inspiring. The characters, the stories, the epic battles—I love it. And yes, one of the favourite fictional character is Minato from Naruto (the other one being Ben Whittaker from The Intern)

I also enjoy growing plants. Not for any big reason, just because I like watching them grow. Seeing a small seed turn into a plant is satisfying. It reminds me that good things take time, to trust the process and focus on inputs instead of outputs.

When I want to relax, I love watching sitcoms like Friends and The Big Bang Theory. These shows never get old for me. No matter how many times I watch them, they still make me laugh. It’s nice to switch off from work and just enjoy a simple, funny show.

And one of my favorite things? Pranking or annoying people around me with silly things. Whether it’s sending weird texts, leaving random notes on their table, or just teasing them for no reason, I love it. It’s harmless fun, but the reactions make my day. Some people are shocked that I do this, but life is too short to be serious all the time!

I especially enjoy troubling the interns at work—making random bets with them, giving them funny challenges, or just making their day unpredictable. It keeps things fun, and honestly, I think they enjoy it too (even if they pretend they don’t).

People expect me to always be thinking about technology, business, growth and future. But not everything in life needs to be productive. Some things are just for happiness—and that’s reason enough to keep doing them.

I hope everyone have their own list of small things that make them happy, even if they don’t have a “purpose”.

A few months ago, I wrote about my decision to start reading fiction, inspired by a conversation between Tim Ferriss and Claire Hughes Johnson. The idea of reading fiction to build empathy was an out-of-the-box idea (at least for me). However, what makes this experience even more unique is that I read this book in a physical format—something that has always been a challenge for me. The promise made in this post https://sp2hari.com/fiction/ is finally done.

For the longest time, I have preferred audio books. Listening to physical books while walking is my only way of consuming them. I lacked the patience to sit at a place and read a book. Phone and laptops were a few steps away and kept me away from physical books.

1. Book vs. Movie: The Backstory Makes the Difference

One of the biggest surprises about reading A Man Called Ove after watching the movie was how much more depth the book provided. The movie does an excellent job capturing Ove’s grumpy yet loveable personality, but the book gives a much richer context to his life experiences.

For instance, the book shares more details about Ove’s early life—his years working as a railway cleaner and later as a construction worker building houses. These moments provide valuable insights into how he became the person we see in both the book and the movie. His relationship with his father, his strong moral code, and his belief in hard work are all developed in a way that the movie simply doesn’t have time to explore. This additional context makes his stubbornness and his sense of right and wrong feel much more grounded.

2. The Emotional Impact of the Ending

One of the important moments in A Man Called Ove is the final scene. I went back and watched the movie’s ending again (you can find it here: YouTube Link), and I noticed an interesting difference. The letter Ove leaves behind in the movie feels longer and more dramatic, whereas in the book, it’s much more concise.

This is a classic example of how books and movies handle emotional moments differently. The movie draws out the emotions, making the farewell feel grand and cinematic, while the book delivers it in a more subtle and understated manner. Personally, I found the book’s version more effective—it felt more in line with Ove’s character, a man of few words who expresses love and care in actions rather than long, sentimental letters.

Overall, glad that I read the book. I enjoyed the movie, but learnt a LOT from the book. Something that I’ll recommend to everyone (even if they’ve watched the movie).

There are a lot of books that talks about building a team/company. There are books that talks about planes (something I’m forever fascinated about). Very few books can teach you both and this is it. Skunk Works by Ben Rich is a fascinating book (don’t even remember the number of times I’ve listened to this one). It shares behind-the-scenes stories of— Lockheed’s Skunk Works, famous for producing legendary aircraft like the U-2, SR-71 Blackbird, and F-117 Nighthawk stealth fighter.

More than just an engineering story, Skunk Works is a masterclass in leadership, innovation, trust, and most importantly, speed—qualities that resonate deeply with me as I’ve adopted Speed as my personal theme for 2025.

These are my top takeaways from the book.

The Power of Small, Agile Teams

One of the key takeaways from Skunk Works is the critical role of small teams in driving innovation. The division didn’t rely on large bureaucracies, endless meetings, or rigid processes. Instead, it thrived on having a lean structure where engineers had the autonomy to make decisions quickly.

In an era when companies are often bogged down by hierarchy, this approach feels like a breath of fresh air. Small teams with end-to-end ownership, minimal red tape, and a clear mission can move mountains. It’s a reminder that to move fast, you need trust, clarity, and minimal overhead.

Trust as a Non-Negotiable Foundation

Kelly Johnson, the founder of Skunk Works, built his division on the principle of trust—both within the team and with their stakeholders, especially the government. He operated on handshake agreements and trusted his engineers to deliver results without micromanagement. Trust allowed Skunk Works to bypass slow procurement processes, eliminate bureaucracy, and focus entirely on solving hard problems. While building startsups/companies, we prioritize speed and agility, but without trust, those are impossible.

Speed and Innovation Go Hand-in-Hand

At the heart of Skunk Works is the theme of speed. The team had a mandate to develop groundbreaking technology under severe time constraints. Whether it was developing the U-2 spy plane in just eight months or delivering the F-117 stealth fighter ahead of schedule, Skunk Works thrived under pressure.

Speed didn’t just mean working faster—it meant cutting out unnecessary steps, focusing on what truly mattered, and making bold decisions quickly. For me, this perfectly aligns with my personal theme for 2025. Speed doesn’t mean recklessness; it means disciplined focus, rapid iteration, and an obsessive drive to deliver.

A Culture of Bold Experimentation

Another key element of Skunk Works’ success was its culture of experimentation. The team was encouraged to take risks, think unconventionally, and explore new technologies. This experimental mindset led to many failures—but also to some of the most revolutionary aircraft in history.

As someone who enjoys working on experimental products and side projects, this lesson feels especially relevant. Whether it’s a new feature for a product, a blog post, or even a new way of conducting mock interviews, experimentation is the fuel that drives innovation.

Bringing Skunk Works into My Own Projects

Reading Skunk Works has given me a renewed sense of purpose and clarity. Whether it’s a new product or any other project, I want to incorporate the principles of speed, trust, and bold experimentation.
• Speed will come from focusing on what matters, cutting out distractions, and empowering small teams or even solo workstreams.
• Trust means giving myself (and collaborators) the freedom to work independently without micromanagement.
• Experimentation means being unafraid to try new approaches, knowing that even if I fail, I’ll learn something valuable.

Skunk Works isn’t just a book for engineers—it’s a book for anyone who wants to build something extraordinary. It teaches us that true innovation comes not from size or resources but from speed, trust, bold thinking, and an unrelenting focus on solving hard problems.

As I move forward with my personal theme of speed in 2025, I’ll carry these lessons with me—knowing that even in the face of daunting challenges, bold teams (or individuals) who move fast can change the world.

A topic that has been something I’ve been talking a lot to the rest of the company. These are the builders who don’t just write code—they design experiences, solve problems, and ultimately solve customer’s end to end problem.

The role of a product engineer extends beyond traditional software development. They bridge the gap between technical capability and user-focused design. Unlike backend engineers who focus on system architecture or data engineers who specialize in pipelines, product engineers work on bringing a product vision to life in ways that delight the end user. It’s one thing to say “I write code” and it’s another to say “I solve this problem for the people by writing code.”

Key Traits of Product Engineer

1. Customer Empathy
   A product engineer spends as much time thinking about who will use their product as they do about how it will work. They understand the user’s needs, pain points, and goals.
2. Collaboration
   Product engineers work closely with designers, product managers, and other stakeholders. They own both the idea and the execution.
3. Attention to Detail
   Whether it’s the performance of an API or the animation of a toggle button, product engineers know the small things can make a big difference in user experience.

Below are a few slides from a recent talk highlighting the importance of having product engineers in the team. These entire presentation was much longer, but these slides focuses on the product engineer role. The talk track for these slides are added along with each slide.

It is good to have a team of a product engineers. There is my definition of product engineers. Writing code is JUST one part of the the job. Talking to users, getting involved with design and taking product decisions. Normal engineers think only about the code. All their problems revolves around code. And of course, move with the urgency. Moving at high speed is core.

The internal joke we have within our team is that we use the term “code monkeys” (no disrespect to monkeys that can code) and what product engineering means. You are involved in every single aspect of the product and not just the “development”. That means you can’t build something and throw it to the other side for maintenance. The engineers are responsible for QA, Support and Deployment (usually pushed to QA team, Support team or DevOps team)

As we started working on this, these are two good books that might help your engineers start with the product thinking. In fact, after reading “The Mom Test”, our engineers try to get the right validation before thinking of releasing a feature.

One positive side effect of the engineering team turning into product engineers is that they are more closer to the customers. For example, here are a couple of support tickets handled by the team. This is the only team handling support tickets and have the access to directly respond to the end users. And that’s because the team cares about users.

Here are some more links if you want to understand the concept of product engineering in detail

1. https://posthog.com/blog/what-is-a-product-engineer
2. https://productengineer.org/
3. https://www.cycle.app/blog/the-product-manifesto

And so, what is the role of a product manager when the team is full of product engineers. Can we eliminate this role if everyone in the team is a product engineer?

Unfortunately no. In fact, I’ve come to the realization that you need a good product manager when the team is full of product engineers.

While having a team of product engineers is a good thing overall, at times, you tend to pull in different directions. Imagine an object pushed in different directions from all sides, the object won’t move at all. For example, one engineer might talk to a user who would complain that the website is slow, another engineer talk to a user who might complain about lack of translation. Ultimately, the product manager takes the final veto call in the overall direction and guide multiple product engineers in the same direction.

While every engineer might consider themselves as product engineers, here’s a checklist to see if you are really a product engineer.

Have you worked with or as a product engineer? Share your thoughts and stories.

For as long as I can remember, I have read only business and professional growth books. Fiction never made it into my reading list when I was thinking about work or learning. You can check out my full reading list here: https://sp2hari.com/books. It’s all about learning and growing in my career.

The only fiction book I have read is The Little Prince, and that was only because my friends pushed me to read it. They thought I needed a break from all my business books. Even then, I couldn’t help but find lessons from it, which I wrote about here: https://sp2hari.com/the-little-prince.

But recently, I started to change how I think about fiction. I listened to an interesting chat between Tim Ferriss and Claire Hughes Johnson that made me stop and think. Tim asked Claire why anyone should read fiction. Is there more to it than just learning about human nature? (I think he was more like me, where he strictly avoided reading fiction)

Tim Ferriss: So what are the reasons to read fiction aside from the, as I think you put it earlier, the insight into the human condition? If you were trying to get someone to take that first bite of the forbidden apple of fiction, are there any other points that you would make?

Claire Hughes Johnson: How do you build empathy? How do you understand everybody has a story? I mean, you’ve traveled a lot, Tim, but a lot of people you and I both know haven’t traveled the world, they haven’t been to that many countries. Do you want to go to another country? Find a great novel that’s been translated from that country, and read it, and you will understand that country in a way that no travel guide will ever give you, in my opinion. So I think it’s a very cheap way — and there’s also to build emotional intelligence.

I think I’ve worked now in tech companies for over 20 years, and when you sort of get to certain levels of responsibility with management and leadership, you could be technically the smartest person in the room, but if you have no emotional intelligence or dimensionality in contemplating emotional states, you are going to struggle. You are going to struggle to lead. And so when I say understand the human condition, I don’t just mean, “I’m reading a book and I understand, wow, that’s how it might feel to be in a divorce or that’s how it might feel to lose your child or — ” I’m saying, no, you yourself, as the reader, if the book is really good, start to feel the feelings. You start to feel like, “Oh, I lost a child.”
Emotional exercise is hard. It’s either happening to you, so you’re going through an emotional situation in your own life, which is hard, but doesn’t happen every day to most people, or you’re going to get emotional exercise from, in my experience, a lot of people get it from film.

[…]

Claire Hughes Johnson: But anyway, point is, I think it’s emotional workout. Literature, great films.

You can listen to the entire podcast at https://tim.blog/2024/02/27/claire-hughes-johnson/

This idea was new to me. Fiction might not just be for fun or creativity; it could actually help me grow as a leader and a friend. It’s like a type of training for your emotions, which doesn’t happen in everyday life.

The first book I’m going to pick from the fiction is this one – A Man Called Ove.

I have already watched the movie, and it even made me tear up at the end. People say the book is even better, with more depth and feeling. Even if I already know the story from the movie, I’m excited to see what the book has to offer. Let’s see how it goes.

One of the values we’ve recently added at HackerRank is something close to my heart. Like our other values, this one had taken on different forms in the past, but the current version resonates with me far more: we call it “Truly, Madly, Deeply Care.”

In the past, we used the phrase “Customer Delight” Amazon has their version: “customer obsession.” But for us, Truly, Madly, Deeply Care captures what we aim to achieve in everything we do—going above and beyond to deliver something extraordinary.

Once we embraced this mindset, we began to notice examples of it everywhere—features, services, and products that reflect that same level of care. It’s in the tiny details that make a product stand out. For example, have you ever noticed the iOS weather app? The raindrops actually bounce when it rains. It’s a small touch, but it shows the level of detail and thoughtfulness that goes into creating something meaningful and delightful.

Another example is the Swiggy app. When you try to place an order from a hospital, you get a thoughtful message—considerate of the context and environment. This is a small but powerful reflection of care that extends beyond just delivering food.

In our own office, the way kitchen paper napkins are stacked neatly – nobody instructed the support staff to do this, yet they’ve done it with such care. It’s a simple act, but it speaks about the pride people take in their work when they care deeply about what they do.

And that’s the beauty of Truly, Madly, Deeply Caring. When you care deeply about what you create, it becomes a source of pride.

This level of care reminds me of a moment from Steve Jobs, during an event when he was asked about Apple’s pricing strategy. Rather than focus on market share, Jobs spoke about Apple’s philosophy:

This philosophy resonated with me deeply, as it encapsulates what “Truly, Madly, Deeply Care” means. When you care profoundly about what you create, it’s not just about market share or profits—it’s about pride, craftsmanship, and creating something that you would stand behind without hesitation.

In that spirit, I’m creating a new page called https://sp2hari.com/care, inspired by Patrick Collison’s page on fast products. My goal is to capture examples of products and services that have gone above and beyond – whether it’s a thoughtfully designed button, a small but meaningful interaction, or something grander. Over time, I hope to see this list grow, showcasing products that embody truly madly deeply care .

If you come across any product or experience that you believe reflects this level of care, please drop me a note—I’d love to add it to the list.

Git is a powerful tool and I’ve been using it for years. But there are few commands that make me feel like a power user. I use the basic commands like git add, git commit and git push everyday, there are some advanced commands that can significantly workflow and troubleshooting process.

git bisect

Have you ever faced a bug in your code but had no idea when it was introduced? This is where git bisect comes to the rescue. It’s essentially a binary search for your Git history. You start by specifying a commit where the code was known to work, and the commit where it’s broken. git bisect will then help you automate the process of checking commits in between, narrowing down the problematic commit.

While it is easy to imagine how git bisect works, the true power comes in using it in the real world. Here is a GitHub repo where you can try this out and a bug was introduced in one of the earlier commits.

https://github.com/sp2hari/learn-git-bisect-example

Clone the repo and you can try the bisect command by running the following commands

$ git clone git@github.com:sp2hari/learn-git-bisect-example.git

#Start the bisect by providing the bad commit id and good commit id
#Bad commit = current commit. Good commit = first commit of the repo.
$ git bisect start origin/main d613b3f
Bisecting: 5 revisions left to test after this (roughly 3 steps)
[a43319812e06febe1491739d2921d72cc28a0aae] Make text bold

#Load the webpage and check if everything works as expected (it does)
$ git bisect good
Bisecting: 2 revisions left to test after this (roughly 2 steps)
[e4ea05da47c825016d4de2bd4b6cb6ce4b5df7e2] Add comments

#Load the webpage and check if everything works as expected (it doesn't)
$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 1 step)
[fcc3b7e7ee805bc37624ef90795775dbf7168772] Update the text in the form

#Load the webpage and check if everything works as expected (it doesn't)
$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[fa574427d1b5ccc3fb2ce756277f3f819089f6d1] Change the rules of universe

#Load the webpage and check if everything works as expected (it doesn't)
$ git bisect bad
fa574427d1b5ccc3fb2ce756277f3f819089f6d1 is the first bad commit
commit fa574427d1b5ccc3fb2ce756277f3f819089f6d1
Author: Harishankaran K <hari@hackerrank.com>
Date:   Sun Sep 8 19:16:07 2024 +0530

    Change the rules of universe

 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git bisect reset

Why it’s a power move: Instead of manually hunting through your Git history or rolling back changes aimlessly, git bisect turns what could be hours of debugging into a methodical and efficient process.

git reflog

Sometimes you make mistakes, and sometimes those mistakes make you think you’ve lost work for good. Enter git reflog. While the normal Git history shows the sequence of commits, git reflog shows every action that has altered the state of your Git repository, even ones you thought were lost (e.g., after a reset or rebase).

Clone this repo https://github.com/sp2hari/learn-git-reflog-example

$ git clone git@github.com:sp2hari/learn-git-reflog-example.git

#Make a change 
$ echo "HackerRank Labs Team" >> index.html
$ git commit -am "Useful commit"

#Make mistakes to lose the changes. 
$ git reset --hard origin/main

$ git reflog
77bd8ba (HEAD -> main, origin/main, origin/HEAD) HEAD@{0}: reset: moving to origin/main
180ef43 HEAD@{1}: commit: Useful commit
77bd8ba (HEAD -> main, origin/main, origin/HEAD) HEAD@{2}: clone: from github.com:sp2hari/learn-git-reflog-example.git

#You can recover the id of the "Useful commit" (180ef43 in this case)

Why it’s a power move: git reflog is like a safety net, giving you the ability to recover commits that don’t appear in your normal history. Whether you accidentally reset your branch or lose a commit during a rebase, git reflog lets you trace everything back.

git cherry-pick

Need to apply a commit from one branch to another without merging the entire branch? git cherry-pick is your friend. This command allows you to apply individual commits from one branch into another, which is particularly helpful when you want to introduce fixes or small features selectively.

$ git cherry-pick <commit id>

Why it’s a power move: Rather than merging two branches and potentially introducing unintended changes, git cherry-pick gives you precise control over which commits you pull into your current work. It’s ideal for bug fixes that need to be deployed quickly but are isolated from ongoing development.

git rebase

git rebase is one of the most misunderstood commands, but once you master it, you’ll have cleaner, more linear commit histories. Instead of creating merge commits, git rebase rewrites history by placing your changes on top of the latest state of a branch.

https://github.com/sp2hari/learn-git-rebase-example

$ git clone git@github.com:sp2hari/learn-git-rebase-example.git
$ git config --global core.editor "code --wait"
$ git checkout feature-multiply
$ git rebase -i main

Why it’s a power move: It keeps your commit history cleaner and more readable by avoiding unnecessary merge commits. It also enables you to better organize your changes before they’re merged into the main branch, creating a more streamlined history that’s easier to navigate.

In conclusion, using these advanced Git commands allows you to troubleshoot more efficiently, control your history with precision, and recover from even the trickiest situations. Mastering commands like git bisect, git reflog, git cherry-pick, and git rebase can elevate your Git game to the next level.

There was a lot of chatter among my team members about how great two picture books they read. Here are all the picture books I have read and my favorite parts.

Big Panda and Tiny Dragon

This story is about two friends, a big panda and a tiny dragon, who travel together during the changing seasons. This is one of the few books with different seasons as the chapter names.

My top three picks from this book.

1. ‘Which is more important,’ asked Big Panda, ‘the journey or the destination?’
   ‘The company,’ said Tiny Dragon.
2. ‘Sometimes, you just have to be silly.’
3. ‘How is that tree still standing?’ asked Tiny Dragon
   ‘During better times,’ said Big Panda, ‘it grew deep roots. Now it can weather any storm’.’

The Boy, the Mole, the Fox and the Horse

My top three picks from this book.

1. “Asking for help isn’t giving up,” said the horse.
   “It’s refusing to give up.”
2. Be curious.
3. “Being kind to yourself is one of the greatest kindnesses,” said the mole.

Sapiens A Graphic History (Vol 1 and 2)

The original book is actually much better than the graphic book. Without reading the original book, I’m not sure if I would have figured out the whole story

Zen pencils

Don’t make stuff because you want to make money…
… it will never make you enough money.
Make gifts for people.
And work on making those gifts in the hope that those people will notice.
Maybe they will notice how hard you worked…
…And maybe they won’t.
And if they didn’t notice…
… I know it’s frustrating.
But ultimately that doesn’t change anything because your responsibility is not to the people you’re making the gift for…
…BUT TO THE GIFT ITSELF.

Calvin & Hobbes

I love each and every one of Calvin and Hobbes. Consider yourself lucky if you own this entire collection and if you’ve read the whole thing at least once in your life. After 10 years, this is the last post with which they finished the whole series. It’s something I look forward to every day!

Back to writing blogs again… and hoping to continue the tradition going forward.

Back in 2023, I had a bet with many of my friends. The deal of the bet varied with different people, but the core was this.

Both the parties involved will write a blog once every month (published on the first full weekend of the month). If one of the parties involved doesn’t write a blog, the losing party gives the winner a 10 rupee note with an apology note written on that.

The winning notes look something like this.

In December last year, I found myself completely burnt out, overwhelmed by the list of pending tasks that seemed to grow by the day. Each morning, I woke up with a sense of dread, knowing that I was falling further behind despite my best efforts. Weekends were even more intense, trying to balance work (like hiring and writing code) and hobbies (like hiking and gardening). What made the situation even worse was the impact it had on the team. They were relying on me, counting on my contributions and leadership to help us achieve our goals. Yet, I was letting them down with excuses many times. They were accommodative, but still that didn’t help me. I had to figure this one out by myself.

Another possible reason (the one I shared with everyone to explain the reason), I wrote about this at https://sp2hari.com/minimal-motivation/. I wondered if I wrote only once (exactly on the first weekend) because of the bet. I naively assumed that if I didn’t have the bet, I might end up writing more. Little did I know, I’m born lazy and won’t do anything unless I have.

The six-month break helped. Writing a blog, even if it is once a month, is a lot of pressure. Throughout the month, it was tiring come up with something blog-worthy.

But I believe the blog break is temporary. In the long run, writing is a habit I want to improve and share with others. Funnily, many folks also stopped writing once the blog bet stopped.

The only exception to this experiment was Vasudha. She wrote more than once a month (actually between 8-12 times every month), so she probably has a lot more self-motivation than the rest of us in the blog bet group.

If you want to read all the blogs part of this bet, you can check the list here – https://sp2hari.com/bets/july24.html

I promised myself that I wouldn’t do a year-end wrap blog post in December. I lived up to the promise.

I promised myself that I wouldn’t write about resolutions, plans, or goals for 2024 and I’m going to fail on that promise. I’ve always believed Jan 1 is yet another regular day in the calendar and it shouldn’t be considered special in any way (the same rule applies for birthday’s too). But truth be told, I’m running out of topics to write a blog and I have to write one for Jan, so here it goes.

I’m going to convince myself that I’m following this rule from Atomic Habits and it is not the lack of topics for this blog post.

How to break a bad habit
Inversion of the 4th Law: Make It Unsatisfying
1. Get an accountability partner. Ask someone to watch your behavior. 
2. Create a habit contract. Make the costs of your bad habits public and painful.

So here are the resolutions/goals/todos for 2024 in no particular order.

1. Learn swimming
   Cooking, driving, and swimming are probably three life skills one should have. I can drive and Vasudha can cook and that covers for two of the three skills together. Unfortunately, swimming is something both need to know individually, and just one person knowing it is not going to help the other one.
2. Travel to Denmark
   This has been a long pending task on my list and at this point, I’m not even sure what is stopping me.
3. Do a trek with Vasudha
   Vasudha completed two treks back to back in 2023 and is planning to do one every quarter in 2024 (talk about quarterly goals). Hoping to join one of them in 2024.
4. Do more hikes (hopefully every weekend)
   I’m assuming this will happen automatically given this has become a habit.
5. Operate at the no-excuse zone at work.
   There are lot of “valid reasons” because of which it is getting harder to focus on the real work.
6. Walk 10k steps per day and 100k per week
   This is a new challenge with some of the other folks in the company. Hoping to get this done in 2024 more often than not.
7. Find time to read 30 mins per day
   This is something new I’m planning to pick up this year. Learning has been only through audiobooks and this year, hopefully, I’m able to pick up real books.
8. Stop driving to the office.
   Either hire a driver or start using DriveU daily. Driving in Bangalore is not great for mental health.
9. Leave the office at 4 PM (and of course, work from home for the rest of the day)
   Working half day in office and half the day at home is probably a good productive hack.
10. Complete TinyChange notebook every day
    Got this notebook from Ishani as a gift and hoping use this to improve the quality of the life in 2024. This needs a lot of input (updating this everyday).

Building a team or a company gives one a chance to make a lot of decisions at various stages. If you are lucky, some of them will be two-way doors, but most of them are one-way doors. Here are a few I can think of that I had to decide or think about at some point in the past (10+ years).

Speed vs Quality ‘Culture’

When I wrote the heading, I was mostly thinking about software development. But the path one takes ends up expanding in all other teams/departments as well. While the immature assumption is we need the speed at the early stages of the product and we can focus on the quality later, things never go down this way. There is never a clear distinction between what is the early stage of product development where speed is needed and what is the later stage of product development where quality is needed. https://patrickcollison.com/fast is a set of projects that might inspire you to move fast. I’m not sure if all of them had high quality though.

One anti-pattern when it comes to speed vs quality is probably the Apple iPhone releases. There is an expectation to release something new every year and every innovation (not sure if we still have any new though) must be tested thoroughly before it gets in our hands. Hardware is very unforgiving with bugs. Intel learned this lesson the hard way.

Team vs Family ‘Culture’

This is another difference in how one can build a team. And again, different successful companies have been created focusing on the team & family. A clear example of we are just a professional team is Netflix.

Here is an excerpt from https://jobs.netflix.com/culture

We model ourselves on being a professional sports team, not a family. A family is about unconditional love. A dream team is about pushing yourself to be the best possible teammate, caring intensely about your team, and knowing that you may not be on the team forever. Dream teams are about performance, not seniority or tenure.

Family is the other end of this spectrum. Salesforce is the best example of this. Here is an excerpt from https://www.salesforce.com/blog/what-is-salesforce-ohana/

In Hawaiian culture, Ohana represents the idea that families — blood-related, adopted, or intentional — are bound together, and that family members are responsible for one another. When he created Salesforce in 1999, he made sure that “Ohana” was in the company’s foundations.

This is probably the most confusing one to pick, since both the options are equally good ones.

Spaces vs Tabs

Being a developer, I need to write this. But this is probably something I should add. This probably is the meta for all the technical decisions which I can never change now. The choice of cloud (AWS vs GCP vs Aure). The database choice and programming language & framework choice feel like a two-way street at the start, but after a few years, the company is married to those decisions.

Of course, many other bigger decisions feel like one-way, but it is not impossible to change them later. For example name, branding, founders, and legal structure all feel like one-way decisions. But we’ve made changes in every one of them.

We initially called the company Interviewstreet and then changed it to HackerRank. We started as 4 co-founders, but only two (me & Vivek) ended up starting this eventually. We started the company in India but finally reorganized the company structure once the US entity was formed.

These are the three one-way decisions I could think of based on the past. I don’t know the right answer for any of them even today. Wonder how many more one-way vs two-decisions lay in the path ahead.

We had our leadership offsite in the US this week and one of the lines mentioned in the culture session is still on top of my mind.

For example, you can have a culture where you treat everyone as a family. Salesforce is a clear example of this.

In Hawaiian culture, Ohana represents the idea that families — blood-related, adopted, or intentional — are bound together and that family members are responsible for one another. When he created Salesforce in 1999, he made sure that “Ohana” was in the company’s foundations.

https://www.salesforce.com/blog/what-is-salesforce-ohana/

You can have a culture where you treat them as a team (almost like a sports team). In this case, if you don’t perform well, you don’t get to play the next match. Netflix and Snowflake are the best examples of this.

Organizations need to accept that they don’t owe their people anything more than ensuring that the company is making a great product that serves the customer well and on time. They don’t owe people the chance to take on a role they’re not prepared for and don’t have the talents for. They don’t owe them a different job created to reward them for their service. And they certainly don’t owe them holding the company back from making the personnel changes needed to thrive.

Powerful, Patty McCord

Another distinct example is Amazon vs Google. Amazon is known for their frugality and if you want a bottle of water in their office, you can buy it from their kiosk. Google is known for giving free food, massage chairs, and everything else. Both are super successful companies and have defined their strong culture.

Culture is what you already have and are doing. Not what you want to copy from others. Makes me wonder what culture I personally have, what culture the teams I manage have, and what culture the entire company has. Are they one and the same or are they all different? Should they be the same or can they be different? What are the micro-adjustments and macro-corrections we need to make to our culture?

Questions to ponder for the upcoming months.

I’ve been wondering about this for a while and still can’t understand my/human behavior. I’m a grown-up adult, who knows about responsibility. I know I’m responsible for my own career, growth, etc. I give enough advice to others about extreme ownership and how they should own their career growth. I also understand how doing just the bare minimum might not always be the best.

Even with all the knowledge I’ve seen only the bets I have with other friends have helped me in my growth so far. I have this bet with others (folks who are accountability partners) to ensure make I do things that I want to do. Manas explains about the bet here.

The first bet I have with many many people is writing a blog every month (the first weekend).

I write exactly one blog per month. I’ve always wondered what is stopping me from writing two blogs a month. Why do I stop at just one post a month? And how many I am able to achieve one per month easily, but one extra post seems like a herculean task. Another fact is that I started writing the blog on Sunday morning when the bet deadline was about to expire. It is almost like I’m writing the blog just to not lose the bet. Without the bet, I might never a blog (even though I understand why it is good for me)

The next bet is to ensure I walk a given number of steps per month. This one is even more interesting. At first, the number of steps I had to cover was 70K/week. For months, my step count was around 70-75K per month. Then we decided to increase the number to 100K (since we found the 70K goal) to be too low. Again, this bet I had with multiple people, but the amount of steps to cover varied for different folks. Here is the simplified version of the number of steps I covered every week.

Strange observations from the table

1. I’ve never lost a bet. I’ve made sure I’ve walked what is required for that week.
2. I’ve walked just enough to win the bet. If the goal is too low, then that’s all I walk.
3. When I had no bets with anyone, I almost stopped walking or doing any physical activity.
4. Some of the numbers I considered impossible (100K steps a week) were actually possible once I had the bet.

My inferences so far

1. I’m a competitive person. I hate losing and hence will do anything/everything to win the bet.
2. It is hard to focus on things that help us grow in the long term. One needs help in ensuring we stay on track to focus on the right things. Help = having the right accountability partner.

I still don’t know what is stopping me from doing more than what is required as a part of a bet. Still exploring!

Even after fully going remote more than 3+ years ago, I still have a lot to learn about being productive in meetings. Zoom fatigue is real and sometimes jumping meeting after meetings makes it harder to focus on the right thing.

Before the meeting

Installing Meetingbar. Probably the single most productive step I’ve done to make it easier for me to join one call after another.

The most important setting that matters here is – Having a keyboard shortcut to automatically join the next call (I prefer Command + Shift + J). Another useful feature is that it shows the time for the next meeting. This helps me pick the task of the right size before the next meeting starts.

During the meeting

Everyone hates interruptions. In fact, I’ve even written custom scripts on top of Gmail to ensure I don’t get interrupted by new emails.

The above settings ensure Focus Mode is turned on every time I join a call. This was the toughest change to make. I’ve been given this feedback often that I multi-task a lot when I am on calls. I get interrupted many times during the call with multiple Slack messages or emails. With DND turned on, I don’t even get phone calls. Missed a call from the Swiggy delivery folks, but the delivery did reach my location. Wondering if those confirmation calls are not even needed.

After the meeting

The best productivity trick after a meeting is to have some free time to recover after the previous meeting. What helped me the most was to keep the meeting to 25 minutes (instead of 30) or 50 minutes (instead of an hour). Google Calendar has an option called ‘Speedy Meetings’ so that the events we create by default have a few minutes break before the next call.

Useful Links

[1] https://amivora.substack.com/p/5-tips-to-make-context-switching

[2] https://www.youtube.com/watch?v=ogMptOS2Vzk

This started as a tradition with one of my colleagues (Radhika Balaji) where we started sharing one new thing to learn every day. This got triggered when Radhika shared how she used to learn new things every day when she was in school and stopped this during board exams. Post the board exams, she never started the habit (for at least 4+ years). We decided to restart this tradition and continued this for multiple months. Here is the list of the things I’ve shared and things that I received.

For multiple reasons, I stopped doing this tradition and wish I could restart this again with more folks again.

Shared by me

1. I’ve started watering all our plants regularly and was trying to find out the optimum time and frequency to water the plants.  Found this interesting video. https://www.youtube.com/watch?v=d60lqIfGeQw
2. https://www.youtube.com/watch?v=jbtp2YsZUI8. The amount of effort going into making something awesome is always great to watch. 
3. https://twitter.com/Rainmaker1973/status/1616518328872304642. There are two things to learn here.  a) Physics and that is what you see in the video. b) How to make something interesting. How to teach and excite someone about ideas. I wish my teachers taught me this way. And I wonder what I can do like this when explaining concepts/ideas. 
4. What does a king with a rotten tooth and an advanced computer technology have in common. https://twitter.com/culturaltutor/status/1623121201026502658?s=46&t=AG1C44Bj8nDOLzyN7s-cNg
5. A small, but nice video about why SR 71 is the greatest and latest 🙂 https://twitter.com/IntEngineering/status/1617235651396620288. And my tweet about the same! https://twitter.com/sp2hari/status/1618860297556566018
6. Found this while browsing the internet. There were few other shorter videos, but this was the best. Watch this when you have full 20 mins free time. https://www.youtube.com/watch?v=Iod6uwUGM2E
7. https://www.youtube.com/watch?v=qfPt8J95R-A Love the animations and the way it is explained.
8. Airport codes. This is a bigger mess, I think it is impossible to fix now 🙂 https://www.youtube.com/watch?v=jfOUVYQnuhw
9. One interesting read on how good design can change the way we behave – https://www.bicycling.com/news/a20027122/vanmoof-tv-on-box-damaged-bikes/
10. https://sive.rs/berklee. Love this post. Clean clear advice based on experience. 

Shared by Radhika

1. Glue People – https://bigthink.com/leadership/how-to-succeed-at-work/
2. This was a wonderful example of Design thinking and innovation: https://youtu.be/M66ZU2PCIcM
3. Do you know what the end of a shoelace is called? https://youtu.be/VwizJNvl62U
4. I saw this and thought it was absolutely crazy. Such a daring project. I wonder if there are any height restrictions for buildings. Even my town has them. https://www.youtube.com/watch?v=aKwkMZbeeGo
5. I hate to admit it but I might actually start believing in gods.  https://www.youtube.com/watch?v=0uBYomUSOoM. This video felt really good, there’s sooo muchhh we don’t know yet. Hope you like it too 🙂
6. Every time I fly, I try to look at the wheels out the window. It made me wonder, how can a huge plane be supported by such tiny small wheels? So I found this video. From the second minute, they explain how it’s a well-calculated call. https://www.youtube.com/watch?v=v2e4TvT9cvg
7. The original proverb should have been “Practice makes myelin” 🙂 https://www.youtube.com/watch?v=f2O6mQkFiiw
8. Rumours are very powerful. There’s a common misunderstanding that kurkure has plastic. I have been eating it because I like it’s flavours and was curious if the plastic rumour was true.  Apparently it’s not.  Crazy how everyone’s been conditioned to believe something and not question it at all. https://en.wikipedia.org/wiki/Kurkure
9. What was Y2K, How did the media twist this, and how it ended. https://www.youtube.com/watch?v=kyZDa09U7gc. It happened in 2000. Maybe you remember it. It looks like total chaos.
10. I was researching the Pentagon when I came across a US defense website and somehow ended up here: https://www.defense.gov/Multimedia/Experience/Top-Gun-The-Edge-of-Aviation/ After the movie, this group became super famous. I love one part here a lot: The students who graduate from here return to their squads and fleets and become teachers. The performance of their own units improves significantly due to this. Even though this seems like common sense, I love it because it’s not very common I feel.

While the list may or may not be interesting for everyone, what I enjoyed the most was the subsequent discussions we had about each and every one of these topics. It was one of the ways to understand new topics and also a different perspective on topics outside your comfort zone.

If you had to share a list of new things to learn, feel free to send it to hari at hackerrank dot com. Always interested in learning new things 🙂

Life update:

We bought a new place last year and moved to this place a month ago.

Second-order effects on the life update.

1. We moved from Koramangala to Harlur. I’ve been living in Koramangala from 2010 to 2023. Not just that, we’ve limited our life to Koramangala and moving to a different place is just odd.
2. My sleep cycle got much better now. I have to sleep early and get up early (around 7:00 AM) to avoid traffic.
3. Traveling to the office just got interesting with so many modes (car, bus, cab, walk)

Life was easier for the last few years. Walking from home to the office used to take exactly 12 mins. Traffic or no other external factors couldn’t change anything this number. In fact, I could step out of the house at 9:45 AM for a 10:00 AM call in the office.

After the move to Harlur, a few more options got added. The first one is to drive to the office. While it appears to be the most comfortable option, traffic starts killing you slowly. For example, the following happened one of the days I missed a whole lot of meetings (in fact, this was when I started from home around 8:30 AM). Once it takes 35 mins to drive 2 km, you start exploring new alternatives.

The next option is to take an Uber/Ola to the office. While this option exists in theory, practically this never worked. You can wait for a cab for hours and have multiple drivers cancel on you. Once I remember waiting for 1 hour for a cab and finally giving up. This probably is the worst option of all.

I never even assumed the option of walking existed. The walk from the office to him is about 9 km and takes more than an hour. But once I did this for the first time, it was easy to continue doing this every day.

In fact, walking was so much fun that I even did this twice (back and forth) once. The best day and I was even was able to finish an entire book while walking. The only challenge is the exposure to so much dust after walking. I think it does make me fall sick once in a while.

The last option is to take a bus. This is for sure a fun option. Walking to the bus stop involves a good 30min walk (a little of a risk crossing the road). There is enough peaceful thinking time on the bus (with or without a seat). It is for sure a cheaper option, but whenever the ticket is 15 or 25, I have to give a coin, which is not so great.

So, everyday morning, my checklist happens to go like this

1. Do I have 2 hours before the first meeting and is not too hot? If yes, then walk
2. Do I have 1.5 hours before the first meeting? Doesn’t matter if the weather is bad. Bus works.
3. If neither of them works, suffer the traffic and drive to the office.

This is a decision I take every day I go to the office and makes life interesting every morning.

These two books got into my reading list mostly because of Vivek. The number of times he mentioned instances from this book, I had to know what the Starbucks story is all about. And I’m glad I did read these two. I expected a simple and smooth story about Starbucks. Didn’t expect so many ups and downs within the company. This post is my key takeaways from the two books. I actually believe these two books should be read together since they both share the entire story of Starbucks from start to end.

Key takeaways from the first book

1. It was crazy to imagine Starbucks CEO/Chairman as one of the early employees of Starbucks (and not the original founders). Shocked to see when the founders decided to sell Starbucks to one of the early employees. Makes me believe that passion for the idea is a lot more important than being the co-founder of a company. Can even attest to this fact, having seen people more passionate than myself at HackerRank, a set of people I can any day call as founders.
2. Surprised by the fact that someone can be so passionate about coffee.
3. It is strange to imagine Starbucks even called something else called “Il Giornale”. When you know about the early name & story of the companies (say Nike or even HackerRank), it has a different story to it.
4. It is very hard even to imagine the world before Starbucks. Some of the coffee they had to “invent” is my usual in the current world. It is like explaining the world without the Internet or Google to someone.

Key takeaways from the second book.

1. Again, crazy to imagine Schultz would imagine becoming the CEO after being the Chairman for a while. Again, shutting down the whole company for two days to make sure everyone can train to become a better baristas.
2. Looks like no matter how big a company is, constant innovation is a must. Innovation seems to be oxygen for every company out there. And never imagined them to innovate in all aspects (coffee beans, vending machines) and everything else that goes along with that.
3. It is amazing to see how much Schultz focuses on the customer experience. He was particular about the height of the coffee vending machine so that the barista can have eye contact/good conversation with the customers while making the coffee.

The first book seems to be a happy story and the second one goes into detail about all the struggles when a company is re-inventing itself. Strongly recommend reading both if you are building a company or a team.

Probably the right title for this blog post should be “Regionalist”, but somehow the word ‘state-ist’ was the word I created and have been using for a long time.

When I was assigned my room in the college hostel (back in 2004), each room was supposed to have 5 students.

The 5 students in my room were assigned like this.

1. Me – From TamilNadu
2. Vibhu – From Delhi
3. Yatish – From Assam
4. Babu – From Orissa
5. Hemant – From Mumbai

I was literally shocked when I saw this combination. And it was clear from others too that they didn’t prefer this either. But college never gives you the option to change your room/roommates. Just a few rooms away, 5 students from my school were in the same room. Yeah, ignore the same state and the same city. Those five were all from the same school.

I accepted this “fate” but never realized this was such an important moment in both my professional and personal life.

The first outcome because of this was the official language of the room was English. If you wanted to share something with everyone in the room, we used only English. It also helped me understand people from different backgrounds better. There was an unknown strangeness towards people from the other states. Living with people from different parts of the country completely removed this bias. This was a masterclass to understand different cultures, festivals, food, and people.

When I co-founded HackerRank with Vivek, I re-used some of the first year’s learnings. First, English was/is the official language in HackerRank. Even if everyone in the team knows a regional language, I ensure the language of choice is always English. I get surprised/shocked when I hear from other tech startups how all their technical discussions happen in Hindi/Tamil. It works well at the start but doesn’t scale well. Building an inclusive culture can’t be an afterthought. It is something that needs to be nailed in from the first day.

Second, it makes me act fair to everyone around me. Since I speak in English, even with the folks who know Tamil, it acts as a good balancing function. No matter how I try, I’m going to be a little partial to folks with whom I can speak in my mother tongue. It is natural and brings in a homely feeling. While I would love to crack more Tamil jokes and discuss the local stories with some of my colleagues, I specifically skip this to keep things balanced. Of course, 1:1 Vivek is the only exception to this rule.

I find it funny when people try to tag people based on the state/city they are from. Especially given I’m from south India, others assume I have issues with folks from the north. When I tell them my wife is from Rajasthan and some of my closest people inside and outside HackerRank are from north India, they find it hard to understand. This small butterfly effect in 2004 made me a better person and made it easier to build an inclusive culture at HackerRank.

Recently, we (me and Vasudha) went for a short trek (around 75 km from Bangalore). We found an agriculture shop selling fertilizers and pesticides on the way back. We have a small garden at our place, and Vasudha has written a great post about it here at https://ideaweb.me/blog/from-cacti-killer-to-gardener/.

We’ve been using natural organic pesticides so far, and this is the first time we are even trying something more powerful and dangerous.

Moving from organic pesticides to a chemical one felt like we’ve leveled up multiple times. In fact, while I spray the organic pesticide vs. chemical, this is exactly how I feel 🙂

This is the actual insecticide we bought.

I don’t know why, but I started reading about Cypermethrin first. It sounded cool, and a simple Google search landed on the Wikipedia page. The first line from the page was this

Cypermethrin (CP) is a synthetic pyrethroid used as an insecticide in large-scale commercial agricultural applications as well as in consumer products for domestic purposes.

Wikipedia

I understood most of it except for a single word – pyrethroid. What is that? Google to the rescue again

A pyrethroid is an organic compound similar to the natural pyrethrins, which are produced by the flowers of pyrethrums (Chrysanthemum cinerariaefolium and C. coccineum). Pyrethroids are used as commercial and household insecticides.

Wikipedia

Oh damn, now there are multiple new words. Pyrethrins, pyrethrums. More and more Googling follows

The pyrethrins are a class of organic compounds normally derived from Chrysanthemum cinerariifolium that have potent insecticidal activity by targeting the nervous systems of insects.

Wikipedia

Pyrethrum was a genus of several Old World plants now classified as Chrysanthemum or Tanacetum which are cultivated as ornamentals for their showy flower heads.

Wikipedia

I’m totally baffled by the matrix I’ve gotten into. The beautiful-looking Chrysanthemum flower, which amazes me a lot, is a class of Pyrethrum. The flower seed cases contain pyrethrins, which can kill insects by targeting their nervous system. And this is what I bought. Talk about a beautiful-looking assassin!

Eventually, my browsing history ended up like this after reading about cypermethrin and how it affects the nervous systems of insects. It felt like I attend 4-5 hours of chemistry class.

Reading these gave a lot of interesting facts about these chemicals and how they operate. When I started this, I wasn’t even sure how it was going to be useful. Then I learned a bunch of things and how they can be helpful.

1. Because pyrethrum contains pyrethrins, they are used as companion plants to repel pest insects from nearby crops. No need to buy the chemical if you can plant some Chrysanthemum in between your plants.
2. Cypermethrin is very toxic to cats which cannot tolerate the therapeutic doses for dogs.
3. Fish are particularly susceptible to cypermethrin, but application around residential sites poses little risk to aquatic life when used as directed.

I was doing all of this search at 2 AM at night and couldn’t sleep anymore. Realizing I was dealing with a weapon of mass destruction created from a beautiful flower, and I wanted to know if it affected the earthworms in any way. From what I’ve read so far, this affects all insects, and the way it affects the nervous system should impact earthworms too. If it does, that was a deal breaker. Back to Google again.

That leads to a research paper published by https://www.pulsus.com/scholarly-articles/combined-toxicity-of-cypermethrin-a-pyerthroid-insecticide-and-metal-to-earthworms-emeisenia-fetidaem-4588.html on how the chemical affects the earthworm.

It was shown that the all-around toxicity from cypermethrin was weak in adult earthworms. Compared with adult earthworms, the toxicity of juvenile earthworms from cypermethrin, especially chronic toxicity, increased significantly. The growth and reproduction of earthworms appeared to be more severely affected by cypermethrin at the juvenile stage than at the adult stage.

Cool, so it doesn’t kill it, but it does affect the growth and reproduction of earthworms. To test this, I did spray a small amount of the pesticide on an earthworm (that appeared small), and it did stop moving (aka died). Of course, my test is not a scientific fact but something to worry about.

Weeks later, I was wondering why I was so curious about this in the first place, and that is what I want to talk about – Curiosity. The passion to learn new things for absolutely no reason at all. Just for the fun of learning.

One of the best podcasts I’ve come across recently is this one https://open.spotify.com/episode/54BjQkzKzSElYvhNI2pOUs?si=a00dc50cb0404808. I was listening to this mostly because I’ve worked with both the guest and the host in different teams of HackerRank. But this line “Skills can be learned. But passion, kindness, and excitement. These are the top 3 qualities I look for”. Probably the core foundation for passion and excitement is curiosity.

Can one develop the skill of curiosity? Yes, of course.

1. It is not by chance that people use the term “childlike curiosity.” I find improving curiosity easier by working with people much younger (aka kids) and interns.
2. Listen for the trigger word – “This how it is being done” or “That’s how it works.” The minute someone says that, ask – “Why.”

Did it help at all? Yes, it did.

First, I realized I had to keep my fish and the insecticide far apart.

Secondly, when I had to travel for a week, I had Vaasavi water the plants twice. Since she came there with her cat, I knew I shouldn’t ask her to spray the insecticide. So, overall the 4-5 hours was a good investment.

Do you want a simple test to check if you are naturally curious about things? Here is a simple test.

You might have heard about this term chatGPT so so many times in the last few weeks/months. If you have ever wondered what the GPT stands for and what it means, tried to google search, and understand the full form for GPT, you are curious about stuff around you!

An amazing book. The story is exciting, a lot of good life lessons to learn and of course, listening to the book in Trevor’s voice. If there is one book which should be read via audible instead of physical book, this must be it.

Top things I recollect from this book.

1. The result of the freedom from the external force always results in the internal conflicts. The conflict between Tsonga and Zulu is very similar to the freedom of India and how that split India and Pakistan. The whole concept of conquering another country using the concept of “divide and rule” breaks apart when the country gets freedom at the end.
2. Trevor’s mom is the main superhero in the whole story. There are a lot of places where she acts as a true rebel and that’s so inspiring. From being getting a secretary job, not being confined to rules, deciding to have a kid – she is THE person in this story. What I love about her attitude is to question the rules. If the rule is stupid and doesn’t make any sense, then mock or challenge the rule.
3. One great learning from the book is to forget the pain. “Don’t let the memory of pain stop you from trying something new.”. If I could take one line from this book forever with me, this could be it.
4. Another intersting learning – “You down own the thing in your life.” Learning this early in life makes life zen. It is surprising how Trevor had no issues with how the dogs lived their life before they got to know about the other boy.
5. Last one is the concept of crime. How crime is decided by what everyone around you is doing or not doing. For example, printing movie songs and distributing them in a CD is not considered a crime (even a minor one). Makes me wonder what are all the things we are doing today can be considered as crime 10 or 20 or 50 years later. Probably killing animals to eat them? Or all traffic violations?