Have you ever opted for the path of least resistance?
Of course you have. Everyone does. In work, especially, it’s almost the default setting: you put your blinders on, you focus on your ticket, you ship your bit, you move on. Why look for trouble? It’s “just a job”, right? If people want you to take on more responsibility, they can pay for it.
I get it.
What I don’t love (and what I’m trying to unlearn) is the version of that mindset that turns into lack of care. The kind where anything outside your exact scope becomes invisible. Not my package, not my bug, not my ticket, not my problem.
And here’s the uncomfortable part: lately I’ve been guilty of it.
In the past few months I stumbled on small issues outside my lane: a build error in a package in our monorepo, a UI bug unrelated to my ticket, a requirement that was clearly malformed. I noticed them… and kept going. No report. No message. No “hey, is this expected?”. Nothing.
Not because I don’t care about my team. Quite the opposite. I care a lot. The problem is that my brain has a couple of default reactions that are… not great.
1) The impostor reflex
I still feel like the newbie. The least skilled person in the room. The impostor syndrome has improved since I joined, but it still shows up in small moments like these.
The script is always the same: “They know better than me. There must be a reason. If I ask, I’ll look stupid.”
Which is ironic, because I ship imperfect code all the time like every other human being, and I love when someone catches something before it becomes a bigger issue.
2) The tunnel-vision reflex
When I’m in the groove with a task, anything else feels like noise. If a package I don’t need is failing, I build the package I do need and crack on. I tell myself I’m being focused, efficient, disciplined.
But the truth is uglier: it’s a tiny form of selfishness disguised as productivity. “Somebody else will deal with it.”
And of course… it came back to bite me.
That build error didn’t magically fix itself. It went unnoticed and eventually blocked my deployment when the deadline was tight. That UI bug ended up overlapping with the area I was working on, so I had to fix it in a rush. That unclear requirement? Still needed. So I added it at the end, and it made the whole thing look sloppy.
None of these were catastrophic. They were small. Edge cases.
But that’s exactly why they matter.
The big problems get noticed. The small ones are the ones that grow quietly until they become your problem anyway. Or worse, somebody else’s emergency.
So yeah, lesson learned (hopefully). Not in a dramatic “I’m a terrible person” way. More in a practical, boring, grown-up way:
If you notice a small crack, don’t step over it and hope it disappears.
I’m trying to build a new reflex: pause for ten seconds, and do the smallest responsible thing.
- Drop a quick message in the right channel.
- Create a tiny ticket.
- Ask “is this expected?” without writing a novel. -Or if it’s truly trivial, fix it and move on.
Step by step. Less tunnel vision. More ownership. More “common good”.