Slashdot runs a thread on “Are Remote Software Teams More Productive?“. The original post links to a few research references that, unsurprisingly, show how expensive interruptions are to programmers, and how unprepared we are, as an industry, to deal with this problem. I particularly liked a rather in-depth look at the issue in “Programmer Interrupted” article.
Like you, I am programmer, interrupted. Unfortunately, our understanding of interruption and remedies for them are not too far from homeopathic cures and bloodletting leeches.
Here are a few points, if the article is too long for you to handle:
Based on a analysis of 10,000 programming sessions recorded from 86 programmers using Eclipse and Visual Studio and a survey of 414 programmers (Parnin:10), we found:
- A programmer takes between 10-15 minutes to start editing code after resuming work from an interruption.
- When interrupted during an edit of a method, only 10% of times did a programmer resume work in less than a minute.
- A programmer is likely to get just one uninterrupted 2-hour session in a day
And also this bit on the worst time to interrupt a programmer:
If an interrupted person is allowed to suspend their working state or reach a “good breakpoint”, then the impact of the interruption can be reduced (Trafton:03). However, programmers often need at least 7 minutes before they transition from a high memory state to low memory state (Iqbal:07). An experiment evaluating which state a programmer less desired an interruption found these states to be especially problematic (Fogarty:05):
- During an edit, especially with concurrent edits in multiple locations.
- Navigation and search activities.
- Comprehending data flow and control flow in code.
- IDE window is out of focus.
Overall, not surprising at all, but it’s nice to have some numbers and research papers to point to…
I found the blog post “I’ve never had a goal” over at Jason Kottke blog interesting. There is a quote from Jason Fried, the founder of Basecamep (aka 37signals):
I can’t remember having a goal. An actual goal.
There are things I’ve wanted to do, but if I didn’t do them I’d be fine with that too. There are targets that would have been nice to hit, but if I didn’t hit them I wouldn’t look back and say I missed them.
I don’t aim for things that way.
I do things, I try things, I build things, I want to make progress, I want to make things better for me, my company, my family, my neighborhood, etc. But I’ve never set a goal. It’s just not how I approach things.
Also, Jason Kottke’s therapist advice:
For the longest time, I thought I was wrong to not have goals. Setting goals is the only way of achieving things, right? When I was criticizing my goalless approach to my therapist a few years ago, he looked at me and said, “It seems like you’ve done pretty well for yourself so far without worrying about goals. That’s just the way you are and it’s working for you. You don’t have to change.”
I myself don’t set goals either. But I’m yet to reach that “you’ve done pretty well for yourself” part. Wink.
Slashdot links to a rather unexpected prediction for the time when we are all driven by the robot cars:
“At least one expert is anticipating that, as the so-called ‘smart’ cars get smarter, there will eventually be an increase in an unusual form of distracted driving: hanky-panky behind the wheel.”
It’s been said many times that you can’t buy happiness with money. The Washington Post runs the article about the research that begs to differ:
Not only did the extra income appear to lower the instance of behavioral and emotional disorders among the children, but, perhaps even more important, it also boosted two key personality traits that tend to go hand in hand with long-term positive life outcomes.
The first is conscientiousness. People who lack it tend to lie, break rules and have trouble paying attention. The second is agreeableness, which leads to a comfort around people and aptness for teamwork. And both are strongly correlated with various forms of later life success and happiness.
Apparently, both dental fear and dental phobia are a thing, and not something I made up in my head:
It is estimated that as many as 75% of US adults experience some degree of dental fear, from mild to severe. Approximately 5 to 10 percent of U.S. adults are considered to experience dental phobia; that is, they are so fearful of receiving dental treatment that they avoid dental care at all costs. Many dentally fearful people will only seek dental care when they have a dental emergency, such as a toothache or dental abscess.
There’s a questionnaire in existence (Corah’s Dental Anxiety Scale) to diagnose it. I scored 17 out of 20, so, yeah – severe anxiety of phobia, but could be slightly worse. Treatment, interestingly, can combine both behavioral techniques, such as positive reinforcement, and pharmacological solutions such as sedation and anesthesia.
And, for those who want to explore this even further, Dental Fear Central is a good place to start.
The trolley problem is an ethical and psychological thought experiment. In its most basic formulation, you’re the driver of a runaway trolley about to hit and certainly kill five people on the track ahead, but you have the option of switching to a second track at the last minute, killing only a single person. What do you do?
Kottke has some thought-provoking variations. I’m sure this has been turned into a drinking game somewhere.
Coding, Fast and Slow: Developers and the Psychology of Overconfidence
This is an excellent take on why (we the) developers suck at time estimations. Basically, it boils down to two reasons: unknown details of the project and overconfendence.
First off, there are, I believe, really two reasons why we’re so bad at making estimates. The first is the sort of irreducible one: writing software involves figuring out something in such incredibly precise detail that you can tell a computer how to do it. And the problem is that, hidden in the parts you don’t fully understand when you start, there are often these problems that will explode and just utterly screw you.
And this is genuinely irreducible. If you do “fully understand” something, you’ve got a library or existing piece of software that does that thing, and you’re not writing anything. Otherwise, there is uncertainty, and it will often blow up. And those blow ups can take anywhere from one day to one year to beyond the heat death of the universe to resolve.
Read the whole thing, it’s worth it.