This cloudy, rainy weekend I finally picked up The Effective Software Engineer by Addy Osmani. I’m still early in it, but it already feels like one of those books I’ll come back to more than once. It’s clear, practical, and easy to follow — at least from what I’ve seen so far.
One chapter in particular stood out to me: “Anti Patterns That Limit Individual Contributor Effectiveness.” It got me thinking about some of the habits we fall into (myself included) that quietly work against how effective we could be.
Motivation
So I thought I’d try something a bit different and start a small series of short posts around this. Nothing too formal — just reflections on a few of these anti-patterns, mixed with my own experiences. This is the first one, and I’m starting with something I run into quite often: context switching, and how it chips away at deep focus.
Part of the reason for writing these is simply to make these patterns a bit more visible to myself as well. It’s easy to slip into them without noticing. Putting them into words helps me step back a bit — maybe it does the same for someone else too.
I probably won’t follow the exact order from the book. Not because I’d change anything there — just picking the ones that resonate or feel worth thinking through a bit more at a given moment.
If this resonates, I’ll continue the series over time.
Important: my intention is not to replace the book. This series is simply a personal reflection on the behaviors that sometimes get in the way of being effective. I strongly recommend reading the book whether or not you follow this series on my blog.
Tone and structuring
Addy Osmani has a clear and well-structured way of looking at each anti-pattern:
- Signs
- Remedy
- Culture fix
- Benefit
That structure makes the ideas very easy to follow and absorb.
In my blog posts, though, I probably won’t follow the same format. I want to keep a more natural flow and write these as personal reflections on the anti-patterns that stand out to me.
Context switching is something senior engineers are expected to manage
There is a common expectation that senior engineers should be able to carry multiple projects and switch context without much friction. I think that expectation is partly fair, but only with a few important conditions:
- context switching should happen for a strong reason: to unblock a person or team, to help work move in the right direction, or to increase business value in a meaningful way. Otherwise, it is often better to defer it instead of reacting immediately
- senior engineers should be comfortable saying no when the interruption is mostly noise and can wait, while also suggesting a better time to come back to it
- priorities still matter most: if switching is necessary, focus on the task with the highest impact and the greatest multiplier effect, because senior engineers are expected to create leverage, not just stay busy
Context-switching is more expensive than it looks
What I liked about this part of Addy Osmani’s book is that it names something many of us normalize too easily. We often treat constant switching as a sign of being helpful, responsive, or “on top of things.” But in practice, it usually means we’re never fully in one problem long enough to do our best work.
That part especially resonated with me. Some of the work I feel best about didn’t come from moving fast between five things. It came from staying with one hard problem long enough for the shape of it to become clear. And that only really happens when my attention has time to settle.
The tricky part is that context switching isn’t always avoidable. Engineering work is collaborative, and interruptions come with the job. But I think the book makes a useful distinction: the problem isn’t switching at all, it’s letting it become the default way of working.
Lately I’ve been thinking about that more seriously in my own routines. Fewer tabs, fewer parallel threads, fewer self-inflicted interruptions. Not because deep focus is always possible, but because when I protect it even a little, the difference in clarity is obvious.
My current strategies for handling context switching
scheduling few longer blocks: what helps me most is keeping things simple and intentional. I try to protect a few longer blocks for focused work, check messages in batches instead of constantly reacting, and be more honest about when a new request can wait.
grouping simillar task: I also get better results when I group similar work together instead of mixing everything across the day. If I can keep coding, meetings, and smaller admin tasks from competing for the same attention, I usually end the day with more clarity and less mental fatigue.
repeatedly asking myself one question: can AI help me automate this, sketch a quick solution, or help me brainstorm so I can save time and reduce unnecessary switching?
something I am currently exprimenting, making my availability visible to others: when people know when I’m available and when I’m trying to stay focused, collaboration still works, but with less random interruption.
Context switching is not going away, so learning how to manage it well is something many of us will keep working on. I’d love to hear what strategies help you stay effective without draining your energy.
Further reading: