habits

Interrupting my interruptions

Tonight I was just settling down for a ponder on some personal stuff when I noticed an email from my brilliant brother-in-law (hi, Stephen!), recommending an article about the cost of interrupting programmers. Half an hour later, I’m blogging about it. Yes, I see the irony in the read, the blog, and the shout-out, but I just can’t help it.

I’ve heard lots of estimates of the cost of interrupting, but the research in this article seems particularly clear. I think the article oversimplifies by assuming that the problem and solution derive purely from memory, but there’s enough insight and clever thinking in the article to make it worth a read…

We’ve all known that interruption = bad. We’ve nodded our heads at this wisdom for years. Occasionally we give lip service to it. We try to clump meetings in one portion of the day, leaving blocks of time for serious thinking and work. We advise our teams to use “lighter” interruptions (“ask your question by chat/email instead of in person; it’s less disruptive…”). We decline non-essential meetings and urge others to keep their invite lists small. We buy “cones of silence” and “Do Not Disturb” signs and set them up outside the cube of the guy who’s trying to finish urgent work for an impending release.

And then we fall off the bandwagon.

At least, I do.

Hi. My name is Daniel, and I’m addicted to interruptions. :-)

time_management

Image Credit: xkcd

Symptoms

You would see my addiction if you walked past my desk and looked at the tabs in my browser: two for email (work, personal), two or three for calendaring, some chat sessions, a task list, several programming topics, a man page, a python reference, an interesting blog post or two, three wikipedia pages, a ticket I looked up before I ran to my last meeting, a wiki page I’m in the middle of editing, a competitor’s product portfolio, a LinkedIn discussion forum on cloud computing, a Google spreadsheet, the PDF of a resume I’m supposed have read before I do an interview in an hour, half a dozen random sites that I visit during the day as I check gossip on a competitor or read the Dilbert cartoon someone emailed me…

How am I supposed to think Deep Thoughts when I’ve got that much noise?

Continue reading →

Learned Helplessness, Rats, and People Power

In the 1950s, researchers at Johns Hopkins conducted some very troubling experiments. They caught wild rats and squeezed them in their hands until they stopped struggling, teaching them that nothing they did would let them escape the crushing grip of their human captors. Then they dropped the rats in a bucket of water and watched them swim.

Now, wild rats are superb swimmers. On average, rats that had not received the squeeze treatment lasted around 60 hours in the bucket before they gave up from exhaustion and allowed themselves to drown. One unsqueezed rat swam for 81 hours.

A later rats-in-bucket experiment (not quite so brutal). Photo credit: MBK (Marjie) (Flickr).

The average squeezed rat sank after 30 minutes.

In the 1960s and 1970s, Martin Seligman became interested in this phenomenon–he called it “learned helplessness“–and he was able to trigger similar “giving up” behavior in dogs and other animals. He theorized that human depression Continue reading →

All I Really Need To Know I Didn’t Learn In Compugarten

I’m glad newly minted software engineers are exposed to data structures, compilers, concurrency, graph theory, assembly language, and the other goodies that constitute a computer science curriculum. All that stuff is important.

But it’s not enough.

Not all classroom material for CS folks should be technical. Photo credit: uniinnsbruck (Flickr).

Since I’m half way to curmudgeon-hood, I frequently find myself lamenting educational blindspots in the young. I’ve even toyed with the idea of teaching at the nearest university, some day when I Have More Time™. If academia would take me, my lesson plans might cover some of the following topics:

Put Your Const Foot Forward

Here are two C++ style habits that I recommend. Neither is earth-shattering, but both have a benefit that I find useful. Both relate to the order in which constness shows up in your syntax.

1. When you write a conditional, consider putting the constant (unchangeable) value first:

if (0 == i)

… instead of:

if (i == 0)

The reason is simple. If you forget/mis-type and accidentally write a single = instead of two, making the expression into an assignment, you’ll get a compile error, instead of subtle and difficult-to-find misbehavior. (Thanks to my friend Doug for reminding me about this one not long ago.)

Ah, the joys of pointers… Image credit: xkcd.

2. With any data types that involve pointers, prefer putting the const keyword after the item that it modifies:

char const * VERSION = "2.5";

… instead of:

const char * VERSION = "2.5";

This rule is simple to follow, and it makes semantics about constness crystal clear. It lets you read data types backwards (from right to left) to get their semantics in plain English, which helps uncover careless errors. In either of the declarations of VERSION given above, the coder probably intends to create a constant, but that’s not what his code says. The semantics of the two are identical, as far as a compiler is concerned, but the first variant makes the mistake obvious. Reading right-to-left, the data type of VERSION is “pointer to const char” — so VERSION could be incremented or reassigned.

Use the right-to-left rule in reverse to solve the problem. If we want a “const pointer to const char”, then we want:

char const * const VERSION = "2.5";

That is a true string literal constant in C++. (Thanks to my friend Julie for teaching me this one.)

This might seem like nit-picky stuff, but if you ever get into const_iterator classes and STL containers, this particular habit helps you write or use templates with much greater comfort. It also helps if you have pointers to pointers and the like. (For consistency, I prefer to follow the same convention for reference variables as well. However, this is not especially important, since references are inherently immutable and therefore never bind to const.)

Action Item

Share a tip of your own, or tell me why you prefer different conventions.

Book Review: Poke the Box

I just finished reading Seth Godin’s Poke the Box, and I recommend that you add it to your reading list. It’s short, punchy, and thought-provoking.

 

The main idea he advocates is that we should not wait around for the world to give us permission, and we should not be afraid to fail. We should just jump in with two feet and make things happen.

My favorite phrase from the whole book–and a great three-word summary–is “Now beats soon.” Kind of reminds me of the favorite motto of a wise leader that I admire: “We must lengthen our stride. And we must do it now.” (Spencer W. Kimball; he had “Do it now!” on a plaque on his desk.)

Yes, there are a few caveats. Some people are forever starting, but never finishing. That can be a problem. And you have to do your homework before you start; you don’t want to jump in until you know whether you’ve picked a smart place to swim across the river.

The only critique I have is that Godin could have said the same thing in about half the space. He has lots of short anecdotes, which are fun, but he had me convinced long before I got to the end.

Action Item

Go out and do something great! Now.

Related articles