Programmers, teach non-geeks the true cost of interruptions (2014) • Hacker News Board

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#201

Post by mmarq » Sat, Jul 10, 2021, 11:15 AM UTC

> Your non-techie peers just don’t get it, no matter how many times you try to make them understand

In my opinion this is more common to software development only because software developers, at laest in Europe, do not have the same social recognition as other professionals. An undisciplined PM/PO interrupting everybody to get estimates to update their GANTT chart will be as disruptive in an operating theater or in a legal office as they are in a software development team. Society just decided to not allow randos (as in people with no medical training) in operating theaters while welcoming them (as in people with no development training) in software development teams. Worse than that, these randos often have more power than the professionals doing the work. Surgeons would be complaining and people would be dying, if scrum-certified noisy "servant-leader" PMs were allowed to decide how to carry out operations.

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#202

Post by easygenes » Sat, Jul 10, 2021, 11:30 AM UTC

dagurp wrote: post #184

eggy wrote: post #52

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…

Airline pilots have a very high workload when landing and it requires intense focus starting about 30 minute before. They are not allowed to talk about anything unrelated in that period.

Yup, and you can be very grateful for their decisions in that period as well. The most hairy flight I’ve been on involved trying to land in Kampala in the midst of a terrible thunderstorm. Turbulence like I’d never felt before (after hundreds of flights). A hushed stillness in the cabin, people grabbing their loved ones. From the amount of time you’ve been descending and the feeling of the flight you know you’re on final approach. Then wham, it feels like the plane fell out of the sky, and it’s still black out the window. A moment more calm. You look around; you thought what you felt before was the worst turbulence ever but now you’re surprised the plane is in one piece still. Then the pilot aborts approach at full throttle and you’re pushed back in your seat with unusual force.

A couple of minutes pass. You’re still ascending. The pilot announces you’ll circle for another 20 minutes waiting for the storm to pass, and if not they will have to return to the port of departure.

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#203

Post by the_other » Sat, Jul 10, 2021, 11:35 AM UTC

mmarq wrote: post #201

> Your non-techie peers just don’t get it, no matter how many times you try to make them understand In my opinion this is more common to software development only because software developers, at laest in Europe, do not have the same social recognition as other professionals. An undisciplined PM/PO interrupting everybody to get estimates to update their GANTT chart will be as disruptive in an operating theater or in a…

This is one of the things scrum is meant to help fix. In your daily scrum, tell your team you need X hours that day w/out interruptions and explain why. If your Scrum Master doesn’t protect you from interruptions by others, they’re not mastering their Scrum effectively. Ideally knowledge of the codebase would be spread around your team already such that other people can handle the interruptions I think it would be fair not to request this “no interruptions” every day.

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#204

Post by the_other » Sat, Jul 10, 2021, 11:39 AM UTC

mtsr wrote: post #196

ideamotor wrote: post #167

Interruptions are very challenging with any deep work that takes hours. This is true. 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 a…

I would recommend trying the pomodoro method: 25 minutes of work, 5 minute break away from screens, repeat. 30 minute break after a few cycles. I’ve discovered I’m much more in touch with my mental and emotional state and even a five minute break will really relieve some of the pressure you put on your mind and body. Also because it’s just for 25 minutes anyway, it’s much easier to get started again, even with unfun…

I used to use an app that had both a timer and a notepad. It was helpful for sketching out pointers to where I’d reached. A quick scan before restarting the next 25min, especially after a meeting or lunch, was very helpful. Being in the same app helped connect it to each session.

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#205

Post by code_duck » Sat, Jul 10, 2021, 11:53 AM UTC

lowercased wrote: post #77

lordnacho wrote: post #70

Earlier quoted context omitted.

Intuitivists. They might take their time to refine their thoughts but they aren't programmers. Type one thing wrong and your novel is still a novel.

type one thing wrong and my code is still code, but the meaning changes, just like the meaning in the novel changes. with many novels, the author may have intended X, but readers are often encouraged to bring their own views and interpretations to the work, and those may often be useful to others in understanding the work. that's not as true for most software I've worked on though.

This would be quite problematic with legal writing.

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#206

Post by mmarq » Sat, Jul 10, 2021, 11:53 AM UTC

the_other wrote: post #203

mmarq wrote: post #201

> Your non-techie peers just don’t get it, no matter how many times you try to make them understand In my opinion this is more common to software development only because software developers, at laest in Europe, do not have the same social recognition as other professionals. An undisciplined PM/PO interrupting everybody to get estimates to update their GANTT chart will be as disruptive in an operating theater or in a…

This is one of the things scrum is meant to help fix. In your daily scrum, tell your team you need X hours that day w/out interruptions and explain why. If your Scrum Master doesn’t protect you from interruptions by others, they’re not mastering their Scrum effectively. Ideally knowledge of the codebase would be spread around your team already such that other people can handle the interruptions I think it would be fa…

I don't want to get into a debate on the "true scrum", but in my experience non-technical scrum masters/POs/PMs who don't write code (randos in my previous comment) are generally detrimental to the productivity of a development team. Software developers who act as scrum masters and whatnot, while also writing code, are way better.

In my past 10 years of experience (as a tech lead, principal and dev manager), the single change that always increased productivity has been to get rid of PMs/SMs and take over their roles. A brain surgeon coordinates brain surgery, a software developer coordinates software development.

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#207

Post by daedalus_f » Sat, Jul 10, 2021, 11:55 AM UTC

mmarq wrote: post #201

> Your non-techie peers just don’t get it, no matter how many times you try to make them understand In my opinion this is more common to software development only because software developers, at laest in Europe, do not have the same social recognition as other professionals. An undisciplined PM/PO interrupting everybody to get estimates to update their GANTT chart will be as disruptive in an operating theater or in a…

I have not worked in software development but I do work in healthcare. At least in my country, management of hospitals has largely been taken away from healthcare professionals and given to career managers whose background is usually administration, HR or finance. They largely display the same irritating traits as you describe and increasingly interfere in clinical decision making while remaining largely unaccountable - unlike everyone else who works in healthcare they have no professional standards body.

I think the wider problem is a conflation of administration and leadership and a tendency for healthcare professionals to not be good at the politics that comes with leadership positions.

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#208

Post by varjag » Sat, Jul 10, 2021, 11:58 AM UTC

snarf21 wrote: post #136

MattGaiser wrote: post #95

Earlier quoted context omitted.

At least on the teams I have been on, we didn't physically interrupt people. We sent Slack and Teams messages for all of that stuff about merges and staging.

Fair, but I think Slack/Teams are just as disruptive as physical interruptions, at least to me.

This weird preference on here for Slack interruptions is just another manifestation of generational call vs text divide. It's more about cultural context and personal anxiety than real disruptive effect.

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#209

Post by NewEntryHN » Sat, Jul 10, 2021, 12:01 PM UTC

The problem is that sitting in front of a computer gives no indication of business. You wouldn't interrupt a surgeon during an operation, or a pilot landing a plane, or a crane operator moving some load on a construction site, or a carpenter currently doing woodwork; because you can very visibly see them being focused on their work. Sitting in front of a computer is the default position of the modern office workplace, which makes it a meaningless signal.

Re: Programmers, teach non-geeks the true cost of interruptions (2014)

#210

Post by mmarq » Sat, Jul 10, 2021, 12:18 PM UTC

daedalus_f wrote: post #207

mmarq wrote: post #201

> Your non-techie peers just don’t get it, no matter how many times you try to make them understand In my opinion this is more common to software development only because software developers, at laest in Europe, do not have the same social recognition as other professionals. An undisciplined PM/PO interrupting everybody to get estimates to update their GANTT chart will be as disruptive in an operating theater or in a…

I have not worked in software development but I do work in healthcare. At least in my country, management of hospitals has largely been taken away from healthcare professionals and given to career managers whose background is usually administration, HR or finance. They largely display the same irritating traits as you describe and increasingly interfere in clinical decision making while remaining largely unaccountabl…

That may or may not be a problem. For instance a career manager may be better suited to make strategical decisions than practitioners.

I don't necessarily have a problem with a non-technical leadership or with non-technical people cooperating with the development team (the latter is often essential for the team to work on meaningful tasks). What I have a problem with is scrum masters, project managers and their like entering an operating theater to distribute candies and pizza, to ask people questions about an unassigned Jira card stuck in the "To Do" swimlane, and generally treat professionals with 10-20 years of experience as if they were a bunch of partially-socialized four-year-old children.