Live data from Hacker News

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

daedtech.com

181–190 of 253 posts

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

#181
post #158

> 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…

Disrespectful jerks are a problem in any workplace. Programmers complain about it online a lot, because programmers complain about everything online. Making a disrespectful jerk do some stupid Sudoku problem to teach them about interruptions isn't overcoming their lack of perspective, it's just letting them know that they were a disrespectful jerk (which they probably already kind of know, but they're used to it so i…

You should find a better working environment.

While I totally struggle with interruptions (and I have the ADHD bonus points), they always come from team mates that I globally appreciate. I hate interruptions and I do complain about it frequently to my coworkers, but that says absolutely nothing about them being jerks.

When you work in a team, you are frequently blocked and need someone else to give you an answer, even as a programmer. That’s an organizational problem that have to be tackled, for sure, but it rarely have something to do with individuals.

I once had a « PM » that liked to put its laptop on my desk to see what I was doing and to « pair » with me while I was programming. But he knew nothing about programming. THAT is wrong. I left that company.

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

#182

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…

Are you saying getting into that "in the zone" state affected your mental health. Interesting. Any examples of the side effects? Is it hard to put into words?

Yeah this happens for me as well. I can feel the high of being productive but now as I gained expirience I also feel the dread of next day being almost like hungover

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

#183
post #135

Earlier quoted context omitted.

The submitted article is a flame war against non-developers and promotes the same attitude in the workplace. Other people have jobs too. It's condescends : "Your non-techie peers just don’t get it, no matter how many times you try to make them understand." Demeans : "Tell him that you bet him lunch he can’t get it done in five minutes, only getting one shot at getting the answer right. Maybe he’ll stop laughing and g…

Whether that's true or not, you (i.e. everyone here) need to follow the rules whether someone else is breaking them or not. Any other approach guarantees a downward spiral, because it always feels like the other person started it and did worse. To put it in terms that many will remember from their mothers: two wrongs don't make a right. Perhaps you don't the article author (or whoever the other person may be) any bet…

The nature of the article is hardly in question. It is the headline, and purpose of the piece.

My best advice would be to apply your vigilance to submissions as diligently as you do to the comments, nipping it in the bud, as it were. That's what I'd do, if I was interested in maintaining standards as your profess to be.

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

#184
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.

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

#185
It's true that interruptions are a source of significant cost for programmers, but the other side of the coin is that talking through problems and design decisions with other programmers can generate a massive gain in productivity.

Let's say you are struggling with a design choice, or something in the production system looks screwy, how do you know who you can approach to discuss this?

Well, the way i've worked in the past (when we used to all sit in an open plan office which seems like an age ago) was that you signalled 'do not disturb' for those times when you needed to be in the zone by putting headphones on. You weren't necessarily listening to music, some of us did, some didn't, but it was used as a clear signal that you shouldn't be disturbed.

The result of the headphone rule works pretty well. I've worked places where there's been a full production meltdown, serious money being lost (well, not earned) due to the downtime, and all sorts of people and teams being pulled in to help identify and resolve the issue, meanwhile on the same desk someone in headphone mode being totally unaware of the problem.

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

#186

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…

Are you saying getting into that "in the zone" state affected your mental health. Interesting. Any examples of the side effects? Is it hard to put into words?

I find that I have to put myself in a state of deep dissatisfaction in order to develop the motivation to dive in. If I get interrupted before accomplishing anything then I'll remain in a bad mood. And if I think I am going to be interrupted then I won't even start the first dissatisfaction step because I don't want to be stopped halfway. One workaround for that is to define the work in smaller pieces so that interruptions are less likely, but that also takes work.

I'm reminded of a scene from the movie 'Never Cry Wolf' where the bush pilot, while flying the plane, puts himself into a state of rage before stepping outside to fix the problem.

https://youtu.be/9i90_-HpVz0?t=120

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

#187
Programming is like riding a bike. It takes time to get on the bike, to get momentum going. Interruptions are like someone hitting you with a stick while you ride.

Getting hit, falling off, and climbing back on the bike takes a lot of effort, and you have to rebuild your momentum each time it happens. The more times you're knocked off in a day, the more tired you get of climbing back on.

Rebuilding the momentum when programming can take 30 minutes or so. Then you just get whacked with another stick.

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

#188

Earlier quoted context omitted.

Responding to the first point: In a "normal" software context, developers are usually faced with other roles that usually don't have the same focus requirements. PMs, scrum masters and sales or business development types don't usually have the same kind of focus requirements during day to day. Sure, they also need deep focus when drawing up a detailed budget or doing roadmap planning or whatnot, but usually their day…

As an accountant and developer I can tell you that many accounting tasks are very similar to coding. I have spent years having to prepare management accounts in an open office and it is exhausting trying to maintain the focus required. And yes people interrupt you just like any other day because their roles require timely responses. I have an office now and it helps a bit, but normally I hide at home and turn off ema…

It looks to me like you’re wanting to make a counterpoint to the person you’re responding to, but he did put ”bookkeepers” in the same category of people who tend to need deep focus and not be disturbed. Do you agree that not every role shares that quality, and that the parent comment has a point?

If you were agreeing with him and just adding to the argument, then my apologies.

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

#189
...what is described here for programming is the case for most creative work where we weave something into a tight compact whole... also in academic writing, where you build up to the moment of writing by copying all the papers you need into your head... and any disturbance empties the cache and sets you back the 30-40 mins again...

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

#190
Re-diving is not only hard but also demotivating and morally tiring. You spend the same efforts again and again and at the fourth try you just stop understanding why they need you, a deep-analyzing guy, in the first place, when they could just hire a “friday ETA at any cost, boss” guy and ship whatever they could do right at friday evening.

I wore these shoes, but one case was special. I was being young, debugging some live show-stopping issues at the client side (the sales department of a plastics factory, a part of a lingered project) when their production manager who I didn’t even know approached and asked in a very demanding tone when the entire project will be done. I distracted and politely redirected them to our PM only to hear a tirade about me doing nothing for months, despite the fact that all the work was thrown on me only recently, after our low-skilled part of the office managed to create enough mess. I politely explained that (omitting the “mess” part) and repeated what I’ve said before, again to no avail. And then my ego decided that it is reasonable to elevate my tone a little and ask them to please not interrupt me at this part of work, because it doesn’t make it easier. God, that hit him unexpectedly hard. Management is never ready for that sort of a dialogue, as I learned later. He left in rage and never greeted me again. (To not look too grumpy, I must say that everyone else, including some high-profile nose-up positions there, sort of adored me for solving their needs at least partially after a long time and for being not yet another silent display-peering guy.)

Wasn’t long before the story was relayed to our PM. I was criticized and expected to apologize but I refused because morally I didn’t feel guilty and to that moment I understood that this project was unlikely to succeed anyway. Few days later I just took the costs of my time and a fellow developer’s at my own expense and left this project completely. It was worth it.

No moral here, but another example that they don’t really understand the difference between a grinder operator and a developer. Also, I may play sir-vs-peasant games with management, but I still don’t get it as a human and will bite back if they play too much. Nothing is worth losing your dignity, unless you’re seriously leveraged. (And in my experience 99% of the client employees never exploited it anyway for personal attacks or sort of that)

Post reply on HN