Rob Pike is a Canadian computer scientist and software engineer.
At Bell Labs (late 1970s–2000s) he worked with Ken Thompson and others on:
- Plan 9 and Inferno operating systems (clean, network-centric successors to Unix)
- The Blit/Jerq terminal, sam and acme editors, and structural regular expressions
- Co-designing UTF-8 (with Thompson), now the dominant text encoding
He co-authored two influential books with Brian Kernighan, The Unix Programming Environment (1984) and The Practice of Programming (1999), which champion clarity and simplicity.
---
Among other things, with The Practice of Programming he laid out many principles of programming style, and today I’m sharing what are commonly called his “five rules.”
You’ll obviously recognize principles also championed by others like Knuth or Kernighan, but an interesting point concerns O(n) complexity.
He reminds us it isn’t an absolute, and that aiming immediately for the theoretically minimal complexity isn’t always a good idea.
I’d add that on modern CPU architectures, what is theoretically fastest isn’t always the fastest once implemented.
And of course this is not a license to write garbage.
---
- Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.
- Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.
- Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)
- Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
- Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.