Some tickets look simple and still get postponed for days.
Others are objectively harder, but somehow easier to attack.
That contradiction used to confuse me.
Why do some developers avoid the exact task that would create the most value?
Why do we spend 45 minutes cleaning side details and 0 minutes starting the real work?
I think the answer is less technical than we like to admit.
Hard tickets do not only demand skill.
They also activate exposure.
A difficult ticket can mean:
uncertainty
visible failure
code you do not fully trust
hidden complexity
risk of slowing others down
a feeling that you should already know
And the brain reacts to that.
Not in a dramatic way.
In a practical one.
It diverts.
That is why easy tasks become seductive.
They reduce tension.
They create movement.
They give the illusion of productivity without the cognitive threat of real progress.
Once you understand this, a lot of dev behavior suddenly makes sense.
The solution is not just "be more disciplined."
It is usually:
define the first safe entry into the hard ticket
lower ambiguity
externalize unknowns
shrink the commitment
protect your best focus window
and stop expecting your brain to love uncertainty by default
That last point matters.
Brains like familiarity.
Engineering often requires the opposite.
If you want to work better, you need better transitions into effort.
Not more guilt.
Resources I found useful on that angle:
Top comments (0)