Productivity

Mental callouses

Posted on by John

In describing writing his second book, Tom Leinster says

… I’m older and, I hope, more able to cope with stress: just as carpenters get calloused hands that make them insensitive to small abrasions, I like to imagine that academics get calloused minds that allow them not to be bothered by small stresses and strains.

Mental callouses are an interesting metaphor. Without the context above, “calloused minds” would have a negative connotation. We say people are calloused or insensitive if they are unconcerned for other people, but Leinster is writing of people unperturbed by distractions.

You could read the quote above as implying that only academics develop mental discipline, though I’m sure that’s not what was intended. Leinster is writing a personal post about the process of writing books. He’s an academic, and so he speaks of academics.

Not only do carpenters become more tolerant of minor abrasions, they also become better at avoiding them. I’m not sure that I’m becoming more tolerant of stress and distractions as I get older, but I do think I’m getting a little better at anticipating and avoiding stress and distractions.

Time and Productivity

Posted on by John

Contractors were working on my house all last week. I needed to be home to let them in, to answer questions, etc., but the noise and interruptions meant that home wasn’t a good place for me to work. In addition, my Internet connection was out for most of the week and I had a hard disk failure.

Looking back on the week, my first thought was that the week had been an almost total loss, neither productive nor relaxing. But that’s not right. The work I did do made a difference, reinforcing my belief that effort and results are only weakly correlated. (See Weinberg’s law of twins.)

Sometimes you have a burst of insight or creativity, accomplishing more in a few minutes than in an ordinary day. But that didn’t happen last week.

Sometimes your efforts are unusually successful, either because of the preparation of previous work or for unknown reasons. That did happen last week.

Sometimes you simply work on more important tasks out of necessity. Having less time to work gives focus and keeps work from expanding to fill the time allowed. That also happened last week.

* * *

I did get out of the house last Tuesday and wrote about it in my previous post on quality over quantity. This turned out to the theme of the week.

Reducing development friction

Posted on by John

Diomidis Spinellis gave an insightful list of ways to reduce software development friction in the Tools of the Trade podcast episode The Frictionless Development Environment Scorecard.

The first item on his list grabbed my attention:

Are my personal settings and preferences consistent on all the computers I’m using? Are they stored under version control? Can I install them on a new computer using a single command?

Listening to the podcast provoked me to finally sync my .emacs files on all my computers so that I now have the exact same file on all computers, maintained under version control. (Xah Lee gave me some sample code for creating the branching logic I needed for a few differences between Windows and Linux.)

Here is a small sample of questions from the podcast.

  • Are my files getting backed up? Is the backup tested, accessible, off site, in multiple media, with regularly retained copies?
  • Can I use the same editor for all my code and documentation editing tasks?
  • Can I get context-sensitive help and code completion?
  • Can I search recursively down a directory tree? Ignoring case? Only in a subset of files? With a regular expression?
  • Can I open a shell from the graphical file explorer and vice versa?
  • Can I quickly build the application I’m working on after a change? Can I test the application with a single command?
  • Can I automatically check my code for common or tricky errors? Are these checks run by default? Are they clean?
  • Does my application log its actions?
  • Is documentation for the tools and APIs I use readily available? Is it hyperlinked? Available offline?

The last question from the podcast summarizes the whole list:

Do I regularly evaluate my development environment to pinpoint and eliminate the sources of friction? Do I help my colleagues do the same?

The difference between machines and tools

Posted on by John

From “The Inheritance of Tools” by Scott Russell Sanders:

I had botched a great many pieces of wood before I mastered the right angle with a saw, botched even more before I learned to miter a joint. The knowledge of these things resides in my hands and eyes and the webwork of muscles, not in the tools. There are machines for sale—powered miter boxes and radial arm saws, for instance—that will enable any casual soul to cut proper angles in boards. The skill is invested in the gadget instead of the person who uses it, and this is what distinguishes a machine from a tool.

Related post: Software exoskeletons

Some things can’t be done slowly

Posted on by John

Keith Perhac mentioned in a podcast that a client told him he accomplished more in three days than the client had accomplished in six months. That sounds like hyperbole, but it’s actually plausible.

Sometimes a consultant can accomplish in a few days what employees will never accomplish, not because the consultant is necessarily smarter, but because the consultant can give a project a burst of undivided attention.

Some projects can only be done so slowly. If you send up a rocket at half of escape velocity, it’s not going to take twice as long to get where you want it to go. It’s going to take infinitely longer.

Related post: A sort of opposite of Parkinson’s law

Slabs of time

Posted on by John

From Some Remarks: Essays and Other Writing by Neal Stephenson:

Writing novels is hard, and requires vast, unbroken slabs of time. Four quiet hours is a resource I can put to good use. Two slabs of time, each two hours long, might add up to the same four hours, but are not nearly as productive as an unbroken four. … Likewise, several consecutive days with four-hour time-slabs in them give me a stretch of time in which I can write a decent book chapter, but the same number of hours spread out across a few weeks, with interruptions in between them, are nearly useless.

I haven’t written a novel, and probably never will, but Stephenson’s remarks describe my experience doing math and especially developing software. I can do simple, routine work in short blocks of time, but I need larger blocks of time to work on complex projects or to be more creative.

Related post: Four hours of concentration

Randomized studies of productivity

Posted on by John

A couple days ago I wrote a blog post quoting Cal Newport suggesting that four hours of intense concentration a day is as much as anyone can sustain. That post struck a chord and has gotten a lot of buzz on Hacker News and Twitter. Most of the feedback has been agreement, but a few people have complained that this four-hour limit is based only on anecdotes, not scientific data.

Realistic scientific studies of productivity are often not feasible. For example, people often claim that programming language X makes them more productive than language Y. How could you conduct a study where you randomly assign someone a programming language to use for a career? You could do some rinky-dink study where you have 30 CS students do an artificial assignment using language X and 30 using Y. But that’s not the same thing, not by a long shot.

If someone, for example Rich Hickey, says that he’s three times more productive using one language than another, you can’t test that assertion scientifically. But what you can do is ask whether you think you are similar to that person and whether you work on similar problems. If so, maybe you should give their recommended language a try.

Suppose you wanted to test whether people are more productive when they concentrate intensely for two hours in the morning and two hours in the afternoon. You couldn’t just randomize people to such a schedule. That would be like randomizing some people to run a four-minute mile. Many people are not capable of such concentration. They either lack the mental stamina or the opportunity to choose how they work. So you’d have to start with people who have the stamina and opportunity to work the way you want to test. Then you’d randomize some of these people to working longer, fractured work days. Is that even possible? How would you keep people from concentrating? Harrison Bergeron anyone? And if it’s possible, would it be ethical?

Real anecdotal evidence is sometimes more valuable than artificial scientific data. As Tukey said, it’s better to solve the right problem the wrong way than to solve the wrong problem the right way.

Related posts

Four hours of concentration a day

Posted on by John

Man concentrating

As I’ve blogged about before, and mentioned again in my previous post, the great mathematician and physicist Henri Poincaré put in two hours of work in the morning and two in the evening.

Apparently this is a common pattern. Cal Newport mentions this in his interview with Todd Henry.

Now we also know that if you study absolute world class, best virtuoso violin players, none of them put in more than about four or so hours of practice in a day, because that’s the cognitive limit. And this limit actually shows up in a lot of different fields where people do intense training, that you really can’t do about more than four or so hours of this type of really mental strain.

And they often break this into two sessions, of two hours and then two hours. So there’s huge limits here. I think if you’re able to do three, maybe four hours of this sort of deep work in a typical day, you’re hitting basically the mental speed limit, the amount of concentration your brain is actually able to give.

He goes on to say that you may be able to work 15 hours a day processing email and doing other less demanding work, but nobody can sustain more than about four hours of intense concentration per day.

Update: The comments add examples of authors and physicists who had a similar work schedule.

Related post: Increasing your chances of entering flow

Increasing your chances of entering flow

Posted on by John

I recently ran across a tip from Mark Hepburn that caught my eye. The content of the tip isn’t important here but rather his justification of the tip:

It sounds trivial, but it can really help keep you in the flow.

This line jumped out at me because I’ve been thinking about my work habits lately. Now that I’m self-employed, I have the opportunity to develop new habits. My excuses for not trying different ways of working have been stripped away. Maybe my excuses weren’t valid before, but it’s obvious that they are not valid now.

Small customizations like Mark mentioned are under-appreciated in part because they are trivial, at least when viewed one at a time. But the cumulative effect of numerous trivial customizations could be substantial. Together they increase the probability that you can act on an idea before it slips your mind and before you lose the will to pursue it.

Small customizations are also very personal, and so they don’t make good blog posts. I suspect that productivity bloggers primarily write about things they don’t actually do. They write about things that a wide audience will find entertaining if not useful. The little things that make a difference to the blogger may be boring or embarrassing to write about.

* * *

Instead of giving a simple list of related links at the bottom as I usually do, I’ll give some links along with commentary.

Henri Poincaré had a radical work schedule: one two-hour sprint in the morning and another in the afternoon. Some people look at that and think he put in half a normal work day. But if he had four hours of concentrated focus, I imagine he put in four times a typical work day.

Here are posts on changing how you type and how you use a text editor.

And here are a three posts on how mundane things are undervalued:

And finally, here’s a post on customizing conventional wisdom to your circumstances.

Fractured work

Posted on by John

Vivek Haldar’s recent post Quantum of Work points out something obvious in retrospect: programming is intrinsically fractured. It does little good to tell a programmer to unplug and concentrate. He or she cannot work for more than a few minutes before needing to look something up online or interact with someone.

A quantum of work is the theoretical longest amount of time you can work purely on your own without needing to break out into looking up something on the web or your mail or needing input from another person. For most modern workers this quantum of work is measured in minutes.

At least that’s the default, the path of least resistance. But it’s not the only way to work. Software developer Joey Hess describes how he works.

[My home] is nicely remote, and off the grid, relying on solar power. I only get 50 amp-hours of juice on a sunny day, and often less than 15 amp-hours on a bad day. … I seem to live half the time out of range of broadband, and still use dialup since bouncing the Internet off a satellite has too much latency, and no better total aggregate bandwidth. So I’m fully adapted to asynchronous communication.

Joey Hess cannot possibly work the way Vivek Haldar describes. It sounds like his quantum of work is measured in hours if not days. That would not be optimal or even feasible for some kinds of work, but it does suggest that we may not need to be as connected as we are. Maybe your optimal quantum of work is somewhere between the extremes discussed above.

If your quantum of work is 10 minutes, maybe you could increase that. This would require making some changes. Keeping your same way of working but trying to ration your time online would be frustrating and counterproductive. I think it’s significant that Hess says he adapted to working asynchronously. For example, I assume he keeps reference material on his local hard drive that others would access online.

Even if working offline is less efficient, it’s a good idea to be prepared to work that way when necessary. I was reminded of that this weekend. I was using some desktop software that depends on a server component. There was a failure on the vendor’s server and nobody at work to fix it, so I was stuck.

What are some ways to increase your quantum of work and to work less synchronously?

Related posts