Hacker News Reader

Comment by deleted_account | Hacker News Reader

I think the author's premise is that interruption aversion is symptomatic of how many programmers work and that there are habits one can develop to minimize the impact of external distractions. The presentation from Tom Stuart goes into much more detail.

My personal experiences have led to a waning sympathy for coworkers complaining about too many meetings or interruptions. It's a reactive complaint. The most productive engineers on my teams also tend to be the most disciplined in managing their tasks, guarding their calendars, and employing every Do Not Disturb option available.

To be honest, I think for a lot of developers the premise is already pretty flattering. I'd love to see a presentation titled: "You Were Not That Productive To Begin With, or Why That Fortnite Stream on Your Second Monitor Might Not Be Helping Things."

View on HN

Haha. Good point. I hate interruptions for an opposite reason from others - they give me no time to prepare a proper response to the interrupter.

My CEO used to bust into my office and want to talk high level tech strategy, meanwhile I’ve been staring at the same for loop for an hour. I finally had to tell him that I cannot switch gears that quickly, and if he wanted a coherent conversation he needed to schedule a meeting :)

The classic conundrum of: "Do you want my _first_ answer or my _best_ answer?"

Workers aren't well empowered in many of those situations, at least in my experience.

Those productive engineers? They figured enough of office politics skills to do the equivalent of taking a manager to a dark alley, then leaving the mutilated remains hanging from the "gate" to their time.

Unfortunately, those skills are not skills we teach anyone, at least not in computing. Meanwhile, project management seems to be a common subject in engineering classes in other areas...

I completely agree it is a dysfunctional work environment where the engineer's only recourse to having a sane schedule is taking their "manager to a dark alley."

That said, framing the problem as: "those skills are not skills we teach anyone" is the problem.

Once you can recognize a skill gap, you can fix it. You can be the teacher.

Well, I recognize my own lack of skills there. What's worse is that I also have a generally uphill battle with interpersonal skills, so I'm really not the person to teach them to anyone.

However, so long as we don't have professional courses taking this into account I don't think we can talk about teaching "software engineers".

> The presentation from Tom Stuart goes into much more detail.

What presentation are you talking about? I'd be interested in reading it.

"The Most Common Problem In Software Development And How To Fix It"

https://youtu.be/i08A2uTDoa8

Reply on news.ycombinator.com