Productivity

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

Personal organization software

Posted on by John

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