If there is one skill that is needed in a modern office is email. By email, I do not refer to the specific Internet protocol. I refer to the general process of exchanging electronic text online.

We have had thousands of years to learn how to talk to each other. We know how to read each other. Our brains have evolved to cope with these intricate exchanges.

Email is much more difficult. Email is an emerging art that few master.

Here are some basic concepts:

  • Keep your emotions in check. Email does not care how you feel. It takes great care to decipher and communicate emotions accurately online. If you get angry or otherwise preoccupied with the emails themselves, you are doing it wrong. If you want to express your feelings, take a theatre class or create a YouTube channel. Email is not your therapist.
  • Every email you send is public. I would never share without permission a private email, but many others would. In many corporations, all emails are archived and can be reviewed by management. Messages you send through Facebook or Twitter are evidently public.

    When I started blogging, people asked me how I could share with the world my thoughts without care. These same people often did not think twice about sending an ugly email.

    Behave as if everyone is reading your emails and you will be more effective.

  • Debating is usually a waste of your time. There are debating clubs, but none that operate by email. If you want to try to convince people of the error of their ways, write bona fide articles.
  • No mass email. It might be ok to send an email to your tribe (less than twelve people) but any email to a larger group is flat out wrong.

    If you are the recipient of an email sent to a lot of people, please do not hit “reply to all” without due consideration.

  • Short and infrequent. Bombarding someone with emails every day is not going to get you on their Christmas list. Long emails will not be read.
  • Keep your inbox clean. You are simply not supposed to have hundreds of messages in your inbox.
  • Not every email requires an answer. Though there might be social expectations that emails require responses… only send a response if it is genuinely useful. Also, if someone is not responding to your email, they are not “ignoring” you.
  • Not every email requires an immediate response. I have cultivated a habit of delaying my responses. If I have to respond to someone who does not know me well, I will send a quick warning that my response will not be immediate. Sometimes, after waiting a few days, no response is needed anymore. Other times, by waiting a bit, I have given myself time to produce a more thoughtful and engaging reply. It can take me weeks or months to answer some emails: I am not particularly worried about it.

In his excellent book How to Fly a Horse, Ashton makes a case for working alone. He quotes Apple’s co-founder and technical genius Steven Wozniak:

Work alone. You’re going to be best able to design revolutionary products and features if you’re working on your own. Not on a committee. Not on a team.

This should be qualified: Wozniak did not work alone. What he means is that he designed his work alone.

Researchers such as Brooks have long advocated that design is a lonely task.

The idea that building up ideas is best done alone or in tiny teams flies in the face of many of our managerial practices:

  • companies like Google and Facebook leave little private space to their employees;
  • most research funding bodies specifically encourage collaboration… having entire funding programs to encourage collaboration.

Yet we know that researchers in smaller laboratories are more productive (Carayol and Matt, 2006). There is also no evidence that collaboration with outside groups improves productivity (Abramo et al., 2009).

I believe that despite all of the evidence, our intuition about when good and innovative work happens is all wrong. If you cannot go for one hour in a quiet room to think, you are just responding. Your brain is not deeply engaged.

Yet we think too often that it is in this multitasking mode, where we have many things on our minds, solving twelve problems at a time, that we are being creative.

Time alone to think is often viewed as egotistical. I would argue that it is even slightly shameful. Who are you to request time alone in a private office?

I think we have evolved a negative view of loneliness for good reasons. For our ancestors, being alone was being dead.

Our brains are marvellous computers that have evolved for sophisticated relationships. We have complex interactions with a few people every day. Our livelihood depends on these interactions. I think you would be right to model human beings as nodes in a computing cluster. We are fundamentally geared to relate frequently and deeply with our tribe.

For sure, there are a few people who cut off all lines of communication… but far fewer than you may think. Look at tenured professors… look at how many, at least in the sciences, write their papers alone. Further, look at how many write papers alone on work that has little to do with what other contemporary researchers do… Researchers are amazing gregarious.

Most of my own work was done in small teams. I almost never work alone per se. I find it much more enjoyable to work with others. But my collaboration patterns are usually iterative:

  • Joe provides piece A;
  • I take time alone to study A, and after a time I provide B;
  • Joe takes B and valides it… maybe providing me with a revised version C…

Each iteration can take hours, days… But notice how the core of the work, the important pieces, are done by individuals working alone.

I have grown convinced over time that the reason we need to design alone is that it is difficult otherwise to reach a state of flow. In a good day, I might enter a state of flow for an hour or two. That is when I do my most important work. The rest of the day is spent answering emails, grading papers, reviewing articles, getting back to students, and so on.

To enter the state of flow, I need to ignore everything but the problem at hand. In a robust state of flow, I will forget to eat. It is difficult to enter this state with people around unless they are careful not to disturb you.

I like to compare a state of flow to a compute that shuts down all non-essential background processes. The entire CPU cache (i.e., your short term memory) becomes dedicated to one problem and one problem only.

In a normal state, my brain has to think about many things… though I am not aware of it, I constantly check the time, review my agenda for the day, and so on. In a state of flow, all these background tasks are terminated.

To do your best work, you need to focus. To get this result, you cannot be, at the same time, in constant interaction with others. So, effectively, you have to be alone… at least when you are doing your important work.

People from my generation often complain that their parents were better off. They are often quick to dismiss the Internet and smart phones as irrelevant to their well-being.

Were they better off?

  1. Though it has recently peaked, the number of cars per person is higher than it was in the seventies. Current cars are much safer than there were.
  2. In percentage, home ownership was no higher in the seventies, and lower in the sixties than it is today. Pre-1945, hardly anyone in a city owned his home.
  3. Average retirement age was higher in the 1970s than it is today. That is despite the fact that we have since made forced retirement illegal, and despite the fact that there are far fewer physically demanding jobs. Of course, pre-1945 few people retired and life expectancy was often lower than 65 years.
  4. Air quality has gotten better. Gazoline no longer contains lead.
  5. Far more people attend college, far more people have a college degree than in the 1970s.
  6. Though it has fluctuated quite a bit, unemployment rates in the 1970s and 1980s were not smaller.
  7. Violent crime has greatly diminished. Car accidents have become less frequent and less fatal.

I could go on… On almost every measure that I can imagine, people are better off.

I have not even gotten started with the developing world… In the 1970s, all of China was starving. Today, young people in China proudly carry smartphones.

I also disagree strongly that the Internet and modern computer technology is an irrelevance. As a kid, I had access to a handful of science books. Today, kids the same age have an almost embarrassing wealth of choices. As a kid, I watched whatever was on television… Today, I watch Dr. Who together with my boys, at a time of our choosing.

Would I go back to live in the 1970s? I would not. Why would you?

There is one thing that people are sure to bring up: inequality. Though the poor have gotten richer, the rich have supposedly gotten richer even faster. I say “supposedly” because people spend little time thinking about wealth is. It is typically left undefined. We use various proxies, but it is hard to grasp what this means in reality. For example, is your health and your education part of your wealth? Are your skills a form of wealth?

If you are gay, a woman or a minority, you were more likely to be discriminated against in the 1970s. How do you factor this into your measure of wealth?

I would argue that most of our wealth is intangible. It is not cars and buildings that make us wealthy… You could destroy every building in the US… and though it would be tragic and create much misery, within twenty years, the country would have recovered much of the lost wealth. We know this from experience: Germany was entirely destroyed following the second world war. Its loss was almost incomprehensible. The country was broken in two. Yet within 15 years, West Germans recovered fully.

In any case, it is undeniable that while technology makes us richer, it also allows one individual to have much greater impact. Without electronic recording, Céline Dion would not be known in every corner of the world. This cut both ways… if you live in a remote location, you are made richer by your access to Céline Dion, but Céline Dion can also benefit from this greater reach. The same logic applies to CEOs.

So it is the case that a great professional singer can earn a lot more than an average one today… whereas the gap was much smaller in the middle ages. Should you be annoyed? You should not since both singers are now better off… (trust me, you do not want to go back to the middle ages)

If you set aside the neo-Marxist terminology (e.g., inequality), what is hidden is an age-old vice: envy.

We hate it when we meet people who are better off than we are. We get distressed when we hear that they might be getting even better off. Some people would give up all of the gains we have made since the 1970s if they could be certain that nobody is richer than they are.

I know that some people would do it because they did. The last century was a massive experiment where half the world adopted socialism: the idea that everyone has to be equal, whatever the cost. It culminated in the Berlin wall: some people sought to escape socialism, and so the defenders of socialism had them shot. Entire families were killed just because they tried to escape.

If you base your entire society on envy, it will be morally crippled.

I submit to you that the same holds at the individual level… if envy is what is driving you… you are morally bankrupt.

Here is a test: if you meet someone you went to school with… and this person has a much nicer car and much nicer house than you do… how do you feel? If you feel bad… is the problem with you or with capitalism?

Further reading: 26 charts and maps that show the world is getting much, much better.

Further thoughts: If you know that many people feel bad when you show up your big house or expensive sport car… and clearly, many people do… then why do it? It is fair enough to buy expensive shoes to pick up girls, but is it wise to buy the most expensive luxury car just because you can? Why are you posting a picture of your BMW on your Facebook page?

Programming language designers often abbreviate common function names. The benefits are sometimes dubious in an era where most programmers commonly use meaningful variable names like MyConnection or current_set as opposed to single letters like m or t.

Here are a few evil examples:

  • The C language provides the memcpy function to copy data. The clearer alternative memcopy requires one extra key stroke.1
  • To query for the length of an object like an array in Python and Go, we use the len function as in len(array). The expression length(array) would be clearer to most and require only three additional characters.
  • Though most languages use the instruction if or the equivalent to indicate a conditional clause, when it comes to “else if”, designers get creative. Ruby uses elsif, helpfully saving us from typing the character e. Python uses elif, saving us two key strokes. PHP alone seems to get it right by using elseif.
  • In Python, we abbreviate string to str. Most languages seem to abbreviate Boolean as bool.

I am not opposed to a judicious use of abbreviations. However, by going too far, we create a jargon. We make the code harder to read for those unfamiliar with the language without providing any benefit to anyone. Let us not forget that source code is often the ultimate documentation of our ideas.

Credit: John Cook’s comment on G+ inspired this blog post.

Update: Commenters point out that memcpy had to be shortened due to technical limitations restricting the length of functions to 6 characters in the old days. Fair enough. However, common C functions that use more than 6 characters also look like alphabet soup: fprintf, strcspn, strncpy, etc.

Most people have a mental model of computation based on the Turing machine. The computer does one operation at a time. For example, maybe it adds two numbers and outputs the result.

In truth, most modern processor cores are superscalar. They execute several instructions per CPU cycle (e.g., 4 instructions). That is above and beyond the fact that many processors have several cores.

Programmers should care about superscalarity because it impacts performance significantly. For example, consider an array of integers. You can compute the gaps between the integers, y[i+1]=x[i+1]-x[i], faster than you can recover the original values from the gaps, x[i+1]=y[i+1]+x[i]. That is because the processor can compute several gaps at once whereas it needs to recover the values in sequence (e.g., x[i] before x[i+1]).

Superscalar execution is truly a wonderful piece of technology. It is amazing that our processors can reorder and regroup instructions without causing any bugs. And though you should be aware of it, it is mostly transparent: there is no need to rewrite your code to benefit from it.

There is another great modern feature that programmers need to be aware of: most modern processors support SIMD instructions. Instead of, say, adding two numbers, they can add two vectors of integers together. Recent Intel processors can add eight 32-bit integers using one instruction (vpaddd).

It is even better than it sounds: SIMD instructions are superscalar too… so that your processor could possibly add, say, sixteen 32-bit integers in one CPU cycle by executing two instructions at once. And it might yet squeeze a couple of other instructions, in the same CPU cycle!

Vectorization is handy to process images, graphics, arrays of data, and so on. However, unlike superscalar execution, vectorization does not come for free. The processor will not vectorize the computation for you. Thankfully, compilers and interpreters do their best to leverage SIMD instructions.

However, we are not yet at the point where compilers will rewrite your algorithms for you. If your algorithm does not takes into account vectorization, it may not be possible for the compiler to help you in this regard.

An important problem when working with databases or search engines is the computation of the intersection between sorted arrays. For example, given {1, 2, 10, 32} and {2, 3, 32}, you want {2, 32}.

If you assume that you are interested in arrays having about the same length, there are clever SIMD algorithms to compute the intersection. Ilya Katsov describes an elegant approach for 32-bit integers. If your integers fit in 16 bits, Schlegel et al. have similar algorithms using special string comparison functions available on Intel processors.

These algorithms are efficient, as long as the two input arrays have similar length… But life is not so easy. In many typical applications, you frequently need to compute the intersection between arrays having vastly different lengths. Maybe one array contains a hundred integers and the other one thousand. In such cases, you should fall back on a standard intersection algorithm based on a binary search (a technique sometimes called “galloping”).

Or should you fall back? In a recent paper, SIMD Compression and the Intersection of Sorted Integers, we demonstrate the power of a very simple idea to design better intersection algorithms. Suppose that you are given the number 5 and you want to know whether it appears in the list {1,2,4,6,7,8,15,16}. You can try to do it by binary search, or do a sequential scan… or better yet, you can do it with a simple vectorized algorithm:

  • First represent your single number as a vector made entirely of this value: 5 becomes {5,5,5,5,5,5,5,5}. Intel processors can do this operation very quickly with one instruction.
  • Compare the two vectors {5,5,5,5,5,5,5,5} and {1,2,4,6,7,8,15,16} using one instruction. That is, you can check eight equalities at once cheaply. In this instance, I would get {false,false,false,false,false,false,false,false}. It remains to check whether the resulting vector contains a true value which can be done using yet another instruction.

With this simple idea, we can accelerate a range of intersection algorithms with SIMD instructions. In our paper, we show that, on practical and realistic problems, you can double the speed of the state-of-the-art.

To learn more, you can grab our paper and check out our C++ code.


  • Daniel Lemire, Nathan Kurz, Leonid Boytsov, SIMD Compression and the Intersection of Sorted Integers, Software: Practice and Experience, 2015. (arXiv:1401.6399)
  • Further reading: Efficient Intersections of compressed posting lists thanks to SIMD instructions by Leonid Boytsov.

    Next Page »

    Powered by WordPress