Often all the context you load into your head is other people's code. Sometimes you don't have control over how complex the codebase becomes. Debugging also requires a lot of context.

I didn't downvote the comment (yet), but I understand why many people did: It's incredibly dismissive and wrong! Yes, you should adopt methods for keeping the context so you don't lose it and continue from where you started. I've added plenty of tools to my mental toolbox, and now I work on more complex problems more quickly then before. However, even with good context-keeping skills, protecting a block of time will still 10x your productivity over being interrupted constantly.

Developers don't demand focus time for their own comfort. It's because the focus time is necessary for good work.

The grandparent is a naive oversimplification. Most things that aren't just very trivial CRUD do have irreducible complexity, that cannot be encapsulated away. Also, making notes doesn't help there, notes that were written need to be read again and again and again, multiplying the effort involved.

I did not downvote that comment, but I think it's bad advice for two reasons:

1. It tries to address the sympthoms without solving the problem. Building a workflow around the distractions assumes that my time is less important than everybody else's.

2. Programming is hard. The comment suggests that the solution to the overhead caused by context switching is... adding more overhead. How about letting people work in peace instead?

To add to the other comments: the work of figuring out how to break things down often requires long periods of quiet thought. In addition, I often refactor as I write, as the process of implementation can uncover poor design decisions made up front.

In short: my work is rarely "beads on a string" that can easily be popped off, and to the degree they are, the unit of time is typically hours, not a half hour.

it has triggered mediocre CRUD maintainers that do not have fundamental development skills and yet think very highly of themselves because they know how to write a new API endpoint