I have a similar philosophy for the systems I manage. We have always been severely understaffed, so I treat any user support request that repeats twice as a bug.

If the decision to push a button is yours, I'll give you the button. If you need some data more than once, you get a button too. My ideal user never needs to know who manages the system or how to contact us.

This has even got me a "why do you guys have almost no tickets? You aren't doing anything!" talk a couple times. Music for my ears.

I'm doing this with the SaaS I'm building (outside of my day job). My URL endpoint functions were directly executing SQL on the database until I decided that I couldn't go on like this, and only then did I write some classes to represent the business logic objects. It sounds ridiculous, but it gave me the flexibility to experiment with what those objects should do before imposing a formalism on them, and I found that very valuable.

At my day job, I'm expected to use TDD, and I don't like it. It's not that I don't like tests - I don't like writing them, but I like it when they're there, so I write them while feeling a bit grumpy. My problem with TDD is that I'm a big picture thinker, and I start from the inputs and work incrementally towards the outputs, without having a good outline of how I'm going to get there, so I can't write unit tests before writing any actual code, because I don't know what the units are going to be yet.

I also find my colleagues' code to be factored in a slightly unnatural way, because it reads like they've structured the code to match the tests, rather than written tests to test aspects of the code.

Maybe I should just be a hermit-programmer.

I have a principle called "the principle of maximum inconvenience".

This principle tells you that whatever you should be doing right now, is the most inconvenient possible path at this time.

It serves as a guide to help orient me in life especially when I'm at a crossroads.

I call my personal methodology PDD, Pain Driven Development.

Fix the thing that is causing the most pain. Or is likely to cause pain in the near future.

Is the author still following this paradigm? I can't imagine a situation from which Rama would emerge like this.

Thought it would be about vibe coding by the title alone :D

I really like this but prefer to think of it in the inverse: Build new technology because you feel the pain of current alternatives.

Sounds like one of the tenets of Extreme Programming: Pay attention to pain. When something is hard to do, fix what makes it hard - your architecture, your class design, your build process, whatever. Don't keep suffering the pain. Fix it.