Productivity

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:

How to neutralize intelligence
Two kinds of multitasking

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:

Negative space in operating systems
It doesn’t pay to be the computer guy

“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

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:

Rethinking interruptions
Multitasking makes us shallow
Two kinds of multitasking
Screwtape on music and silence

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:

Confusing familiar with simple
Superficial convenience

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:

Programming language fatigue
A little simplicity goes a long way

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:

Is helpful software really helpful?
Ford-Chevy arguments
Would you rather have a chauffeur or a Ferrari?

I’ve tried various strategies and pieces of software for personal organization and haven’t been happy with most of them. I’ll briefly describe my criteria and what I’ve found.

My needs are fairly simple. I don’t need or want something that could scale to running a multinational corporation.

I’d like something with a portable, transparent data format. I don’t want the data stored in a hidden file or in a proprietary format. I’d like to be able to read the data without the software that was used to write it.

I’d like to be as structured or unstructured as I choose and not have to conform to a rigid database schema. I’d like to be able to do ad hoc queries as well as strongly typed queries.

I’d like something that exports to paper easily.

Here’s what I found: org-mode. It’s an Emacs mode for editing text files. It provides sophisticated functionality, but all the sophistication is in the software, not the data format. It’s more convenient to work with org-mode files in Emacs, but the raw file format is just a light-weight mark-down, easy for a person or a computer to parse.

When I went back to using Emacs a year ago after a 15-year hiatus, I heard good things about org-mode but didn’t understand what people liked about it. I heard it described as a to-do list manager and was not impressed. I’m not interested in the features I was first introduced to: tracking the status of to-do items and making agendas. I still don’t use those features. It took me a while to realize that org-mode was what I had been looking for. It was similar in spirit to something I’d thought about writing.

Emacs is an acquired taste. But someone who doesn’t use Emacs could get some good ideas from looking at org-mode. I imagine some people have borrowed its ideas and implemented them for other editors. If not, someone should.

The org-mode site has links to numerous introductions and tutorials. I like the FLOSS Weekly interview with org-mode’s creator Carsten Dominik. In it he explains his motivation for writing org-mode and gives a high-level overview of its features.

Related posts:

Giving Emacs another try
Forced to be simple
Not for everyone
Software that gets used

From Merlin Mann:

If you’ve got more than two priorities, you might as well think you have more than two arms.

Related posts:

Task switching
Four reasons we don’t apply the 80/20 rule

“Scale” became a popular buzz word a couple decades ago. Suddenly everyone was talking about how things scale. At first the term was used to describe how software behaved as problems became larger or smaller. Then the term became more widely used to describe how businesses and other things handle growth.

Now when people say something “won’t scale” they mean that it won’t perform well as things get larger. “Scale” most often means “scale up.” But years ago the usage was more symmetric. For example, someone might have said that a software package didn’t scale well because it took too long to solve small problems, too long relative to the problem size. We seldom use “scale” to discuss scaling down, except possibly in the context of moving something to smaller electronic devices.

This asymmetric view of scaling can be harmful. For example, little companies model themselves after big companies because they hope to scale (up). But running a small software business, for example, as a Microsoft in miniature is absurd. A small company’s procedures might not scale up well, but neither do a large company’s procedures scale down well.

I’ve been interested in the idea of appropriate scale lately, both professionally and personally.

I’ve realized that some of the software I’ve been using scales in a way that I don’t need it to scale. These applications scale up to handle problems I don’t have, but they’re overly complex for addressing the problems I do have. They scale up, but they don’t scale down. Or maybe they don’t scale up in the way I need them to.

I’m learning to make better use of fewer tools. This quote from Hugh MacLeod suggests that other people may come to the same point as they gain experience.

Actually, as the artist gets more into her thing, and gets more successful, the number of tools tends to go down.

On a more personal level, I think that much frustration in life comes from living at an inappropriate scale. Minimalism is gaining attention because minimalists are saying “Scale down!” while the rest of our culture is saying “Scale up!” Minimalists provide a valuable counterweight, but they can be a bit extreme. As Milton Glaser pointed out, less isn’t more, just enough is more. Instead of simply scaling up or down, we should find an appropriate scale.

How do you determine an appropriate scale? The following suggestion from Andrew Kern is a good starting point:

There is an appropriate scale to every human activity and it is the scale of personal responsibility.

Update: See the follow-up post Arrogant ignorance.

Related posts:

Stupidity scales
Million dollar software technique
Scaling the number of projects
Defining minimalism

William Turkel has a nice four-part series of blog posts entitled A Workflow for Digital Research Using Off-the-Shelf Tools. His four points are

1. Start with a backup and versioning strategy.
2. Make everything digital.
3. Research 24/7 (using RSS feeds).
4. Make local copies of everything.

Also by William Turkel, The Programming Historian, “an open-access introduction to programming in Python, aimed at working historians (and other humanists) with little previous experience.”

Related post:

Create offline, analyze online

Here’s an interesting historical anecdote from Karl Fogel’s Producing Open Source Software on the value of preparing for meetings.

In his multi-volume biography of Thomas Jefferson, Jefferson and His Time, Dumas Malone tells the story of how Jefferson handled the first meeting held to decide the organization of the future University of Virginia. The University had been Jefferson’s idea in the first place, but (as is the case everywhere, not just in open source projects) many other parties had climbed on board quickly, each with their own interests and agendas.

When they gathered at that first meeting to hash things out, Jefferson made sure to show up with meticulously prepared architectural drawings, detailed budgets for construction and operation, a proposed curriculum, and the names of specific faculty he wanted to import from Europe. No one else in the room was even remotely as prepared; the group essentially had to capitulate to Jefferson’s vision, and the University was eventually founded more or less in accordance with his plans.

The facts that construction went far over budget, and that many of his ideas did not, for various reasons, work out in the end, were all things Jefferson probably knew perfectly well would happen. His purpose was strategic: to show up at the meeting with something so substantive that everyone else would have to fall into the role of simply proposing modifications to it, so that the overall shape, and therefore schedule, of the project would be roughly as he wanted.

Related posts:

Bike shed arguments
Parkinson’s law

One of the most popular post on this site is Why programmers are not paid in proportion to their productivity. In that post I mention that it’s not uncommon to find some programmers who are ten times more productive than others. Some of the comments discussed whether there was academic research in support of that claim.

I’ve seen programmers who were easily 10x more productive than their peers. I imagine most people who have worked long enough can say the same. I find it odd to ask for academic support for something so obvious. Yes, you’ve seen it in the real world, but has it been confirmed in an artificial, academic environment?

Still, some things are commonly known that aren’t so. Is the 10x productivity difference exaggerated folklore? Steve McConnell has written an article reviewing the research behind this claim: Origins of 10x — How valid is the underlying research?. He concludes

The body of research that supports the 10x claim is as solid as any research that’s been done in software engineering.

Related posts:

Randomized trials of parachute use
Experienced programmers and lines of code

Someone once asked Napoleon how he decided where to assign soldiers. Napoleon’s reply was that it’s simple: soldiers are either smart or dumb, lazy or energetic.

• The smart and energetic I make field commanders. They know what to do and can rally the troops to do it.
• The smart and lazy I make generals. They also know what to do, but they’re not going to waste energy doing what doesn’t need to be done.
• The dumb and lazy I make foot soldiers.

But what about the dumb and energetic? “Those,” Napoleon replied, “I shoot.”

The Napoleon joke comes to mind when I hear praise for somebody because they can “get things done.” Should we make them a field commander or shoot them?

Joel Spolsky says that the ideal programmer is someone who is smart and gets things done. But what about people who are dumb and get things done?

When Ross Perot ran for president in 1992, his supporters exclaimed “He can get things done!” So I’d ask “What does he want to get done that you’d like to see happen?” I don’t recall ever getting an answer.  What he wanted to get done didn’t matter. (I’m not saying that Perot’s platform was dumb. I’ll stay out of that discussion. I’m only saying that it could have been dumb and some people would not know or care.)

One time I heard someone praised as a good teacher. Not knowledgeable, but a good teacher. I objected that if someone is ignorant but a good teacher, does that mean they’re effective in conveying their ignorance? Wouldn’t that be a bad thing? No, all that mattered was that he was a good teacher.

Computer programs consists of lines of code, and lines of code consist of characters. So it’s good for a programmer to be proficient in producing lines of code and characters. Of course it’s more important that they produce lines of code that are correct, maintainable, and that accomplish something worthwhile.

Why would someone support a presidential candidate without knowing their positions? Why would someone want their children to have an ignorant but effective teacher? Why would someone want a programmer who is proficient at producing bad code?

I don’t think anyone wants these things, though they do lose sight of their goals. People like charismatic presidents, good teachers, and productive programmers. But it’s too easy to fall into reductionism, focusing on elemental components and losing sight of the big picture.

Leaders need to make things happen. Teachers need to teach. Programmers need to write code. These basic skills are necessary, but they are not enough.

There’s an active conversation here (59 comments currently, several of which arrived as I composed this post) on how much typing speed matters. I believe the discussion is lively in part because it touches on the issues in this post, basic skills versus larger goals. Participants are coming from varying levels of abstraction, from keystrokes to software engineering. Some are arguing bottom-up, some top-down. I find the dynamic of the discussion more interesting than its content.

Related posts:

Why programmers are not paid in proportion to their productivity
Experienced programmers and lines of code
Writes large, correct programs
Stupidity scales