Last Updated: February 2026 - The Bruce Lee principles still apply, but the context has shifted. Added: AI pragmatism, platform engineering mindset, and why “no way as way” matters more than ever.

For my inaugural post, I’d like to lead off with my philosophies and approaches in DevOps ( What is DevOps? ). Like many of my childhood friends, I idolized Bruce Lee growing up. There is no introduction needed for Bruce as there isn’t anything I can say which hasn’t already been said about the legend. One of his many talents and creations included a guiding set of philosophical principles.

Most, if not all, of these thoughts, profoundly correlate to everything I do. I will go through some of these ideas and point out the link that binds to my guiding principles in my profession.

“Be Water, My Friend”

My north star in DevOps is pragmatism. I believe that DevOps is not there to impede but facilitate. I do not believe in coming into any situation with a set opinion on how certain things should be done or a particular set of tools should be integrated.

My approach is to be practical. I want to observe the efficacy of the current workflow. Get a thorough understanding of the business and team roadmap and goals, then let’s hammer out a plan on how and what I can do to help get the team there. The only thing left after that is to execute.

Be flexible. Be nimble. Be pragmatic, my friend.

“Using no way as way; having no limitation as limitation”

There is a time and place to implement bleeding-edge technologies. Please don’t jump into a new database or language because it is unused and shiny. Sometimes an older but much more stable solution would work equally well.

I’ve been in situations when a new and shiny piece of database falls over at 3 am, and suddenly, the DevOps team realizes there is no in-house expertise and community support is lacking. It’s a very lonely feeling to have in those wee hours. The feeling of defecating lego bricks is overwhelming as each minute passes with your SaaS being down. “Be a practical dreamer backed by action.”

“Be a practical dreamer backed by action”

Talk is cheap. Debate is expensive. Meetings are a drag. Enough with the pontification.

The highly opinionated tech heads who enjoy the endless “Hmm and Haw” debates are my kryptonite. Time is money, so let’s spend it with purpose and intent.

Don’t mistake action without purpose as an exercise in productivity. Any proof-of-concept effort, evaluation, or playing with new tech should produce justifiable data at the end to warrant the time investment.

“Research your own experience. Absorb what is useful. Reject what is useless. Add what is essentially your own.”

Everyone’s journey and experience differ slightly from their peers. It is especially prevalent in DevOps as it includes many roles, skills, and talents grouped as one. Depending on your journey and experience, your take on DevOps will not be the same as mine. I accumulated and achieved this level of understanding because of the convergence of all I’ve done and the roads traveled. If it’s working then I’ll keep on doing what I am doing and prosper. If not, I’ll make minor changes that will inevitably lead to positive net results later.

“Walk on!”

I walk my path and do not let others influence me frivolously. I can hold my own, and although I do not claim to know everything (it is impossible!), There are still many known unknowns and even more unknown unknowns. This keeps me humble and pragmatic. It is my way to DevOps.

2026 Update: AI, Platforms, and Pragmatism Under Pressure

Nine years later, I still start my day with these principles. But running infrastructure in 2026 adds new dimensions to “being water.”

Platform Engineering: Pragmatism at Scale

The original post emphasized observing before prescribing. In 2026, this manifests as platform engineering done right:

  • Start with developer pain, not vendor solutions. The worst platforms are built by architects who never wrote production code.
  • Golden paths, not golden cages. Developers should be able to break out of the paved road when necessary, without breaking everything.
  • Measure toil reduction, not tool adoption. A platform that saves 10 minutes per deployment but adds 30 minutes of debugging isn’t a win.

AI Operations: The New “Bleeding Edge”

My warning about “new and shiny databases falling over at 3 AM”? Multiply that by GPU costs, model hallucinations, and storage cost.

Running LLMs in production requires a new pragmatism:

  1. Not every use case needs a 70B model. Sometimes a fine-tuned 7B model, or even classic NLP, is the right call.
  2. Inference cost is the new cloud bill shock. Token usage scales linearly with user growth. Plan for it.
  3. Prompt engineering is not engineering. It’s experimentation. Document what works, version your prompts, and treat them like code.
  4. Retrieval-Augmented Generation (RAG) pipelines fail silently. When your model starts hallucinating, is it the model, the context window, or the retrieval? Observability matters more than ever.

“Using No Way As Way” in 2026

The AI hype cycle is in full swing. Every vendor promises to “transform” your operations. My response: be water.

Absorb what’s useful:

  • AI-assisted incident triage (summarizing logs, suggesting root causes)
  • Automated documentation generation
  • Code review assistants for infrastructure-as-code

Reject what’s useless:

  • AI “replacing” engineers (it augments, it doesn’t replace)
  • LLMs for critical security decisions (explainability matters)
  • Vendors promising “zero touch” operations (someone always touches it eventually)

Add what’s essentially your own:

Your organization’s context, regulatory requirements, team structure, legacy systems, determines what actually works. No off-the-shelf platform or AI solution understands your 3 AM pager history.

The Unchanged Core

Despite Platform Engineering, AI Operations, and whatever comes next:

  • Pragmatism still wins. The team that ships working systems beats the team with the best conference slides.
  • Communication beats tooling. Kubernetes won’t fix your Dev vs. Ops feud.
  • Someone still needs to care at 3 AM. Automation helps, but ownership matters.

The tools change. The principles endure. Be flexible. Be pragmatic.