Happy Code is less options

Simplicity is prerequisite for reliability.

Too many options do not make coding feel free.
They make it feel noisy.

Coding gets lighter
when fewer decisions stand between you and the work.

People praise flexible tools
because they let you work any way you want.

That sounds nice
until every small task begins with another choice.

How should this be formatted?
Where should this live?
Which pattern fits here?

Now the work is not just the work.
The work is also deciding how to do the work.

That is fine for important design choices.
Those deserve attention.

But repeated low-value micro-decisions are different.
They do not make the code better.
They just spend your focus before the real problem starts.

This is not only a developer feeling.
Psychologists have studied choice overload
and decision fatigue for years.

More options can feel empowering at first,
but they also increase mental load.

After enough small decisions,
your brain gets worse at making the next one.

Software work already has enough real decisions.
We should not add fake ones.

Go is a good relief valve.
Its formatting rules are strict enough
that one whole category of friction just disappears.

You run gofmt and move on.

Your brain stays on the problem
instead of sliding into preference.

That is not less professional.
That is less waste.

A formatter removes one kind of noise.
Good code removes another.

CUPID¹ is a way of thinking about code
that feels good to work with.

It is not a checklist for perfect architecture.

It is a reminder that code can either spend your attention
or protect it.

Three parts matter here:
predictability,
idiomatic code,
and doing one thing well.

Predictable code asks fewer questions from your brain.

Idiomatic code follows a shape
you can recognise without negotiation.

Code that does one thing well
gives you fewer paths to compare.

Good conventions are not a cage.
They are a shortcut past decisions
that should not matter.

This does not mean every option is bad.
It means extra options should earn their place.

If a language, tool, or design
is barely opinionated,
you keep making the same kind of decision again and again.

If it is opinionated,
the big question becomes simple:

do I like this way of working or not?

That shift matters more
than it first seems.

You stop managing possibility and start doing the work.

The code feels lighter
because your mind does too.

Happy Code begins where needless choice ends.