161–170 of 253 posts
---
And I added this part later, just to frame the question in case it suggests that I think notes are useless here:
I have been writing and keeping notes of my work for more than a decade, mostly writing them as I go.
I have been programming since 1977/78, and sometimes for work, but most of the time for fun. As someone who does technical work at heights with rope access, and many years of technical diving on hydraulics, pneumatic, and electrical equipment, I can say it all depends on your ability to shut out interruptions and get to a good stopping point. I get frustrated when I am programming and I am interrupted, but my most fr…
To those advocating writing (more notes) to help context switching, just a thought — do chess players keep notes during a running game? --- And I added this part later, just to frame the question in case it suggests that I think notes are useless here: I have been writing and keeping notes of my work for more than a decade, mostly writing them as I go.
When I make a move I spend a few mins replaying the moves to make sure I recall my current plan and that I'm not missing anything obvious, before I start analyzing possible moves.
> Your non-techie peers just don’t get it, no matter how many times you try to make them understand. We really need to get past this smug idea that tech work is uniquely difficult in a way that no one else can understand. Any deep work suffers from interruptions, and programming isn't the only type of work that has significant mental context. This idea that programmers are uniquely vulnerable does no favors when tryi…
This is absolutely true. I no longer mind interruptions. I don't love them, but they aren't devastating productivity crashes either. Weirdly enough, friendly, helpful answers to the query seems to reduce interruptions. I think people don't mind interrupting grumpy programmers.
Also, adopting contemporary coding practice helps. Keeping functions to a single purpose. Not mutating data. Restricting side effects. Automated testing. Acquiring complete understanding of your tools and frameworks. These things help you grasp at a glance more quickly what's happening.
In short, committing to allow people to interrupt can alter your approach and work flow to accommodate interruptions
However, these discussions very often commit a big mistake: the Ford mass production mistake of being too myopic, optimising too locally.
In an organisation there are many people working complex problems toward a common goal. You can optimise for local productivity, i.e. one programmer steams ahead, ignoring the rest of the organisation, and gets a lot done. But when local productivity is optimised at the cost of shutting down quick communication between people, the organisation will grind to a halt.
The programmer will, eventually, make the wrong things, in the wrong amount, and at high cost -- not to mention how the other people that needed help from the programmer will just hover around and not know what to do.
Or worse, but more likely: they'll improvise an incorrect solution to the problem. Eventually that solution will blow up and the programmer will have even more work to do to fix it.
This is similar to the problems Ford made for himself with the mass production paradigm, in that you can install a machine to really efficiently make parts for a car at a rate of 1,000 per second -- but if it needs to make them in batches of 50,000 and it takes hours to set up the batch, you're adding so many hidden costs to the process. Local optimisation can easily kill global optimisation. (Entire books have been written about this, so I won't expand too much on it.)
If you truly want good results, you can't take a myopic view of optimisation and only look at your personal ability to crank out solutions to what you think are the right problems.
For good results, you need to optimise the productivity of the entire system, and the entire organisation is a good start. (Later, you should include suppliers and other peripheral entities in your optimisation process.)
The inefficiencies of the organisation is, in my experience, almost never the ability of a programmer to crank out solutions to what they think are the important problems.
In my experience, the inefficiencies are almost always lacking communication. Failure to understand the important problems. Slow feedback. Code lying around not making things better for the users. Code written for a problem someone decided were no longer important. Bad documentation and internal support. Bad teamwork, especially across division and team boundaries.
Essentially all the problems we know from the old bad days of manufacturing.
Please, realise that the person interrupting you definitely think they are doing it for a good reason, and they are probably trying to spare you from meaningless work -- now, or in the future.
If that's not the case, then the discussion must be centered around organisational productivity, not just the idea that personal productivity is more important than anything else.
I do my best work at night, when everyone is asleep.
What I am facing however, is a related issue. Perhaps because I have not been doing much programming lately, I find it increasingly difficult to actually get and be in the zone. When I go in, I go all in, and enter a kind of fugue state where the hours slip away. While for some this may sound advantageous, in the past, it has been associated with some bad physical and psychological health outcomes. Now, I actually have anxiety about going into such a state, and try to piece meal my problems, and focus on the non-programming work and thinking.
Situations change, and I am about to be in one where I do really need to perform a lot of coding myself. I suppose I am answering my own question, but I need to split up my work and take notes to reduce the numbers of abstracted layers upon which I am working. Take more breaks with confidence I can return.
I suspect this technique can help ease the burdens of interruptions as well, but it does come at a cost in time. For me, the severe crunch time requirements and gained insane last minute skills should still be less necessary for some time. This is likely called being in a startup and getting older and, well, recognizing long-term limitations.
To those advocating writing (more notes) to help context switching, just a thought — do chess players keep notes during a running game? --- And I added this part later, just to frame the question in case it suggests that I think notes are useless here: I have been writing and keeping notes of my work for more than a decade, mostly writing them as I go.
In correspondence it is bit different and there I usually try and write down lines.