Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

daedtech.com

Post reply on HN
Print view View original

231–240 of 253 posts

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

#231

Post by dang »

doublejay1999 wrote: post #183
dang wrote: post #135

Earlier quoted context omitted.

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.

That's not how it works here. How it works is that users need to control themselves under provocation.

https://news.ycombinator.com/newsguidelines.html

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

#232

Post by Abhinav2000 »

PragmaticPulp wrote: post #12

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

Great advice

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

#233

Post by pksebben »

smcl wrote: post #224
mtsr wrote: post #196

Earlier quoted context omitted.

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…

Yeah good point. I think it's also different since the interruption is on your own terms - you've deliberately given yourself 5 minutes break from some task so that you be more focused over the lifetime of that task. You're (hopefully) not getting other tasks thrown at you which can take up precious mental resources or destroy context you've been slowly building up in your head.

I use pomodoros religiously, and you touched on one of the few gotchas of the technique; Never use your break to attend to other work, unless it's thoughtless. Can't say how many times I've lost the thread and been kicking myself because of mixed contexts.

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

#234

Post by the_other »

james-skemp wrote: post #223
the_other wrote: post #204

Earlier quoted context omitted.

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.

Do you recall the name of it? Starting a new job and that may finally be enough of a change to trigger me actually trying this after all these years of hearing about it.

Vitamin-R. It was Mac only, I think.

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

#235

Post by calderwoodra »

harrisonjackson wrote: post #6

The example I like to use is sudoku. Often, after a day of programming, it takes me a while to "come out of it" and I explain that to my SO as if she'd been doing hours of sudoku and then had to jump into a social situation. Similarly, if you are interrupted in the middle of a "solve" it may be difficult to jump back in - especially if the puzzle hasn't been created correctly and you are trying to "debug" which numbe…

I like to explain it like you're building Ikea furniture, but every time you're interrupted, you have to start from the beginning.

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

#236

Post by mxfh »

ntrz wrote: post #18

The suggested `adding game' in the article seems pretty smug and patronizing to me. Surely explaining the situation to the `culprit' like an adult would do just as well without stooping to the ``I'm interrupting you! I'm interrupting you! See how annoying it is?'' solution. If someone has such little regard for you that a normal conversation won't work, I feel like that `demonstration' is likely to just garner you a…

With the added danger of just handing an easy win to an oldschool accountant type, who surely knows how to do trivial carry addition and can remember 4 digits at time.

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

#237

Post by lamontcg »

titzer wrote: post #121
lamontcg wrote: post #119

> "Any chance I can get an ETA on having that fixed?” This is the most annoying question in the world. I usually want to respond "probably sometime before the heat death of the Universe, but honestly that could slip". Until I write the fix I have no idea that the direction I'm taking will actually work. Very often I discover some $SADNESS while trying to actually do the fix. Some test may blow up in some way I never…

> This is the most annoying question in the world. But this is exactly the information that other people need to plan around to get on with their own work. You need to see things from their perspective. The inner workings of your processes and the long-winded explanation, from their side, is "the most annoying" response in the world. It's a simple question. The ETA is the only information that is actionable for them.…

You can't triage the unknown

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

#238

Post by mrburkins »

eggy wrote: post #228
lostphilosopher wrote: post #142

Earlier quoted context omitted.

FWIW I think you could write an interesting book.

Thank you. I've been torn about a private vs. public life. I have always enjoyed the immediacy of the moment in life having lost friends while still in my teens. I am very tech savvy, and I love GoPros and smartphones for what they are, but I rarely film or photo myself. I do journal, so perhaps when I stop playing around, I'll try writing a book for my children.

Please do. Having lost my dad somewhat unexpectedly I would have loved something like this. I have 2 kids now and think besides financial security, journals, letters etc might be one of the most valuable things I could give them. That way they know me whether I’m here to tell them or not

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

#239

Post by beaugunderson »

aroundtown wrote: post #101

You know what helps: 1. Stop being passive aggressive about being interrupted. 2. Take notes. Dealing with [1]: it is ok, to interrupt some one who starts talking to you, tell them "Hang on", "Just a minute", "Come back in an hour". You have to put your foot down if you are working, even with bosses. Note taking[2]: early in my career I kept too much information in my head, including debugging. Life is so much better…

I do this so often just by adding temporary comments in the code and files that I'm debugging. If I get interrupted I can just `git diff` and see the entire chain of files that got me where I was. When the problem is solved, I just `git checkout -p` and discard any of the temporary comments while keeping whatever the fix was (or inverting this, with `git add -p` and then `git checkout`).

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

#240

Post by doublejay1999 »

dang wrote: post #231
doublejay1999 wrote: post #183

Earlier quoted context omitted.

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.

That's not how it works here. How it works is that users need to control themselves under provocation. https://news.ycombinator.com/newsguidelines.html

> How it works is that users need to control themselves under provocation.

then do so, my friend. then do so.

Post reply on HN