Somewhere along the way, complexity got mistaken for competence. A system with more moving parts looks more serious; a diagram that takes an hour to explain looks like hard problems being solved. Often it is the opposite — the residue of decisions deferred, of "right" chosen over "fit," of cleverness no one asked for.
Complexity is not a sign you are doing something hard. It is a cost you agree to pay, every day, for as long as the system lives — in onboarding, in debugging, in the blast radius of every change. Sometimes the problem genuinely demands it, and then the cost is worth paying. But essential complexity is rarer than the accidental kind, and the accidental kind is almost always self-inflicted: added early, in the name of a scale or a flexibility that had not arrived and frequently never did.
The opposite reflex fails just as hard. Strip away the structure a system genuinely needs and you do not get elegance; you get fragility wearing elegance's clothes — clean right up until the first case it was too simple to handle. The skill is not minimizing complexity. It is spending it deliberately: paying it exactly where the problem requires and refusing it everywhere else.
The test for any piece of complexity is brutal and clarifying: what does this buy, and would I pay for it again knowing what I know now? Complexity that cannot answer is not sophistication. It is debt that hasn't been invoiced yet — and the system pays the interest whether or not anyone reads the bill.