Productivity

In his podcast Roberts on Smith, Ricardo, and Trade, Russ Roberts states that self-sufficiency is the road to poverty. Roberts elaborates on the economic theories of Adam Smith and David Ricardo to explain how specialization and trade create wealth and how how radical self-sufficiency leads to poverty.

Suppose you decide to grow your own food. Are you going to buy your gardening tools from Ace Hardware? If you really want to be self-reliant, you should make your own tools. Are you going to take your chances with what water happens to fall on your property, or are you going to rely on municipal water? Are you going to forgo fertilizer or rely on someone else to sell it to you? Carried to extremes, self-reliance ends in a Robinson Crusoe-like existence.

People in poor countries are often poor because they are self-reliant in the sense that they must do many things for themselves. They do not have the opportunities for specialization and trade that are available to those who live in more prosperous countries.

Some degree of self-reliance makes economic sense. Transaction costs, for example, make it impractical to outsource small tasks. It also makes sense to do some things that are not economically feasible. For example, an orthodontist may choose to make some of her own clothing or keep a garden for the pleasure of doing so, not because these activities are worth her time. In general, however, specialization and large trading communities are the road to prosperity. Without a large economic community, no one can become an orthodontist (or an accountant, barrista, electrician, …)

Why do we so often value self-sufficiency more than specialization and trade? Here are a three reasons that come to mind.

1. In America, self-sufficiency is deeply rooted in our culture. We admire the pioneer spirit, and this leads to seeing as virtues actions that were once a necessity.
2. Self-sufficient people are generally well liked, especially if they’re not too prosperous.  Conversely, those who create wealth by leveraging the labor of others are often treated with suspicion and jealously.
3. Our school system encourages “well roundedness” rather than excellence. The way to succeed is to be moderately good at everything, even if you’re not outstanding at anything. (More on this idea here.)

Update: After writing this post, I read Russ Robert’s book The Choice: A Fable of Free Trade and Protectionism. I discovered one of the later chapters is entitled “Self-Sufficiency Is the Road to Poverty.” Excellent book.

Related posts:

Evaluate people at their best or at their worst?
Make something and sell it
Do something dull
Transaction costs

From The Power of Full Engagement:

… every one of the great industrial disasters of the past twenty years — Chernobyl, the Exxon Valdez, Bhopal, Three Mile Island — occurred in the middle of the night. For the most part, those in charge had worked very long hours and built up considerable sleep debt.

Can better tools make you less productive? Here’s a quote from Frequently Forgotten Fundamental Facts about Software Engineering by Robert Glass:

Most software tool and technique improvements account for about a 5- to 30-percent increase in productivity and quality. … Learning a new tool or technique actually lowers programmer productivity and product quality initially. You achieve the eventual benefit only after overcoming this learning curve.

If you’re always learning new tools, you may be less productive than if you stuck with your old tools a little longer, even if the new tools really are better. And especially if you’re a part-time developer, you may never reach the point where a new tool pays for itself before you throw it away and pick up a new one. Kathleen Dollard wrote an editorial to this effect in 2004 entitled Save The Hobbyist Programmer.

Miners know they have a significant problem when the canary they keep with them stops singing. Hobbyist/part-time programmers are our industry’s version of the canary, and they have stopped singing. People who program four to eight hours a week are being cut out of the picture because they can’t increase their skills as fast as technology changes. That’s a danger signal for the rest of us.

So what do you do? Learn quickly or change slowly. The first option is to commit to learning a new tool quickly, invest heavily in up-front training, and use the tool as much as you can before the next one comes along.  This is the favored option for ambitious programmers who want to maximize their marketability by always using the latest tools.

The second option is to develop a leap frog strategy, letting some new things pass you by.  The less time you spend per week programming, the less often you should change tools. Change occasionally, yes, but wait for big improvements.

Related posts:

Doing good work with bad tools
Fear of tech commitment
Three-hour per week language

I have four Twitter accounts that send out one tip per day. One of these might help you with a New Year’s resolution. If you don’t use Twitter, you can follow these Twitter accounts by subscribing to their RSS feeds.

Windows keyboard shortcuts

If  you’d like to become more efficient in using Windows, and reduce your chances of repetitive stress injury, you may want to use your keyboard more and your mouse less. SansMouse is a Twitter account that sends out one keyboard shortcut per day.

Regular expressions

If you’ve intended to learn regular expressions but haven’t made the time, you might want to follow RegexTip for one tip per day about regular expressions. I focus on the features common to Perl, Python, C#, JavaScript, etc. I also have some tips coming up with language-specific tips.

Math

I have two mathematical Twitter accounts. These might be useful if you want to review math courses you took a long time ago or if you want a preview of math you might need in the future. Both are eclectic, mixing elementary and advanced topics.

ProbFact sends out one probability fact per day, mostly theorems but sometimes notes on applications.

I just started AnalysisFact a couple days ago. It will cover a wide range of topics from real and complex analysis. AnalysisFact will have a wider range of sophistication than ProbFact, mixing undergraduate and graduate level material.

Update (31 December 2011): Over the last year I’ve added three mathematical Twitter accounts:

• AlgebraFact for algebra and number theory
• TopologyFact for topology and geometry
• StatFact for statistics.

I’ve also added two computing accounts:

• TeXtip for TeX and LaTeX typesetting
• CompSciFact for computer science.

Summary

Here are the Twitter accounts and their RSS feeds:

• SansMouse (RSS)
• RegexTip (RSS)
• ProbFact (RSS)
• AnalysisFact (RSS)
• AlgebraFact (RSS)
• TopologyFact (RSS)
• TeXtip (RSS)
• StatFact (RSS)
• CompSciFact (RSS)

***

New Year’s links

Here are a couple posts from Jon Swanson:

8 ways to end the year
Leave it in 2008 (Just mentally change the “8″ to a “9″ when you read it.)

And here is a good post from Jurgen Appelo:

Checklist for goals and resolutions.

Related posts

Using Windows without a mouse
Tips for learning regular expressions
Math and statistics articles
Daily tip Twitter account FAQ

Countless articles tell us that multitasking makes us less efficient — we’re not as good at multitasking as we suppose. But here is a new criticism: multitasking makes us shallow.

If you don’t want to sink, you learn to surf; you have to. You learn how to go fast, but smooth, through a huge amount of stuff — at work, at home, in the store, in the street. Multitasking means learning how to double back and reshuffle at the least hint of resistance, it means missing most of what goes on around you but learning not to regret it because nothing is that much more valuable than anything else, it means learning how to coast through meetings on zero information … You are compensated for the loss of buffers and boundaries built into the old real world of separated times and spaces, by an overall muffling of experience in general …

From Mediated by Thomas de Zengotita.

Related posts:

A sort of opposite to Parkinson’s law
Getting to the bottom of things
Rethinking interruptions
Emily Dickinson versus Paris Hilton

The most productive programmers are orders of magnitude more productive than average programmers. But salaries usually fall within a fairly small range in any company. Even across the entire profession, salaries don’t vary that much. If some programmers are 10x more productive than others, why aren’t they paid 10x as much?

Joel Spolsky gave a couple answers to this question in his most recent podcast. First, programmer productivity varies tremendously across the profession, but it may not vary so much within a given company. Someone who is 10x more productive than his colleagues is likely to leave, either to work with other very talented programmers or to start his own business. Second, extreme productivity may not be obvious. This post elaborates on this second reason.

How can someone be 10x more productive than his peers without being noticed? In some professions such a difference would be obvious. A salesman who sells 10x as much as his peers will be noticed, and compensated accordingly. Sales are easy to measure, and some salesmen make orders of magnitude more money than others. If a bricklayer were 10x more productive than his peers this would be obvious too, but it doesn’t happen: the best bricklayers cannot lay 10x as much brick as average bricklayers. Software output cannot be measured as easily as dollars or bricks. The best programmers do not write 10x as many lines of code and they certainly do not work 10x longer hours.

Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the client doesn’t actually want what they’re asking for. They may know where to find reusable or re-editable code that solves their problem. They may cheat. But just when they are being their most productive, nobody says “Wow! You were just 100x more productive than if you’d done this the hard way. You deserve a raise.” At best they say “Good idea!” and go on.  It may take a while to realize that someone routinely comes up with such time-saving insights. Or to put it negatively, it may take a long time to realize that others are programming with sound and fury but producing nothing.

The romantic image of an über-programmer is someone who fires up Emacs, types like a machine gun, and delivers a flawless final product from scratch. A more accurate image would be someone who stares quietly into space for a few minutes and then says “Hmm. I think I’ve seen something like this before.”

Related posts:

Writes large correct programs
Experienced programmers and lines of code

Why would you not want to use your mouse? Some tasks are most efficiently done with a mouse, but others can be done more efficiently with the keyboard.The problem isn’t so much using a mouse versus using a keyboard but rather the time it takes to switch between the two modes. Particularly when using a laptop with a touchpad, it’s faster to use the keyboard.

Why does it even matter? So what if you save a few seconds here and there? It’s a matter of keeping up with your thoughts. Suppose some series of tasks takes 20 seconds with a mouse but you can accomplish the same tasks in 12 seconds using the keyboard. The big deal isn’t that you’ve saved 8 seconds; the big deal is that you’re more likely to finish your tasks before you lose the thought that motivated them.

The same could be said for learning to type more quickly. Typing 20% faster doesn’t directly make you 20% more productive unless you’re a professional typist. The benefit is that your fingers can come closer to keeping up with your brain.

If you’d like to get in the habit of using your keyboard more and your mouse less, you may find this helpful. I’ve created a Twitter account for posting one tip per day on using Windows without a mouse. If you’d like to follow using Twitter, it’s @SansMouse. If you don’t use Twitter, you could subscribe via RSS. I’ve written a few dozen tips so far and they’re in a queue to be dribbled one per day. You could practice one simple tip per day until it is natural to use your mouse much less.

I use my mouse fairly often, though I’m trying to get into the habit of using it less. I’ve recently become persuaded that it’s worthwhile to use the keyboard more and that it doesn’t take that much effort.

Related post:

Four patterns in Windows keyboard shortcuts

Here are four patterns for organizing the most common keyboard shortcuts for Windows. First I’ll list the patterns, then I’ll give some qualifications and elaborate on the patterns.

1. Keyboard shortcuts involving letters are all of the form Control-<letter> or Windows-<letter>.
2. The letters used in Control shortcuts and Windows shortcuts don’t overlap.
3. Control in combination with navigation keys moves the cursor. Shift in combination with navigation keys makes a selection.
4. The Tab key cycles through things. What the key cycles through depends on what it is paired with.

When I say Control-<letter> I refer to shortcuts such as Control-C, holding down the Control key and pressing C in order to copy something. When I say Windows-<letter> I refer to holding down the Windows logo key in and pressing some letter.

My goal here is to stick to the most common shortcuts, ones that work across several versions of Windows and with many applications. Also, I’m not including any accessibility sequences such as sticky keys etc.

Control key with letters

Here are the common Windows keyboard shortcuts of the form Control key followed by a letter.

Windows key with letters

Here are the common shortcuts using the Windows key with a letter.

Exceptions

There is one common shortcut that uses a letter and more than just the Control key or Windows key: the combination Windows-Shift-M maximizes all minimized windows. But there are no common shortcuts of the form Alt-<letter> or Control-Shift-<letter> etc.

F is the only letter used with both the Control key and the Windows key. In both cases the command finds something. Control-F finds text within a file and Windows-F searches across directories.

Navigation keys

All the navigation key shortcuts come in pairs.

Control-Home moves the cursor to the top of a document; Control-End moves the cursor to the end.

Control-Left Arrow moves the cursor to the left one word; Control-Right Arrow moves the cursor to the right one word.

Control-Up Arrow moves the cursor up a paragraph; Control-Down Arrow moves the cursor down a paragraph.

Control-Shift-Home selects from the top of the document to the cursor location; Control-Shift-End selects from the current location to the bottom of the document.

Control-Shift-Left Arrow selects one word to the left; Control-Shift-Right Arrow selects one word to the right.

Shift-Left-Arrow expands the selection one character to the left; Shift-Right-Arrow expands the selection one character to the right.

Shift-Up-Arrow selects one line up; Shift-Down-Arrow selects one line down.

Tabbing

The Tab key alone moves the focus in a window, cycling through the controls in the order specified by the application.

Control-Tab cycles through tabs or through windows in an application with multiple windows.

Alt-Tab cycles through running applications.

Windows-Tab cycles through the Task Bar.

Adding the Shift key to any of the above key reverses the cycle order. For example, Alt-Shift-Tab cycles through applications in the opposite order of Alt-Tab.

Miscellaneous shortcuts

Most common Windows keyboard shortcuts are listed above. However, there are several shortcuts that are commonly used but do not fall into a regular pattern. Some of these shortcuts are listed below.

• Shift-F10 brings up a properties dialog, just like right-clicking.
• Shift-Delete permanently deletes a file, bypassing the recycle bin.
• Alt-F4 closes the active window or opens the shutdown dialog if there is no active window.
• Alt-Down Arrow opens a drop down list box.
• Alt-Print Screen grabs an image of the active window rather than the entire screen.
• Alt-Space opens the current window’s system menu.
• Windows-Pause brings up the System Properties dialog.

Most of the function keys are not used often. The most commonly used function keys are

• F1 to bring up help,
• F5 to refresh, and
• F10 to activate an application’s menu bar.

Related posts:
Using Windows without a mouse
Three ways to enter Unicode characters in Windows
Readable path listings
Integrating the clipboard and the command line

Parkinson’s Law says that work expands to the time allowed. I’ve seen that play out over and over. However, I’ve also seen a sort of opposite of Parkinson’s Law. Sometimes work gets done faster when you have more time for it.

Sometimes when I’ve planned a large block of uninterrupted, say going into the office when hardly anyone else is there, I get through my to do list in the first hour of the day. Knowing that I have plenty of time, I think more clearly and end up not needing the extra time. When that happens, I sometimes think “If I’d known this would just take 30 minutes to solve, I would have done it sooner.” But it’s not that simple. Just because it took 30 minutes on a good day doesn’t mean that it could have been done during just any 30-minute time slot earlier.

In his book Symmetry and the Monster, Mark Ronan shares a story along these lines. Ronan tells how John Conway worked on a famous mathematical problem. Conway and his wife agreed that he would carve out Saturdays from noon to midnight and Wednesdays from 6 PM to midnight for working on this challenge. He started one Saturday and cracked the problem that evening. Perhaps Conway would have been able to solve his problem by working on it an hour at a time here and there. But it seems reasonable that having a large block of time, and knowing that other large blocks were scheduled, helped Conway think more clearly.

My guess is that Parkinson’s law applies best to projects involving several people and to one-person projects that are not well defined. But for well-defined projects, especially projects requiring creative problem solving, having more time might lead to not needing so much time.

Related posts:

Work expands to the time allowed
A 3,000 page proof (review of Symmetry and the Monster)
C-State and F-state

Angela Duckworth gave a 90-second talk entitled Why Achievement Isn’t Normal.

She’s using the term “normal” in the sense of the normal (Gaussian) distribution, the bell curve. With normally distributed attributes, such as height, most people are near the middle and very few are far from the middle. Also, the distribution is symmetric: as many people are likely to be above the middle as below.

Achievement is not like that in many fields. The highest achievers achieve far more than average. The best programmers may be 100 times more productive than average programmers. The wealthiest people have orders of magnitude more wealth than average. Best selling authors far outsell average authors.

Angela Duckworth says achievement is not normal, it’s log-normal. The log-normal distribution is skewed to the right. It has a long tail, meaning that values far from the mean are fairly common. The idea of using a long-tailed distribution makes sense, but I don’t understand the justification for the log-normal distribution in particular given in the video. This is not to disparage the speaker. No one can give a detailed derivation of a statistical distribution in 90 seconds. I’ll give a plausibility argument below. If you’re not interested in the math, just scroll down to the graph at the bottom.

The factors that contribute to achievement are often multiplicative. That is, advantages multiply rather than add. If your first book is a success, more people will give your second book a chance. Your readership doesn’t simply add, as if each book were written by a different person. Instead, your audience compounds. Web sites with more inbound links get a higher search engine rank. More people find these sites because of their ranking, and so more people link to them, and the ranking goes up. Skills like communication and organization don’t just contribute additively as they would on a report card; they are multipliers that amplify your effectiveness in other areas.

The log-normal distribution has two parameters: μ and σ. These look like the mean and standard deviation parameters, but they are not the mean and and standard deviation of the log-normal. If X is a log-normal(μ , σ) random variable, then log(X) has a normal(μ, σ) distribution. The parameters μ and σ are not the mean and standard deviation of X but of log(X).

The product of two log-normal distributions is log-normal because the sum of two normal distributions is normal. So if the contributions to achievement are multiplicative, log-normal distributions will be convenient to model achievement.

I said earlier that log-normal distributions are skewed. I’ve got something of a circular argument if I start with the assumption that the factors that contribute to achievement are skewed and then conclude that achievement is skewed. But log-normal distributions have varying degrees of skewness. When σ is small, the distribution is approximately normal. So you could start with individual factors that have a nearly normal distribution, modeled by a log-normal distribution. Then you can show that as you multiply these together, you get a distribution more skewed than it’s inputs.

Suppose you have n random variables that have a log-normal(1, σ) distribution. Their product will have a log-normal(n, √n σ) distribution. As n increases, the distribution of the product becomes more skewed. Here is an example. The following graph shows the density of a log-normal(1, 0.2) distribution.

Here is the distribution of the product of nine independent copies of the above distribution, a log-normal(9, 0.6) distribution.

So even though the original distribution is symmetric and concentrated near the middle, the product of nine independent copies has a long tail to the right.

Related posts:

Small advantages show up in the extremes
Variation in male and female Olympic performance: Part 1, Part 2
Evaluate people at their best or at their worst?

Yesterday I found a copy of Parkinson’s Law for $1 at a library book sale. This book is best known for it’s opening line: Work expands so as to fill the time available for its completion.

The name “Parkinson’s law” can mean at least four different things:

1. The 1957 book by C. Northcote Parkinson
2. The first chapter of Parkinson’s book
3. The principle expressed in the book’s opening line, as understood by Parkinson
4. The principle in the opening line as understood today.

I’d heard of the general principle of Parkinson’s law a few years ago. I only found out about the book more recently. I didn’t know until last night that Parkinson intended his principle to be applied more narrowly than it is applied now.

The full title of the first chapter of the book is “Parkinson’s Law, or The Rising Pyramid.” This chapter explains how work expands to fill the available resources within a bureaucracy and why bureaucracies grow exponentially at a compounding rate of around 5% per year. The subtitle addresses the mechanism for this growth, bureaucrats creating a pyramid of subordinates. Parkinson derives his law from “two almost axiomatic statements”:

1. An official wants to multiply subordinates, not rivals.
2. Officials make work for each other.

Nowadays Parkinson’s law is usually condensed to saying work expands to the time allowed. It is applied to individuals as well as a burgeoning bureaucracies. Parkinson discusses this interpretation in his opening paragraph but then limits his attention to organizations.

The total effort that would occupy a busy man for three minutes all told may in this fashion leave another person prostrate after a day of doubt, anxiety, and toil.

Chapter 3 of Parkinson’s law is “High Finance, or The Point of Vanishing Interest.” This chapter is the source of the phrase bike shed arguments. In this chapter Parkinson states what he calls the Law of Triviality:

… the time spent on any item of the agenda will be in inverse proportion to the sum involved.

The idea is that people are more likely to contribute to the discussion of things they understand. A nuclear reactor will sail through the finance committee, but a bicycle shed will cause endless debate because everyone can understand it and everyone has an opinion.

I picked up a copy of Mrs. Parkinson’s Law at the same book sale, also for $1. I’d never heard of it before, but I imagine it will be entertaining.

Related posts:

Bike shed arguments
Organizational scar tissue

I find it odd that so many folks complain about email. Email’s ruining their lives. They wish email had never been invented. Etc.

Say you get 100 email messages in a day. Would you rather have 100 phone calls? The problem isn’t the 100 messages but the 100 new responsibilities represented by the email messages. Email spam is a annoying, but phone spam (i.e. telemarketing) is worse.

There are alternatives to email that work well in their niche. RSS subscriptions beat email newsletters. Instant messaging beats email for quick interaction. Twitter beats email for keeping up with loquacious friends. But I don’t understand those who say “email is dead.”

A simplest form of the 80/20 rule says that 80% of results come from only 20% of efforts. For example, maybe the top two people on a team of 10 are responsible for 80% of the team’s output. Maybe the most popular 20% of items on the menu account for 80% of a restaurant’s sales. Maybe you read 10 books on a subject but most of what you learned comes from the best two (or the first two).

The exact numbers 80 and 20 are not special. For example, one study showed that 75% of Twitter traffic comes from the most active 5% of users. That’s still an example of the 80/20 rule. The point is that a small portion of inputs are responsible for a large portion of outputs.

One criticism of the 80/20 rule is that you can only know which 20% was most effective in hindsight. A salesman could call on 100 prospects in a week and only make sales to 20. At the end of the week he could ask “Why didn’t I just call on those 20?” Of course he had to call on all 100 before he could know who the 20 were going to be. Or maybe the best 20% of your stock portfolio accounted for 80% of your growth. Why didn’t you just invest in those stocks? If you could have predicted which ones they were going to be, you would have done just that.

It’s easy to be cynical about the 80/20 rule. There are too many hucksters selling books and consulting services that boil down to saying “concentrate on what’s most productive.” Thanks. Never would have thought of that. Let me write you a check.

At one extreme is the belief that everything is equally important, or at least equally likely to be important. At the other extreme is the belief that 80/20 principles are everywhere an that it is possible to predict the “20″ part. Reality lies somewhere between these extremes, but I believe it is often closer to the latter than we think. In many circumstances, acting as if everything were equally important is either idiocy or sloth.

You can improve your chances of correctly guessing which activities are going to be most productive. Nobody is going to write a book that tells you how to do this in your particular circumstances. It takes experience and hard work. But you can get better at it over time.

Related posts:

Four reasons we don’t apply the 80/20 rule
Weinberg’s law of twins

Some things are important because they’re unimportant. These things are not intrinsically important, but if not handled correctly they distract from what is important.

Content is more important than spelling and grammar. But grammatical errors are a distraction. Correct spelling and grammar are important so readers will focus on the content. Typos are trivial (more on “trivial” below) but worth eliminating.

When I was in college, the computer science department deliberately used a different programming language in nearly every course. The idea was that programming language syntax is unimportant, and constantly changing syntax would cause students to focus on concepts. This had the opposite of the desired effect. Since students were always changing languages, they were always focused on syntax. It would have made more sense to say that since we don’t believe programming language syntax is important, we’re going to teach all our lower division courses using the same language. That way the syntax can become second nature and students will focus on the concepts.

Grammar, whether in spoken languages or programming languages, is trivial. It is literally trivial in the original sense of belonging to the classical trivium of grammar, logic, and rhetoric. These subjects were not the goal of classical education but the foundation of classical education. We now say something is “trivial” to indicate that it is unimportant, but in the past this meant that the thing was foundational. Calling something “trivial” meant that it was important in support of something else of greater interest.

When people call something trivial, they may be correct, but not in the sense they intended. They might mean that something is trivial in the modern sense when actually it’s trivial in the classical sense. For example, unit conversions are trivial. Just ask NASA about the Mars Climate Orbiter.

For a day or two, make note of every time you hear something called “trivial.” Ask yourself whether it is trivial in the modern sense of being simple and unimportant or whether it could be trivial in the classical sense of being foundational.