Rob Pike's Rules of Programming (1989)

> 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. I wish people would follow this rule and just let stuff work. I recently encountered the most extreme version of this I've ever seen in my career: a design review where a guy proposed a Redis caching layer and a…

I love this >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. I completely agree with this. Which is why all the LeetCode interviews always struck me as odd. They focus on algorithms, not data structures, which is exactly what you don't want to do out of the gate, most of the time. I suppose, if you don't know algorithms at…

Torvalds version of rule 5: “Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” Brooks's version: "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious."

I don't think the author's interpretation of #5 to mean use smart objects (which I'll guess means objects in the object-oriented sense) is correct. I interpret Pike's meaning to be to use dumber objects that make the data visible and obvious. That's also consistent with Go's emphasis on simple datatypes. It's very close (in my opinion) to a restatement of Brook's quote "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your…