The mind is single-core. There's no black lotus you can huff or secret technique to master to make it more than one core. And the inertia returning to its task is significant.
[1] https://www.npr.org/sections/health-shots/2013/01/24/1701601...
I think we can say (1) engineering productivity is severely impeded by interruptions and (2) it doesn't hurt to work on skills to help yourself get less impacted by disruptions.
You're right there's no secret technique, but documenting your work and thoughts, keeping TODO lists, breaking down large work items into small chunks can all help distractions not ruin your day.
But, these are effectively "hacks" and the only way to ensure highest possible productivity is to have processes which prevent engineers from being interrupted
There might be a good reason why code developed under extreme focus also tends to be inscrutable to others.
Wow. I have never thought about it this way. That's quite a profound insight. Thanks.
The corollary is true as well. I, as well as many others I imagine, have had to fix and maintain dumpster fires of spaghetti code developed under the standard distraction-filled modern business day.
Distraction doesn't beget good code; instead, a good programmer learns how to be as productive as they can despite the dysfunction of a typical modern business.
Any engineer is only as productive as the system she works in, and a system that eschews communication for long periods of solitary work is not, generally, a productive system.
I vaguely remember reading about an old study from one of those telephone companies in the '60s or so about engineering productivity, and they found that the single thing that set the "best" engineers apart from their peers was in how much more they communicated. I haven't been able to find this study, but if someone knows what I'm talking about, please shoot me a link or something.
You can do a lot of work in parallel if you have the correct coroutine architecture. That involves encapsulating information in a way that you can put it down and pick it back up efficiently.
An upside of developing this skill is that if you become adept at storing the relevant information, you will be better at handing that information off to another person.
Further, absolute productivity at a single task is rarely the most important thing. If it is, then you've reduced yourself to a cog or a worker bee.
Taking responsibility for the direction of your work means accepting that you need to be part of the decision-making process, which will lower your absolute productivity, but (done well) will increase your overall effectiveness.
'Productivity' is subjective to the business and position. In your 2-person startup, productivity might be shipping CRUD functionality in triplicate and setting up the bones for a larger application. In an enterprise, productivity can simply be not _reducing_ productivity while doing something. A develop and a manager being productive also look very different. I don't think your point and GP's point are mutually exclusive.