I follow Derek Sivers. I got introduced to him via his blog (I do not remember how I got his blog reference though - maybe via DHH blogs). I like many of his blog posts. They are short posts, simple in the content and profound in its teaching. This book follows a similar pattern. This is targeted at entrepreneurs. It has around 40 chapters based on his experience of running the CD Baby company.

The thing that stood out was that many of the decisions taken by him are grounded in very simple desires. Based on these simple desires, the company was run in a unique way, much different from what I expected from a technology startup. There is this belief that as a startup, you need to think big and constantly expand. As you expand, your needs change, you need to evolve, and to a certain extent even the customers change. But for CD Baby, that wasn’t the case. The company’s growth was very natural: based on the problem faced, a solution was invented, and that itself became a monetization channel for the company (example - building the servers and renting them out). He actively wanted a small company so that he could cater to those customers who could not be served by distributors. He loved writing code even when he was running a company of 75-80 employees.

With all these crazy startup stories in the current age about various technologies and the need to grow fast or think big, Anything You Want is an antidote for that. It helps bring our minds back to thinking of customers first, solving the simplest problems customers are in pain over, and remembering that, at the end of the day, it is your world you are creating and hence you should enjoy what you like. I also feel the book itself projects that journey as too simplistic, but I believe there were a lot of challenges (example — coming to the selling decision, hiring and letting go, the tussle with Apple).

I strongly recommend reading this book for anyone who is an entrepreneur or wants to become one.

My personal rating of this book is:

• Category: Entrepreneurship
• Rating: 5/5

I have used an LLM to review the write-up, fix grammatical errors, and iron out any awkward sentences.

• Title
  • Title Of the Book
• Authors
  • Authors of the Book
• Bought - YES/NO
  • Whether I own the copy of the book or not
• Read Status - To Read/Currently Reading/Read
  • current state of the book reading
• Country - India/Other
  • Is the book primarily published in India (to make a decision of where to buy it)
• Reference Count
  • how many references I have got for the book. More references means more preferred pick for reading next.
• Reference Source - Office/Blog/X/Podcast/Search/Personal Recommendation/Random
  • From where the recommendations are coming in. This will help to decide which book to pick for reading
• Comments
  • Usually gives more details of the reference source. Actual source like x link or podcast reference. Again helps with book reading decision.
• Language
  • Language of the book. I primarily read either English or Kannada. Sometimes I get recommendations of other languages usually Indian language books.
• For Kids - YES/NO
  • Is this a book for kids that I want to buy and give it.
• Category
  • This puts the book in a certain topic. There is no list of known topics rather which ever I feel this book resonated with.
• Category Rating
  • Within that category how does this book stand in my view. The rating system I have explained below.
• Links In My blog
  • This links my blog posts that is referring this book.

For external reference, I also mark the currently reading book in GoodReads as well as in my personal blog.

Rating System

This is a rating system I use to put the book in particular sorting that is applicable to me.

• 5 - Must Read - want to read multiple Times/lots of learning/enjoyed
• 4 - Good Read - Lots of learning/single time read/enjoyed
• 3 - Okay Read - some learning/single time read/passed through
• 2 - Not Bad Read - single time read/no learning/passed through
• 1 - Bad Read - could not complete /wrong teachings/negative/not applicable to me

Future

There is a future plan to display this whole tracking sheet in my personal blog. I have just started this system and I will evolve it as I use it more.

I picked up this book at the library. We usually go there to pick up suspense fiction for my wife and some toddler books for my daughter. As I was browsing the children’s aisle, I spotted this one shelved under children’s books. Since it was related to India and Indian mythology, it piqued my interest.

Classic Tales from India collects several stories drawn from various Puranas. They’re narrated for a child audience — specifically, in a style suited to a child growing up in the United States today. Each story is kept short but still manages to convey a fair bit of detail. The real highlight of the book is the artwork: traditional Indian art styles that make the pages stand out and add a lot of visual appeal.

What I didn’t like: the stories drawn from the Ramayana and Mahabharata deviate in places from Valmiki’s Ramayana and Vyasa’s Mahabharata. This is most likely because these versions were sourced from later Puranas rather than the original epics, but the book never says so. It would have helped a lot if each story credited its specific source.

Overall, it’s a good book to give younger children a brief introduction to Indian Puranic stories.

I have used LLM for reviewing the write up, fix grammatical errors and iron out any awkward sentences.

My operating system is Ubuntu. So, these instructions are specific for that operating system.

Installation

Install Obsidian by downloading the deb file from https://obsidian.md/download. Sometimes, the Obsidian Web Clipper does not work with the one installed from the snap/Ubuntu Software. Hence, install it using the deb file directly.

Settings

These are the settings. I’m only listing settings that differ from the defaults.

• General
  • Log in to get the Catalyst license
  • Enable Command Line Interface
  • Enable Receive Early Access Versions
• Editor
  • Spell Check Languages
    • English (United States)
    • English (United Kingdom)
    • Hindi
• Files and Links
  • Default location for new attachments: In the folder specified below
    • Attachments
  • Automatically update internal links: True
• Appearance
  • Theme: I change it after every few days. I can start with Minimal
  • Disable Inline Title
• Core Plugins
  • Following core plugins are switched off
    • Audio Recorder
    • Publish
    • Random Note
    • Slash Commands
    • Slides
    • Sync
    • Unique Note Creator
    • Workspaces
• Community Plugins
  • Turn off Restricted Mode
  • Enable Automatically Check for Plugin Updates
  • I use following community plugins
    • Advanced Tables
    • Automatic List Management
    • Calendar
    • Charts
    • Dataview
    • Excalidraw
    • Git
    • Homepage
    • Reminder
    • Tag Wrangler
    • Tasks
    • Templater

Core Plugin Settings

Daily Notes

• New file location: DailyNotes
• Template file location: Templates/Template_DailyNotes
• Date format: YYYY-MM-DD

Templates

• Template folder location: Templates

Community Plugin Settings

Apart from the ones listed below, remaining plugins (Advanced Tables, Charts, Dataview, Excalidraw, Reminder, Tag Wrangler, Tasks) work well with their default settings.

Automatic List Management

• Turn off: Auto Sort On Changes

Calendar

• Words Per Dot: 2048

Git

• Auto commit-and-sync interval: 60
• Auto commit-and-sync after stopping file edits: On
• Pull on startup: On

Homepage

• Turn on Pin
• Homepage view: Reading View

Templater

• Template folder location: Templates

Related Posts

• My Personal Laptop Setup
• My Obsidian Vault
• My Development Configuration

How to Love In Sanskrit was a surprise read. I did not expect much from the book when I picked it up. The title was also very intriguing in that I could not categorize it into a particular type of book. It lists Sanskrit poem translations related to love. The twist is, these translations are not word-to-word translations. Rather, these are translated to convey the same meaning but in a modern context. That brings out the liveliness of the poems and makes it easy to connect with them. Here are a few examples:

She calls me hard-hearted. She should know. 
The moment I set eyes on her, she stole my heart and took it home with her.

I was you
and you were me.

What transpired
that now we see

you as you
and me as me?

She has no need for words:
her eyes
do a fine job already

I am he, you are she
You are verse, I am song.
I am heaven, you are earth
Let us live as one
and bring children into this world.

It made me realize the feelings about love, about separation, about flirting are the same across ages. The language of expression changes but that feeling remains the same then, now, and in the future.

An interesting feature of this collection is that each poem is accompanied by its source. A few of the texts, such as the Ramayana, Mahabharata, and Atharvaveda, were familiar to me, but most were not. Reading these poems also created a desire to read those Sanskrit, Prakrit, and other classical language books. I would also like to read those books not as word-to-word translations, but as modern contextual ones, which are far more enjoyable and relatable. Yes, word-to-word translation is interesting for understanding the language, but I want to feel those thoughts in these books. The brief descriptions of the source texts were another highlight. One example that stayed with me was Bawd’s Counsel by Damodaragupta, dated to around 800 CE, which is described as a work centered on ordinary people in an urban city. I had often assumed older texts would focus mostly on gods, kings, and queens, so this was a surprise. That made me curious to read more of such works and see what has changed, and what has remained familiar, across the centuries.

I strongly recommend this book and it is also a very nice book to give as a gift to your spouse, a newlywed, or anyone in love.

• I have used LLM agents to review the draft. I have also taken help with rewording and rephrasing the sentences.

I wanted to understand how this would work out in a Java program. I wanted to compare it with a Rust program execution where there is no garbage collector.

For this experiment, I used the following Java version with the default G1 garbage collector.

openjdk version "26" 2026-03-17
OpenJDK Runtime Environment (build 26+35-2893)
OpenJDK 64-Bit Server VM (build 26+35-2893, mixed mode, sharing)

Here is the Java program

import java.time.Duration;
import java.time.Instant;

class Node {

    private int value;
    private Node next;

    public Node() {
        this.next = null;
        this.value = 0;
    }

    public void addNext(Node node) {
        this.next = node;
    }

    public Node getNext() {
        return this.next;
    }

    public void setValue(int value) {
        this.value = value;
    }

    public int getValue() {
        return value;
    }
}



class StopTheWorld {

    public static Node createLinkedList(int limit) {
        Node headNode = new Node();
        headNode.setValue(0);
        Node current = headNode;

        for (int i = 0; i < limit; i++) {
            Node newNode = new Node();
            newNode.setValue(i);
            current.addNext(newNode);
            current = newNode;
        }

        return headNode;
    }

    public static void main(String[] args) {
        Instant start = Instant.now();
        Instant initStart = Instant.now();
        Node linkedList = createLinkedList(50_000_000);
        long initTime = Duration.between(initStart, Instant.now()).toNanos() / 1000;
        Instant oldStart = Instant.now();
        long delay = 0;
        long worstCase = 0;
        long createTime = 0;
        long worstCreateTime = 0;
        Instant loopStart = Instant.now();
        for (int i = 0; i < 1000000; i++) {
            Instant min_start = Instant.now();
            long value = Duration.between(oldStart, min_start).toNanos() / 1000;
            if (value > worstCase) {
                worstCase = value;
            }
            delay += value;
            Instant createStart = Instant.now();
            createLinkedList(1000);
            long thisCreateTime = Duration.between(createStart, Instant.now()).toNanos() / 1000;
            if (thisCreateTime > worstCreateTime) {
                worstCreateTime = thisCreateTime;
            }
            createTime += thisCreateTime;
            oldStart = min_start;
        }
        long loopTime = Duration.between(loopStart, Instant.now()).toNanos() / 1000;
        Instant end = Instant.now();
        Duration elapsed = Duration.between(start, end);
        System.out.println("Elapsed: " + elapsed.toMillis() + " ms");
        System.out.println("Initial 50M list create time: " + initTime + " µs");
        System.out.println("Total For Loop time (1M x 1K): " + loopTime + " µs");
        System.out.println("Total Delays between iteration: " + delay + " µs");
        System.out.println("Worst Gap is: " + worstCase + " µs");
        System.out.println("Total Create time: " + createTime + " µs");
        System.out.println("Worst Create time: " + worstCreateTime + " µs");
    }
}

Here is the output of the Java program.

➜  simple-programs java StopTheWorld
Elapsed: 7670 ms
Initial 50M list create time: 2622048 µs
Total For Loop time (1M x 1K): 5048015 µs
Total Delays between iteration: 4711094 µs
Worst Gap is: 565162 µs
Total Create time: 4568381 µs
Worst Create time: 565142 µs

For Rust, I used rustc 1.93.0 (254b59607 2026-01-19). Here is the equivalent Rust program.

use std::time::Instant;

struct Node {
    value: i32,
    next: Option<Box<Node>>,
}

impl Node {
    fn new(value: i32) -> Self {
        Node { value, next: None }
    }
}

impl Drop for Node {
    fn drop(&mut self) {
        let mut current = self.next.take();
        while let Some(mut node) = current {
            current = node.next.take();
        }
    }
}

fn create_linked_list(limit: i32) -> Box<Node> {
    let mut head = Box::new(Node::new(0));
    let mut current: *mut Node = &mut *head;

    for i in 0..limit {
        let new_node = Box::new(Node::new(i));
        unsafe {
            (*current).next = Some(new_node);
            current = &mut **(*current).next.as_mut().unwrap();
        }
    }

    head
}

fn main() {
    let start = Instant::now();

    let init_start = Instant::now();
    let _linked_list = create_linked_list(50_000_000);
    let init_time = init_start.elapsed().as_micros();

    let mut old_start = Instant::now();
    let mut delay: u128 = 0;
    let mut worst_case: u128 = 0;
    let mut create_time: u128 = 0;
    let mut worst_create_time: u128 = 0;

    let loop_start = Instant::now();
    for _ in 0..1_000_000 {
        let min_start = Instant::now();
        let value = min_start.duration_since(old_start).as_micros();
        if value > worst_case {
            worst_case = value;
        }
        delay += value;
        let create_start = Instant::now();
        let _list = create_linked_list(1000);
        let this_create_time = create_start.elapsed().as_micros();
        if this_create_time > worst_create_time {
            worst_create_time = this_create_time;
        }
        create_time += this_create_time;
        old_start = min_start;
    }
    let loop_time = loop_start.elapsed().as_micros();

    let elapsed = start.elapsed();
    println!("Elapsed: {} ms", elapsed.as_millis());
    println!("Initial 50M list create time: {} µs", init_time);
    println!("Total For Loop time (1M x 1K): {} µs", loop_time);
    println!("Total Delays between iteration: {} µs", delay);
    println!("Worst Gap is: {} µs", worst_case);
    println!("Total Create time: {} µs", create_time);
    println!("Worst Create time: {} µs", worst_create_time);
}

Here is the output of the Rust program.

➜  simple-programs ./stop_the_world
Elapsed: 26915 ms
Initial 50M list create time: 1737040 µs
Total For Loop time (1M x 1K): 25178866 µs
Total Delays between iteration: 24577577 µs
Worst Gap is: 145 µs
Total Create time: 10964945 µs
Worst Create time: 90 µs

The code is trying to stress test the memory allocation. We are using a linked list for this experiment. We create one big 50 million nodes linked list and then 1 million small 1000 nodes linked lists. Here is the tabular output for comparison.

On a high level, these results looked weird. My mental model was Rust is more of a systems programming language and hence should have been faster than Java across every metric. Here, we see that the Java program completed about 3.5x faster than Rust. Let’s look into the following metrics and try to understand why that is happening:

• Total time for creating 1M 1k node linked list creation time (including delays)
  • This is the total loop time (1M x 1k). Here, Java is almost 5x faster than Rust.
  • The key here is, in every iteration, a 1k node linked list is formed and by the end of the iteration, that linked list has gone out of scope.
  • In the Rust world, the moment it goes out of scope, Rust deletes it. So, for Rust, every iteration = allocation + any work after allocation + delete.
  • In the Java world, there is only allocation and no deletion. Deletion is taken care by the GC at a later time. So, for Java, every iteration = allocation + any work after allocation. Hence, Java is much faster here.
• Total delays between single 1k node linked list creations
  • This is the total iteration delays. Here too, Java is 5x faster than Rust.
  • This makes sense given how every iteration differs in Rust world vs Java world. In Rust, the extra time goes toward deletion. 1 million deletions add up in Rust.
• Total time spent in just creating 1M of 1k node linked list (without gaps/delays)
  • This is the total time it spent on just the creation of 1k node linked lists. Here, Java is 2.4x faster than Rust. This indicates that even pure allocation (without deallocation) is costlier in Rust than in Java. The reason is that Java’s generational GC uses bump-pointer allocation for short-lived objects — allocating a new object is nearly free, just incrementing a pointer into the young generation heap. Rust, by contrast, performs a heap allocation through its allocator for every Box::new, which is typically slower than HotSpot’s thread-local bump-pointer fast path for young objects. That per-node allocator overhead accumulates across 1000 nodes per list × 1 million iterations.
• Max time spent in creating one single 1k node linked list (including gap)
  • This is the most interesting metric. Here, Rust is almost 6280x better than Java.
  • This is the STOP THE WORLD PAUSE OF JAVA GARBAGE COLLECTOR. Before allocating the node, Java needed to reclaim some space. Hence, it stopped the application and asked GC to reclaim some space. So, for one of the creation steps, it took significantly longer.
• Worst Gap between the individual iteration
  • Here also, Rust is almost 3900x better than Java. This is a continuation of the previous metric. Because GC worked for one of the creation attempts, that iteration time ballooned for Java.
    • For Rust, every iteration is the same = allocation + any work after allocation + delete.
    • For Java, there is a magic step = (Garbage Collection) + allocation + any work after allocation
• Initial 50M node linked list creation time
  • It seems Rust is almost 1.5x faster in creating a huge single-shot list. I am not sure why that behavior is seen. One important timing note: _linked_list goes out of scope at the very end of main, after start.elapsed() is already captured. So the program’s reported elapsed time does not include the cost of dropping the 50M node list — that drop happens outside the measured window.

Validating with GC Logs

We can enable GC logs to understand how GC is behaving in Java. Here are the GC logs — let’s try to understand whether the numbers match.

➜  simple-programs time java -Xlog:gc StopTheWorld
[0.003s][info][gc] Using G1
[0.040s][info][gc] GC(0) Pause Young (Normal) (G1 Evacuation Pause) 5M->5M(16M) 10.465ms
[0.056s][info][gc] GC(1) Pause Young (Normal) (G1 Evacuation Pause) 9M->9M(20M) 14.943ms
[0.075s][info][gc] GC(2) Pause Young (Normal) (G1 Evacuation Pause) 13M->12M(72M) 17.457ms
[0.130s][info][gc] GC(3) Pause Young (Normal) (G1 Evacuation Pause) 28M->28M(72M) 42.890ms
[0.157s][info][gc] GC(4) Pause Young (Normal) (G1 Evacuation Pause) 40M->43M(72M) 25.836ms
[0.178s][info][gc] GC(5) Pause Young (Concurrent Start) (G1 Evacuation Pause) 51M->51M(72M) 19.032ms
[0.178s][info][gc] GC(6) Concurrent Mark Cycle
[0.203s][info][gc] GC(7) Pause Young (Normal) (G1 Evacuation Pause) 59M->60M(228M) 22.891ms
[0.330s][info][gc] GC(8) Pause Young (Normal) (G1 Evacuation Pause) 108M->109M(228M) 97.542ms
[0.415s][info][gc] GC(9) Pause Young (Normal) (G1 Evacuation Pause) 145M->147M(228M) 80.128ms
[0.465s][info][gc] GC(10) Pause Young (Normal) (G1 Evacuation Pause) 167M->169M(228M) 46.356ms
[0.499s][info][gc] GC(11) Pause Young (Normal) (G1 Evacuation Pause) 185M->187M(684M) 31.950ms
[0.526s][info][gc] GC(6) Pause Remark 233M->233M(684M) 0.997ms
[0.574s][info][gc] GC(6) Pause Cleanup 315M->315M(684M) 0.039ms
[0.576s][info][gc] GC(6) Concurrent Mark Cycle 398.156ms
[0.917s][info][gc] GC(12) Pause Young (Prepare Mixed) (G1 Evacuation Pause) 339M->343M(684M) 330.662ms
[1.155s][info][gc] GC(13) Pause Young (Mixed) (G1 Evacuation Pause) 447M->451M(684M) 226.702ms
[1.321s][info][gc] GC(14) Pause Young (Concurrent Start) (G1 Evacuation Pause) 519M->521M(684M) 158.399ms
[1.321s][info][gc] GC(15) Concurrent Mark Cycle
[1.433s][info][gc] GC(16) Pause Young (Normal) (G1 Evacuation Pause) 569M->573M(2052M) 106.487ms
[2.493s][info][gc] GC(17) Pause Young (Normal) (G1 Evacuation Pause) 977M->979M(2052M) 845.976ms
[2.963s][info][gc] GC(18) Pause Young (Normal) (G1 Evacuation Pause) 1311M->1183M(2052M) 418.603ms
[3.101s][info][gc] GC(19) Pause Young (Normal) (G1 Evacuation Pause) 1459M->1194M(2052M) 96.162ms
[3.152s][info][gc] GC(20) Pause Young (Normal) (G1 Evacuation Pause) 1490M->1193M(4428M) 5.607ms
[3.431s][info][gc] GC(21) Pause Young (Normal) (G1 Evacuation Pause) 1713M->1193M(4428M) 1.118ms
[3.476s][info][gc] GC(15) Pause Remark 1523M->1523M(4428M) 0.737ms
[3.526s][info][gc] GC(22) Pause Young (Normal) (G1 Evacuation Pause) 1745M->1193M(4428M) 0.848ms
[3.685s][info][gc] GC(15) Pause Cleanup 1883M->1883M(4428M) 0.070ms
[3.696s][info][gc] GC(15) Concurrent Mark Cycle 2375.184ms
[4.578s][info][gc] GC(23) Pause Young (Prepare Mixed) (G1 Evacuation Pause) 3785M->1193M(4428M) 1.470ms
[4.909s][info][gc] GC(24) Pause Young (Mixed) (G1 Evacuation Pause) 3845M->1189M(4428M) 6.353ms
[5.236s][info][gc] GC(25) Pause Young (Normal) (G1 Evacuation Pause) 3841M->1189M(4428M) 1.434ms
[5.558s][info][gc] GC(26) Pause Young (Normal) (G1 Evacuation Pause) 3841M->1189M(4428M) 1.472ms
[5.882s][info][gc] GC(27) Pause Young (Normal) (G1 Evacuation Pause) 3841M->1189M(4428M) 1.258ms
[6.214s][info][gc] GC(28) Pause Young (Normal) (G1 Evacuation Pause) 3841M->1189M(4428M) 1.623ms
[6.540s][info][gc] GC(29) Pause Young (Normal) (G1 Evacuation Pause) 3841M->1189M(4428M) 1.357ms
[6.879s][info][gc] GC(30) Pause Young (Normal) (G1 Evacuation Pause) 3841M->1189M(4332M) 1.320ms
Elapsed: 6863 ms
Initial 50M list create time: 2497475 µs
Total For Loop time (1M x 1K): 4364742 µs
Total Delays between iteration: 3733728 µs
Worst Gap is: 420189 µs
Total Create time: 3678367 µs
Worst Create time: 420117 µs
java -Xlog:gc StopTheWorld  11.25s user 1.61s system 180% cpu 7.124 total

Yes, from the logs we can see that GC pauses are happening. We can map the worst gap we saw (~420ms) to GC(18) which took 418ms. Using the default heap means the JVM starts with 16M and slowly expands, leading to more pauses early on. We can use a fixed heap with -Xms4G -Xmx4G which reduces pause frequency by avoiding dynamic heap expansion. The biggest memory reclaim happens around GC(23) and GC(24), after which the GC stabilizes with quick cycles. By the time GC(23) and GC(24) happen, the long-lived 50M node list has likely already been promoted to the old generation. Those later mixed collections are reclaiming old-generation regions after concurrent marking. The quick cycles after that occur because most of the remaining work is collecting the short-lived 1k node lists.

Conclusion

So, Java’s throughput is good, but Rust is very deterministic. Here is what two LLMs had to say about these results:

- Claude:
  
This is a classic **throughput vs. latency tradeoff**:
- Java's GC optimizes for throughput (amortizes collection cost across many allocations)
- Rust's ownership model gives deterministic, near-zero pause times at the cost of slower aggregate destruction of long-lived heap structures

For real-time systems, games, trading, or audio — Rust's 145 µs worst case matters enormously. For batch jobs or web services that care about average throughput, Java wins here.

- Codex

Bottom line: this output says Java has much better allocation throughput for short-lived objects, while Rust gives much tighter pause-time behavior. It does not prove “Java is faster than Rust” generally; it proves HotSpot’s generational allocator is very good for this exact garbage-heavy workload.

Yes, this is a small program and extrapolating these results broadly would be unwise. But it does give some good insights. If we are looking for very deterministic latency in our applications or services, then Rust is a good fit. In this allocation-heavy workload, Java showed better overall throughput. So, we need not feel guilty about using Java as long as occasional latency spikes are within acceptable bounds.

• I have used LLM agents to review the draft. I have also taken help with rewording and rephrasing the sentences. I have also used it for doing research.

ಇದು ನಾನು ಓದುತ್ತಿರುವ ಟಿ. ಕೆ. ರಾಮಾ ರಾವು ಅವರ ಮೊದಲ ಪುಸ್ತಕ. ಇದರಲ್ಲಿ ಮೂರು ಸಣ್ಣ ಪತ್ತೆದಾರಿ ಕಥೆಗಳಿವೆ. ಪ್ರತಿಯೊಂದೂ ವಿಭಿನ್ನವಾಗಿದೆ. ಕಥೆಗಳು ಪ್ರಾರಂಭದಲ್ಲಿ ನಿಧಾನವಾಗಿ ಸಾಗಿದರೂ ತುಂಬ ಬೇಗನೆ ರೋಚಕವಾಗುತ್ತ ಹೋಗುತ್ತವೆ. ಎಂಬತ್ತು-ತೊಂಬತ್ತರ ದಶಕದಲ್ಲಿ ನಡೆಯುವಂತ ಸನ್ನಿವೇಶ ಇದೆ. ಕಥೆಗಳಲ್ಲಿನ ಹಲವು ಪಾತ್ರಗಳಲ್ಲಿ ಯಾರು ಕೊಲೆಗಾರರೆಂದು ಊಹಿಸಲು ನನ್ನಿಂದ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ನನಗೆ ಅನಿಸಿದ್ದು, ಈ ಕಥೆಗಳನ್ನು ಇನ್ನು ದೊಡ್ಡದಾಗಿ ಮಾಡಿ ಇನ್ನೂ ಹಲವಾರು ವಿಷಯಗಳ ವಿವರಣೆಗಳನ್ನು ನೀಡಬಹುದಿತ್ತು. ಪ್ರತಿ ಕಥೆಯ ಮುಖ್ಯ ಪಾತ್ರವು ಸಾಮಾನ್ಯ ವ್ಯಕ್ತಿಯಂತಿದೆ. ಒಂದು ಆಸೆ, ರಾಮಾ ರಾವು ಅವರ ಈ ಪತ್ತೆದಾರಿ ಕಥೆಗಳನ್ನು ಮತ್ತು ಗಣೇಶಯ್ಯರವರ ಪತ್ತೆದಾರಿ ಕಥೆಗಳನ್ನು ಕನ್ನಡ web series/youtube series ಆಗಿ ಮಾಡಿದರೆ ಎಷ್ಟು ಚೆನ್ನಾಗಿರುತ್ತಿತ್ತು. ಟಿ.ಕೆ. ರಾಮಾ ರಾವುರವರ ಮತ್ತಷ್ಟು ಕಥೆಗಳನ್ನು ಓದಬೇಕು.

After reading Made in Japan, I became deeply curious about the country and its culture. I wanted to see it for myself and experience it firsthand, and my wife planned the trip.

The trip was an eye-opener in more ways than I expected.

Trains and Trains Everywhere

My main experience with a vast and busy transport station is Bengaluru’s Majestic Bus Stand (my dad told me that Mumbai has even bigger and busier stations). It is an integrated hub where the local city bus system, inter-city and inter-state bus system, auto stand, and train station are all very nearby (recently, even a Metro station has been added to it). If you go to Majestic during peak hours, it is very busy and chaotic, with a large number of buses and people.

Japan operates on an even bigger scale, with seamless integration between metro trains, bullet trains, and buses. The stations are crowded and busy, yet they feel remarkably orderly. The trains arrive almost to the second; every two to three minutes, trains come and go. Huge numbers of people move in and out of the trains, while the stations themselves are filled with shops and activity. People stand in line to get on trains and enter elevators, and train station workers are very cooperative and help people reach their destinations. They are professional and, to borrow a Sanskrit expression, स्मितपूर्वाभिभाषिणः, smiling as they speak. That brings calmness to confused or distressed passengers and helps disabled commuters. There were many facilities to make things easier for passengers, like coin lockers to store luggage, regular announcements of trains and delays, color-coded directions to help with navigation within the station, and a large number of escalators and elevators (some places did not have them, but the majority did).

I expected bullet trains to be rare, probably twice a day, but they were also very regular, like every 10 minutes. There were simply so many varieties of trains (rapids, local, limited express, and shinkansen), and it felt as if everything was connected by rail.

Shrines

They were massive, well-maintained, and built of wood. Overall, they were aesthetically very pleasing, with gardens, trees, and structures. Though I felt they were more touristy than spiritual (maybe because there were lots of tourists). Everyone had the same entrance fees and the same level of access. Only those who were performing certain rituals had extra access. The crowd control and management were very professional. The streets leading to these shrines were very small and yet fully crowded with tiny shops and people. Yet these streets were very clean, and even the shops looked well-maintained. There were fees for fortunes and dedicated spaces for popular rituals (100 yen to get a fortune, tie the amulet at a dedicated place), and everything was well-maintained. Seeing these shrines also made me reflect on Hindu temples and temple streets back home.

This made me think of my own Hindu temples, temple streets, and commercial streets in my cities (Bengaluru, Chikkamagaluru, Udupi, and any old commercially important streets of India). I always thought they were badly managed. I thought that because there are so many people and these places get crowded, it is not possible to maintain them well. I always felt these old commercial streets needed to be widened to make them breathe. Poor crowd management in temples felt inevitable because there are so many people. How wrong I was! Even these small streets can have world-class facilities if the people and the government want them to. Kyoto was the best example of how small streets, lined with modest shops and major brands, can still be well-maintained and economically vibrant. Our Hindu temples need better and more modern people management as well as facility management, carried out with professionalism and empathy.

Seeing those shrines made me think about how grand many Hindu shrines might have been had they not been neglected or ruined over the centuries. If there had been no invasions over the last thousand years, how would these temples, palaces, and cities have grown? I had heard that many wooden Hindu temples and Indian wooden palaces were burned down. I always felt that, because they were wooden, they might not have been that great. No, they would have been architecturally magnificent, and in every way they would have been grand. Entire cities, along with temple structures, were ruined by invasions and apathy. How much we have lost!

Many shrines in Japan have been restored. So, I wondered why Hindu temples, palaces, and forts are not restored.

Automation

One strong impression I came away with was that Japan takes automation very seriously. They had so many sorts of vending machines: drinks, fresh on-the-spot orange juice, soft-serve ice cream, and animal-feeding food. You name it, and they have it in the form of a vending machine. That massive train network cannot be managed without a massive amount of automation.

My wife and I kept joking that one thing we would definitely miss after returning to the USA or India would be the Japanese toilet. It had water for cleaning, heated seats, and an automated cleaning system. This was the norm everywhere, from public parks, tourist places, trains, and aircraft to restaurants and hotels.

Language & Culture

One thing that stood out to me was how strongly Japanese language and culture remain present in everyday life. The train stations had a little bit of English along with Japanese, either on signboards or announcement boards. Most things were in Japanese. We hardly met anyone, barring only two or three people during our entire stay in Japan, who could converse in English beyond three or four words. We relied heavily on Google Lens and Google Translate for conversation and translation.

People are very down to earth. They were very friendly and helpful. Just because I do not know Japanese, they did not dismiss us. At least in our experience, very few people treated us dismissively for not knowing Japanese (maybe that was because we were tourists and only went to tourist places). There were many instances in which they went beyond their responsibility to help us. We have a saying, “Athithi Devo Bhavah!” (Guest is like God), and we truly felt that in Japanese hospitality. The taxi services were very good. They were very professional, taxis were kept clean, and there was no haggling or random price quote. If I stopped a taxi, it would stop and take us irrespective of our destination. They were dignified, wearing suits and calmly asking clarifying questions to understand clearly where we wanted to go.

Japan also felt like a high-trust society. Rarely did anyone check whether you had paid and had valid tickets for reserved or first-class seats on the train (I am not sure if they have other means of validating). Even in shops, hardly anyone was watching whether you had paid before taking things out (yes, there are CCTV cameras, but still). Hardly any police officers or security personnel were visible.

So, at least for me, these sayings, “English is needed to become a global power” or “English is needed to civilize” or “English is needed to adapt to global standards” or “Due to English we have an advantage” or “English is needed for access to modern science,” are all just propaganda or myth. I have seen living proof that people can be very cultured, disciplined, and advanced in every way even without English-language education.

Food

There was an incredible variety of food, and it was clear that people in Japan take food seriously. I especially liked the ramen. Though, as a vegetarian, finding a vegetarian-only restaurant was difficult. We were looking for vegan restaurants. There were many, but there were fewer near the places we were visiting, and they were always crowded.

Conclusion

I would recommend Japan to anyone who wants to experience a country through its culture, people, language, and everyday public life. It is a place that leaves a strong impression.

This is the 2nd post (first one) on my attempt to learn how to use LLMs for coding. I developed an Android app - Citta - A Personal Meditation Tracking App using Claude Code, even though I had never worked with Dart, Flutter, or Android development before. In the process of development, I realized that the essential software development engineering skills remain the same even in the LLM era of coding. LLM agents can produce professional-looking apps very fast, but making the underlying code production-ready and maintainable still takes work. LLMs/Agents will supercharge you if you have deep domain knowledge, use good software engineering practices, and have good basic computer science knowledge. Let me explain this in detail.

Experience

With my zero knowledge of Android (or its SDK, or Flutter framework), I was still able to develop a good app within 2 weeks (~30 hours of actual development work). The developed app is comparable to equivalent professional apps listed in the Play Store. Using an LLM definitely reduced the overall turnaround time from idea generation to the first working product.

I started by using the planning mode of Claude Code (shift + tab). I interacted with Claude Code to discuss my idea for the app. I explained how my app should look and feel, and what features the app should provide. As part of this process, I did ask some questions like which framework I should use, what kind of storage I should explore, why a DB does not make sense here, what the effect of storing everything in a file would be, and how this would scale as years go by. For everything, Claude gave me a good explanation and then followed up with a couple of options marked with the preferred way to do it. For a few of them, I chose what Claude gave as preferred, and for others, I overrode the preferred way with something else that I thought was the right way to do it. If I had prior knowledge in Flutter or Android development, I could have led Claude in an even better direction, as I could have asked better questions. With that domain knowledge, I would have thought even more deeply about the internals, and thus probably it would have given better alternatives.

I asked Claude to break the requirements into atomic small tasks that could be worked on independently. It did break them down into smaller tasks. I wanted to go one task at a time. But I guess my prompt was not clear, and Claude Code went ahead and completed all the broken-down tasks at once. Claude developed the complete UI. The UI development was a breeze with little hands-on help. As it completed everything, a lot of code got generated. I had to spend 2-3 days reading the code to understand what it had written. So, even though I was progressing fast in app development, which was exciting, I had also lost the context of what it was doing underneath. I had to slow down to regain an understanding of what it was doing so that I would be comfortable with what I was shipping.

Overall, it did not follow good coding best practices. It had duplicated code and also very little test coverage. Much of the implemented code did not have tests. I had to explicitly ask it to add test cases. So, even though the app looked professional from the outside, the code underneath was not production-ready or maintainable.

I wanted Claude to complete one atomic task at a time, then come back to me so that I could review it and then go to the next step. I also wanted it to add those tasks as GitHub issues so I could track the progress of the product implementation. Claude Code, in a few instances, pushed code to GitHub without running all the tests and static analyzers. Ideally, the iteration would be: implement a single task, run the unit tests, run the analyzers, do a self-review, wait for my review, push it to GitHub after human review, mark that task as complete in GitHub, and finally move on to the next GitHub issue.

There were many things Claude did not remember in its context, and it kept on making the same mistakes. For example, I had installed the Flutter SDK in a custom folder. Even though I provided the actual location of the SDK when it failed the first time, it did not remember. Rather, it kept on making the same mistake when it tried to run the build, as it could not find the SDK in the standard location. I created a skill which helped reduce that repeated mistake.

There was one bug related to the alarm not playing the first time the app started. Claude tried many things to fix it, but failed. Those fixes made things worse, and I had to roll back those changes. I did some investigation on my own, and I found two links which had information and fixes about a similar problem. I suggested those two links to Claude Code, and based on that, it implemented the actual fix for the bug. This worked nicely! Probably LLMs are good at solving bugs that need relatively little context. In this case, it needed to search for similar problems/errors and then infer how it could apply that knowledge to the current problem.

Claude Code had introduced a few logical bugs while developing the app. For example, the way it had implemented file backup and recovery had issues that could have led to loss of data. Only when I read the code was I able to discover and fix it. From this, I feel we need strong domain knowledge or experience which would help identify and fix these problems outside of the LLM agents. Having closer review cycles of generated code will also help identify them early and fix them.

The other thing I missed was a better code review tool. I would want to see the LLM prompts that generated or updated the code along with the code it had generated. This would give better context. So, the review should capture both code and LLM prompt interactions.

What next?

Here are some of the things I would like to practice and learn next:

• Developing skills or rules for the LLM agent that would help bring software engineering best practices into the workflow, so that LLM agents work through atomic tasks in a test-driven development style with a close review cycle.
• An LLM agent needs to augment the developer, and hence what I expect from the agent will be completely different from what another developer seeks from agents. I would want to set the following rules for the LLMs to be effective for my way of development:
  • Do not implement more than one GitHub issue without approval.
  • Run formatter, analyzer, and tests before reporting completion.
  • Avoid duplicate code.
  • Do not push to GitHub unless explicitly approved.
  • Start with test-driven development for every GitHub issue.
  • Add or update tests for every behavioral change.
  • Do a code review of self-implemented code before declaring the task completed.
  • Record unresolved risks before moving to the next task.
• Explore better code review tools that can show both the generated code and the LLM context that produced it.

Critical Observations

• Using an LLM agent for a new product idea can drastically reduce the overall time for actual product development. But there is a real risk of losing an understanding of the underlying code of the product. So you need to slow down to bring yourself up to speed.
• Writing code via LLMs does not remove my responsibility to read the generated code to understand the in-depth context.
• We need to have in-depth context of the problem/domain as well as coding/computer science knowledge for better prompts and a better way to lead the agents in the right direction.
• I need to create LLM agent skills or rules to make the code style and quality closer to the way I would have written it.