[flagged]
AI will happen anyways.
Programmer interrupted: The cost of interruption and context switching (2022)
21–30 of 271 posts
Re: Programmer interrupted: The cost of interruption and context switching (2022)
#22We definitely need a mandatory all-team meeting about this every Tuesday and Thursday at 2 pm until the issue has been resolved.
At one worksite I did raise the issue of there being too many meetings. The response was "Can we call a huddle sometime this week to discuss this issue?"
Re: Programmer interrupted: The cost of interruption and context switching (2022)
#23I actively like being distracted when I'm programming. I tend to approach a problem from lots of different directions, each time fizzling out, hitting a block or having some sort of mental reset, until something unconsciously clicks and an overall structure, understanding or solution emerges. Continually leaving and returning to the problem is a part of that process, so I tend to find someone walking up with a question rather welcome. The biggest and most effective leave-and-return is of course to sleep on it, and it's rare that I go to bed with a problem at the back of my mind and don't wake up with at least a new approach or insight.
I have to be careful, though, as I'm aware most of my colleagues don't feel the same way about interruptions.
Re: Programmer interrupted: The cost of interruption and context switching (2022)
#24It's the shadow work of programming I never liked.
- Setting up boilerplate code
- Configuring my IDE
- Configuring special browsers (for web development) with no addons or tweaks done so it appears like an average person is using the browser
- Configuring the OS
- Separating work from play. Keeping separate machines strictly for programming
- Tests
- Reading best practice material
- Researching if other people have written the exact same thing as you and uploaded it to GitHub (or don't repeat what other's have coded already).
All that can be set-and-forget but I periodically have to do it all again because requirements change, or I get a new machine or I simply want to re-configure my development environment for minor (or major) gains in productivity.
Re: Programmer interrupted: The cost of interruption and context switching (2022)
#25Sadly, the cost of context switching is well-known, and has been proven, over and over again, for decades. But managers don't care (and many co-workers also). A quick shufti at most modern open-plan offices, shows the contempt that managers have for developer context. They know better, and have made the conscious decision to go open, anyway. I remember visiting the Facebook/Instagram building, in NYC, and was aghast…
>But managers don't care (and many co-workers also).
i bet 99% of time people are interrupting themselves. Like i just did to browse HN.
Re: Programmer interrupted: The cost of interruption and context switching (2022)
#26Now I have a family I often can't choose the end of my working day so it coincides with a natural break in my work. In those circumstances, when I know they're going to arrive back in less than 30 minutes, I stop working and do a brain dump of everything that's going on in my head into a plain text file. With that I can pick things up much faster the next morning. I've even started doing it during the day when both my wife and I are working from home and we're about to have lunch together. I'd seriously recommend it.
It somewhat reminds me of this Hemingway quote "You read what you have written and, as you always stop when you know what is going to happen next, you go on from there. You write until you come to a place where you still have your juice and know what will happen next and you stop and try to live through until the next day when you hit it again." I think there's an art to stopping at the right time, even if it's within constraints that aren't in your control.
Re: Programmer interrupted: The cost of interruption and context switching (2022)
#27[flagged]
> From a risk management perspective, why would I hire a programmer and pay them 200k a year when they cannot handle basic communication without becoming unproductive? Do you actually hire programmers (people just transforming detailed spec into code) at 200K/y? Or do you hire Engineers for 200K + Stock to transform uncertain requirements and constraints into a working solution? If the former, you are overpaying a lo…
> Does such a robot exists
No, but if it ever does, they're going to replace all programmers with it, regardless of their "soft skills".
Re: Programmer interrupted: The cost of interruption and context switching (2022)
#28Earlier quoted context omitted.
That’s the same misconception about programming that people had decades ago. People thought the same thing when we introduced 5GLs back in the 1980s, and there was a lot of hype, and programming became more accessible, but demand for programmers increased rather than decreasing. People thought the same thing back when Fortran was introduced in the 1950s, and programming became more accessible, but the demand for prog…
Same with SQL, which was promised as a way for data processing managers to get rid of expensive programmers as the managers would now be able to get whatever information they wanted from their databases using an easy to understand, English like language. All it did was change the nature of the job of retrieving and storing database information but didn't actually get rid of the programmers.
> All it did was change the nature of the job
It also created SQL injection vulnerabilities, so there's that.
Re: Programmer interrupted: The cost of interruption and context switching (2022)
#29I don't disagree but...
If you're having a huge issue with this, I suggest trying to find ways to hold less context at one time.
Write stuff down & get it out of your head more often. Write down all of your ideas & break down your tasks into smaller tasks. Don't try & solve a giant problem all at once without writing down what you're going to do. You may also discover issues earlier.
It doesn't get rid of the issue 100% but it helps a lot. I say this as a dev who has to do a lot of context switching.