Rule of least surprise

Rule of Least Surprise says: anything ( some it system in our case) should behave in the way that causes the least surprise to people, users, us. We all love suprises we feel good about… not the biggest fans abotu those bad or negative experiences.

Surprise creates confusion, bugs, and lost trust. Prefer predictability over cleverness.

Think about it… when you call a function, you expect it to do what it says, not sneak in extra behavior. Silent mutations are a classic trap. Side effects are unknown to the user. Trust me, the user will NOT FIGURE IT OUT. Passing an object and having it changed behind your back. Magic defaults are even worse, the system “helps” you by choosing something you didn’t ask for, and then everything breaks when that choice is wrong.

Hidden side effects like a function that quietly sends HTTP requests or writes to disk makes debugging a nightmare. Over-automation auto-fixes things you didn’t want touched and inconsistency means the same thing behaves differently in different places.

Remember that when coding the most imortant thing is that You know what will happen and are certain of that. This is a BIG NO NO during todays AI era, we never can be 100% sure unless you check verything twice… or more…

Favor explicit behavior: functions that return new values instead of mutating. Clear defaults that are obvious and documented. Visible side effects: if something writes to disk, send email, or mutate global state, the name should scream that. Opt-in automation: don’t auto-migrate, auto-format, or auto-overwrite unless the user explicitly asks. Consistency across your API, CLI, and framework so the same flag or pattern always means the same thing.

When in doubt, ask: “Would this surprise me, or feel natural?” If it surprises, redesign it. Predictability beats cleverness every time.