Productivity

Criteria for a computing setup

Posted on by John

“My setup” articles have become common. These articles list the hardware and software someone uses, usually with little explanation. The subtext is often the author’s commitment to the Apple brand or to open source, to spending money on the best stuff or to avoid spending money on principle. I don’t find such articles interesting or useful.

Vivek Haldar has written a different kind of  “my setup” article, one that emphasizes the problems he set out to solve and the reasons for the solutions he chose. Here are a couple excerpts describing his goals for preserving his data and his health.

Try to remember the oldest digital artifact that you can still retrieve, and more importantly, decode and view. Can you? How old is it? That should give you some idea of how hard and full of unknowns the problem of long-term preservation is. …

If a significant fraction of your working life is spent working with computers, and you do not yet have even the mildest RSI, you should consider yourself extremely lucky, but not immune. Act like you do have RSI, and change your set up right now to avoid it.

I thought the best part of the article was the criteria, not the solutions. It’s not that I disapprove of his choices, but I appreciate more his explanation of the rationale behind his choices. I don’t expect anybody is going to read the article and say “That’s it! I’m going to copy that setup.” I gather that in at least one detail, his choice of version control system, Vivek wouldn’t even copy his own setup if he were to start over. But people will get ideas to consider in their own circumstances.

Related post: Ford-Chevy arguments in tech

iPad as hip flask

Posted on by John

I reread Paul Graham’s essay The Acceleration of Addictiveness after a friend quoted it in a blog post explaining why he is taking an indefinite hiatus from social media. I hadn’t noticed this gem in the footnotes when I first read Graham’s essay:

Several people have told me they like the iPad because it lets them bring the Internet into situations where a laptop would be too conspicuous. In other words, it’s a hip flask.

Related post: How to neutralize intelligence

Ceiling of Complexity

Posted on by John

Dan Sullivan coined an interesting term: The Ceiling of Complexity™. (Sullivan has a habit of trademarking™ everything™ he™ says™. I dislike the gratuitous trademarking, but I like the phrase “ceiling of complexity.”)

The idea behind ceiling of complexity is that every project you complete creates residual responsibilities and expectations. This residual may be small, maybe not even noticeable, but it’s always there. Over time, this residue builds up and adds complexity. Eventually it forms a ceiling and limits further progress until you do something to break through the ceiling and reach a new state of simplicity. The ceiling of complexity is a byproduct of success.

Sullivan’s picture of a ceiling of complexity is sort of existential crisis, something an individual would only face a few times over a career, but I find it useful to use the term for less dramatic situations. It gives a way to talk about the gradual accumulation of small responsibilities that become significant in aggregate.

The idea of a ceiling of complexity can be applied to projects as well as to careers. For example, the entropy of a software code base increases over time. Successful projects may have a faster increase in entropy. The software has to maintain backward compatibility because many people depend on its features. Sometimes even its bugs have to be preserved because people rely on them. It’s much easier to renovate software that nobody uses.

Related posts

Avoiding distraction

Posted on by John

My previous post gave examples of how David Souter and Donald Knuth chose not to use some common technologies. John Venier left an insightful comment.

I think the avoidance of technology in these cases is really an avoidance of distraction. These same fellows would probably not keep a parrot in their office if it screeched every couple of minutes, regardless of their affinity for birds.

I believe he’s right. My intention was to write more broadly about how tools influence our thinking, but the examples I gave were only about one kind of influence: distraction.

Related posts

Productivity and negative space

Posted on by John

My post Why programmers are not paid in proportion to their productivity has been getting a lot of buzz today. One of the arguments in that post is that the most productive programmers know where they can find software to do parts of their job. When they reuse existing code rather than writing their own from scratch, nobody notices. They probably don’t even notice themselves, at least not often.

The work you don’t do is a sort of negative space, like the shape formed by the empty space in a painting or the silence in a piece of music. It’s hard to appreciate what’s not there. It’s hard for a business to reward the unnecessary work that someone avoids doing.

Venkatesh Rao has a different take on what makes some people far more effective than others. In his post Thrust, Drag, and the 10x Effect, he says that the people who are 10x more productive are the those who allocate large, uninterrupted blocks of time to work on difficult creative tasks.

Rao’s observation would also help explain why super programmers do not earn super wages, and it ties into the idea of negative space. People who fracture their time putting out fires seem more productive, or at least more responsive, than the people who block out time to think. It’s harder to notice someone not being frantic. Thinkers don’t fare well in environments that reward activity more than accomplishment.

Related post:

Demonstrating persistence

Posted on by John

“A college degree shows you can finish something.” I’ve heard this forever, but I don’t believe it. Of course a college degree shows that someone finished one thing, namely a college degree. But I don’t think that’s the best predictor of whether someone will finish something else.

College provides a great deal of support: accountability, frequent feedback, a community of peers, etc. Succeeding in this environment is an accomplishment, but it doesn’t necessarily demonstrate that someone can succeed in a less supportive environment. It also doesn’t necessarily indicate that someone can focus on a project that takes more than a semester to finish.

Here are a few things that might be better indicators of initiative and persistence.

  • Learning a foreign language as an adult
  • Losing 50 pounds
  • Learning to play the oboe
  • Quitting smoking
  • Reading Churchill’s history of WWII
  • Starting a business
  • Running a marathon
  • Writing a book

Employers that use college degrees as their only filter on applicants are missing out. An ideal candidate would have a college degree and some proof of independent achievement. But given a choice between someone with only academic credentials and someone with only independent accomplishments, the latter may be a better hire.

Related post: Picking classes

How to neutralize intelligence

Posted on by John

Kurt Vonnegut’s short story Harrison Bergeron begins “The year was 2081, and everybody was finally equal.” Beautiful people are required to wear ugly masks, strong people are required to carry weights, etc. Every excellence is handicapped.

But how do you handicap intelligence? With interruptions. In Vonnegut’s story, those deemed too intelligent are required to wear a device in their ear that regularly interrupts their thoughts with a loud noise.

Related posts

Perverse hipster desire for retro-computing

Posted on by John

Here’s my favorite line from an article Life on the Command Line by Stephen Ramsay:

I also don’t do this [work from the command line] out of some perverse hipster desire for retro-computing. I have work to do. If my system didn’t work, I’d abandon it tomorrow.

That’s refreshing. Some of the more ardent command line advocates give the impression that they use the command line out of pride rather than out of a desire to get work done. Ramsay is recommending his way of working, not bragging about what he’s able to do. He has some interesting ideas, especially in his follow-up article The Mythical Man-Finger.

By the way, I’m no command line wizard; I’m a fairly typical computer user. On the other hand, my use of the command line and Emacs has been increasing.

Related posts

Mental context switches are evil

Posted on by John

This week I’ve run across two examples of technical strategies to reduce mental context switches.

The first example is Pete Kruckenberg’s story of why his team chose to develop a web application using node.js even though he had extensive experience in Perl/Apache. One of his arguments is that since the client-side code has to be written in JavaScript, it saves mental energy to use JavaScript for the server-side code as well. Even for someone who knows JavaScript and Perl well, it takes mental energy to oscillate between the two languages.

There’s much more to node.js than its use of JavaScript. It requires a very different approach to developing web applications. Kruckenberg and his colleagues had to weigh multiple factors in deciding their development framework. But it may not be too much of a simplification to say they chose a big, one-time mental context switch—the node.js style of development—in order to avoid countless daily context switches between JavaScript and Perl.

The second example is Ryan Barrett’s blog post Why I run shells inside Emacs.

Mental context switches are evil. Some people handle them better than others, but not me. I handle them worse. I feel it, almost physically, when context switches whittle down my precious flow piece by piece.

Barrett explains that he first tried configuring Emacs and his shell to be similar, but the very similarity made the context switch more irritating.

Even something as small as switching between Emacs and the shell can hurt, especially when I do it thousands of times a day. … What’s worse, only some parts are different, so my muscle memory is constantly seduced into a false sense of familiarity, only to have the rug yanked out from under it seconds later.

Both examples highlight the cost of context switches. Neither Kruckenberg nor Barrett mentioned the cost of learning two contexts. Instead both focused on the cost switching between two contexts. Novices might understandably want to avoid having to learn two similar tools, but these stories were from men who had learned two tools and wanted to avoid oscillating between them.

My favorite line from Barrett is “context switches whittle down my precious flow piece by piece.” I’ve felt little distractions erode my ability to concentrate but hadn’t expressed that feeling in words.

It’s no exaggeration to call flow “precious.” Productivity can easily vary by an order of magnitude depending on whether you’re in the zone. It may sound fussy to try to eliminate minor distractions, but if these distractions make it harder to get into the zone, they’re worth eliminating.

Related posts

Superficial convenience

Posted on by John

Here’s an interesting phrase:

superficial convenience at the expense of real freedom

This comes from the conclusion of the 1998 essay The Elements of Style: UNIX as Literature by Thomas Scoville. The author sums up his preference for UNIX culture by saying he prefers the “freedom and responsibility that UNIX allows” to the “superficial convenience” of Windows NT.

I’m not interested in arguing here the relative merits of Unix and Windows. I’m more interested in broader ideas that spin off from the quote above. When is a convenience superficial? How well does convenience versus freedom explain technological controversies?

I could see substituting “short-term convenience” for “superficial convenience” and substituting “long-term efficiency” for “real freedom.” But that may lose something. Thomas Scoville’s terms may be more nuanced than my substitutions.

Related posts