Not slogans. These are the positions I argue for in design reviews, and the ones I have been wrong about often enough to state carefully.
The simplest system that solves the problem is the one that can still be understood at 3am by someone who did not write it. Every abstraction is a loan taken against future comprehension, and the interest is paid during incidents.
Circuit breakers, retries, and timeouts bolted onto a finished system only redistribute its failures. Resilience is a property of how services depend on each other, which means it is decided in the design review or not at all.
Tracing and metrics are not an operational afterthought — they are how a distributed system becomes legible. If you cannot answer where the latency went without adding code, the architecture already failed at something.
Code is read far more often than written, and rewritten more often than either. The clever solution wins the sprint; the obvious one is still there in four years, when the people who understood the cleverness have moved on.
A language, a database, or a framework is worth changing when a profile says so and the migration can be done incrementally. Big-bang rewrites bet the delivery date on a hypothesis.
New tools deserve curiosity and skepticism in that order. I use AI-assisted workflows daily and I write the architectural guardrails first, because a team that adopts tooling without constraints simply produces its technical debt faster.