Today I read an article wrote by Rob Pike. In that article, Rob recalled his pair programming with Ken Thompson couple years ago, another one of the best programmer in the history.
He said he always tried to debug as soon as possible while Ken always just kept standing and thinking, ignored Rob and the code they'd just written. However, Ken can always find the root cause before Rob and figured out the solution.
Rob realized that Ken was building a mental model of the code and when something broke it was an error in the model. By thinking about how that problem could happen, he'd intuit where the model was wrong or where our code must not be satisfying the model.
Rob said Ken taught him that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the cod that will improve the design and prevent further bugs.
In the end of the article, Rob makes a conclusion that thinking without looking at the code is the best debugging tool of all, because it leads to better software.
I think I should try to adapt this approach when I programming. Thinking before debugging.
I found another article wrote by Rob, Rob Pike's 5 Rules of Programming:
Rob Pike's 5 Rules of Programming
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.
Pike's rules 1 and 2 restate Tony Hoare's famous maxim "Premature optimization is the root of all evil." Ken Thompson rephrased Pike's rules 3 and 4 as "When in doubt, use brute force.". Rules 3 and 4 are instances of the design philosophy KISS. Rule 5 was previously stated by Fred Brooks in The Mythical Man-Month. Rule 5 is often shortened to "write stupid code that uses smart objects".
Written on 27 September 2016