[twblalock]

> context switching is the mind killer

Only if you let it be.

Minimize the context. It turns out that good programming practices work well for this: break things down and encapsulate them. You haven't done that if you need to maintain a giant complex picture in your head that goes "poof" and disappears when people interrupt you, or when you need to go to the bathroom, or when you go to lunch.

Break things down into smaller parts. Encapsulate. Write things down. Get used to picking up where you left off. It takes practice just like anything else, but it's worth it. Demands on your time only become more intense as you advance in your career, so it's very beneficial to develop those skills early on.

[judofyr]

I have no idea why you're getting downvoted into oblivion. These all sounds like excellent ideas. Can someone elaborate what's so controversial in this comment?

[lostdog]

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.

[corty]

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.

[probably_wrong]

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?

[gumby]

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.

[disgruntled101]

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